Automatic date update in version.in

Automatic date update in version.in

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

This is a cherry pick of commit b622494ee378fd0a490 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.

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

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.

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 a41ad3474ceacba39e11c7478154c0e553784a01)

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

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.

(cherry picked from commit 1c0e43634cfdd0ad7ef9ac3dd7d208dddeb80f5e)

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

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.

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

[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.

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.

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

[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

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.

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

[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

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.

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in