Simon Marchi [Thu, 24 Feb 2022 17:02:55 +0000 (09:02 -0800)]
gdb: clean up some things in features/Makefile
- 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.
Joel Brobecker [Sun, 16 Jan 2022 10:29:26 +0000 (14:29 +0400)]
Update copyright year in version output for gdb, gdbserver and gdbreplay
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.
Mike Frysinger [Sun, 3 Oct 2021 16:02:53 +0000 (12:02 -0400)]
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.
Andrew Burgess [Mon, 4 Oct 2021 14:48:11 +0000 (15:48 +0100)]
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 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.
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.
projects / thirdparty / binutils-gdb.git / log
