This commit updates the copyright year of various files which
gdb/copyright.py is not able to handle automatically.
gdb/ChangeLog:
* gdbarch.sh: Update end year of copyright year range for
copyright header of generated files.
gdb/doc/ChangeLog:
* gdb.texinfo: Change end year of the manual's copyright notice
to 2022.
* refcard.tex: Ditto.
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.
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).
gdb/ChangeLog:
* copyright.py (EXCLUDE_LIST): Add "gdbsupport/Makefile.in".
(cherry picked from commit a3f3402131)
This commit changes the end year of the copyright year range
printed by gdb, gdbserver and gdbreplay to be 2022. This reflects
the fact that some changes were made on this branch this year.
gdb/ChangeLog:
* top.c: Update year range in copyright notice.
(print_gdb_version): Update copyright year to 2022.
gdbserver/ChangeLog:
* gdbreplay.cc: Update year range in copyright notice.
(gdbreplay_version): Update copyright year to 2022.
* server.cc: Update year range in copyright notice.
(gdbserver_version): Update copyright year to 2022.
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
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.
(cherry picked from commit a619b58721)
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}.
(cherry picked from commit dd207c1302)
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 8f66807b98
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
This is a cherry pick of commit b622494ee3 with a minor edit
in gdb.server/ext-attach.exp to disable some tests that fail due to
unrelated bugs. Those unrelated bugs have been fixed in the master
branch.
gdb/ChangeLog:
PR gdb/28405
* remote.c (remote_target::remote_add_thread): Add new silent_p
argument, use as needed.
(remote_target::remote_notice_new_inferior): Pass additional
argument to remote_add_thread.
(remote_target::remote_notice_new_inferior): Likewise.
(extended_remote_target::attach): Call remote_add_thread instead
of add_thred_silent directly.
(remote_target::select_thread_for_ambiguous_stop_reply): Move
assert earlier, before we use the thing we're asserting is not
nullptr.
gdb/testsuite/ChangeLog:
PR gdb/28405
* gdb.server/ext-attach.exp (run_test): New proc containing all of
the old code for running the core of the test. This proc is then
called multiple times from the global scope.
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.
gdb/ChangeLog:
PR gdb/28480
* valops.c (struct_field_searcher::update_result): Improve
ambiguous member detection.
gdb/testsuite/ChangeLog:
PR gdb/28480
Pushed by Joel Brobecker <brobecker@adacore.com>
* gdb.cp/ambiguous.cc: Add code to permit ambiguous member testing.
* gdb.cp/ambiguous.exp: Add ambiguous member test.
(cherry picked from commit a41ad3474c)
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.
(cherry picked from commit 1c0e43634c)
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.
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.
gdb/ChangeLog:
2021-11-03 Luis Machado <luis.machado@linaro.org>
PR gdb/28355
* arch/aarch64.h (struct aarch64_features): New struct.
gdbserver/ChangeLog:
2021-11-03 Luis Machado <luis.machado@linaro.org>
PR gdb/28355
* linux-aarch64-low.cc (is_sve_tdesc): Remove.
(aarch64_target::low_arch_setup): Rework to adjust the register sets.
(aarch64_regsets): Update to list all register sets.
(aarch64_regsets_info, regs_info_aarch64): Replace NULL with nullptr.
(aarch64_sve_regsets, aarch64_sve_regsets_info)
(regs_info_aarch64_sve): Remove.
(aarch64_adjust_register_sets): New.
(aarch64_target::get_regs_info): Remove references to removed structs.
(initialize_low_arch): Likewise.
In commit 81e6b8eb20 "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 240edef62f "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
gdb/ChangeLog:
2021-10-22 Tom de Vries <tdevries@suse.de>
PR tui/28483
* tui/tui-winsource.c (tui_source_window_base::update_breakpoint_info):
Fix returns in loop body.
gdb/testsuite/ChangeLog:
2021-10-22 Tom de Vries <tdevries@suse.de>
PR tui/28483
* gdb.tui/break.exp: New file.
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
0bcda68539):
...
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 0bcda68539 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
gdb/ChangeLog:
2021-10-04 Tom de Vries <tdevries@suse.de>
PR build/28318
* ax_cxx_compile_stdcxx.m4: Add CXX_DIALECT to CXX.
* configure: Regenerate.
gdbserver/ChangeLog:
2021-10-04 Tom de Vries <tdevries@suse.de>
PR build/28318
* configure: Regenerate.
gdbsupport/ChangeLog:
2021-10-04 Tom de Vries <tdevries@suse.de>
PR build/28318
* configure: Regenerate.
/* Common target dependent code for GNU/Linux on PPC systems.
Copyright(C)2018-2021FreeSoftwareFoundation,Inc.
Copyright(C)2018-2022FreeSoftwareFoundation,Inc.
ThisfileispartofGDB.
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
