Files
binutils-gdb/gdb/process-stratum-target.h
Andrew Burgess 1b28027e89 gdb: some process_stratum_target should not be shared
When multi-target support was added to GDB, an assumption was made
that all process_stratum_target sub-classes could be shared by
multiple inferiors.

For things like the Linux and FreeBSD native targets, this is
absolutely true (or was made true).  But some targets were either not
updated, or, due to design restrictions, cannot be shared.

This patch adds a target_ops::is_shareable member function.  When this
returns false then this indicates that an instance of a particular
target should only appear on a single target stack.  It is fine for
difference instances of a single target type to appear on different
target stacks though.

This is my second attempt at this patch.  The first attempt can be
found here:

  https://inbox.sourceware.org/gdb-patches/577f2c47793acb501c2611c0e6c7ea379f774830.1668789658.git.aburgess@redhat.com

The initial approach was to have all targets be shareable by default,
and to then mark those targets which I knew were problematic.
Specifically, the only target I was interested in was core_target,
which cannot be shared (details below).  During review Tom pointed out:

  I think there are a lot of other targets that can't be
  shared... remote-sim, all the trace targets, even I think windows-nat,
  since it isn't multi-inferior-capable yet.

The suggestion was that the default should be that targets were NOT
shareable, and we should then mark those targets which we know can be
shared.  That is the big change in this iteration of the patch.

The core_target is still non-shareable.  This target stores state
relating to the open core file in the core_target and in the current
inferior's program_space.  After an 'add-inferior' command, if we
share the core_target, the new inferior will have its own
program_space, but will share the core_target with the original
inferior.  This leaves the new inferior in an unexpected state where
the core BFD (from the new program_space) is NULL.  Attempting to make
use of the second inferior, e.g. to load a new executable, will (on
x86 at least) cause GDB to crash as it is not expecting the core BFD
to be NULL.

I am working to move the core file BFD into core_target, at which
point it might be possible to share the core_target, though I'm still
not entirely sure this makes sense; loading a core file will in many
cases, automatically set the executable in the program_space, creating
a new inferior would share the core_target, but the new inferior's
program space would not have the executable loaded.  But I figure we
can worry about this another day because ....

As Tom pointed out in his review of V1, there are other targets that
should be non-shareable (see quote above).  In addition, I believe
that the remote target can only be shared in some specific situations,
the 'add-inferior' case is one where the 'remote' target should NOT be
shared.

The 'remote' (not 'extended-remote') target doesn't allow new
inferior's to be started, you need to connect to an already running
target.  As such, it doesn't really make sense to allow a 'remote'
target to be shared over an 'add-inferior' call, what would the user
do with the new inferior?  They cannot start a new process.  They're
not debugging the same process as the original inferior.  This just
leaves GDB in a weird state.

However, 'remote' targets are a little weird in that, if the remote
inferior forks, and GDB is set to follow both the parent and the
child, then it does make sense to allow sharing.  In this case the new
inferior is automatically connected to the already running child
process.

So when we consider 'add-inferior' there are two things we need to
consider:

  1. Can the target be shared at all?  The new target_ops::is_shareable
     function tells us this.

  2. Can the target be used to start a new inferior?  The existing
     target_ops::can_create_inferior function tells us this.

If the process_stratum_target returns true for both of these functions
then it is OK to share it across an 'add-inferior' call.  If either
returns false then the target should not be shared.

When pushing a target onto an inferior's target stack, we only need to
consider target_ops::is_shareable, only shareable targets should be
pushed onto multiple target stacks.

The new target_ops::is_shareable function returns true as its default,
all the immediate sub-classes are shareable.

However, this is overridden in process_stratum_target::is_shareable, to
return false.  All process_stratum_target sub-classes are non-shareable
by default.

Finally, linux_nat_target, fbsd_nat_target, and remote_target, are all
marked as shareable.  This leaves all other process_stratum_target
sub-classes non-shareable.

I did some very light testing on Windows, and I don't believe that this
target supports multiple inferiors, but I could easily be wrong here.
My windows testing setup is really iffy, and I'm not 100% sure if I did
this right.

But for the Windows target, and any of the others, if this commit breaks
existing multi-inferior support, then the fix is as simple as adding an
is_shareable member function that returns true.

If the user tries to 'add-inferior' from an inferior with a
non-shareable target, or the 'remote' target as it cannot start new
inferiors, then they will get a warning, and the new inferior will be
created without a connection.

If the user explicitly asks for the new inferior to be created without
a connection, then no warning will be given.

At this point the user is free to setup the new inferior connection as
they see fit.

I've updated the docs, and added a NEWS entry for the new warning.  In
the docs for clone-inferior I've added reference to -no-connection,
which was previously missing.

Some tests needed fixing with this change, these were
gdb.base/quit-live.exp, gdb.mi/mi-add-inferior.exp,
gdb.mi/new-ui-mi-sync.exp, and gdb.python/py-connection-removed.exp.  In
all cases, when using the native-gdbserver board, these tests tried to
create a new inferior, and expected the new inferior to start sharing
the connection with the original inferior.  None of these tests actually
tried to run anything in the new inferior, if they did then they would
have discovered that the new inferior wasn't really sharing a
connection.  All the tests have been updated to understand that for
'remote' connections (not 'extended-remote') the connection will not be
shared.  These fixes are all pretty simple.

Approved-By: Tom Tromey <tom@tromey.com>
2025-09-30 14:18:31 +01:00

182 lines
7.1 KiB
C++

/* Abstract base class inherited by all process_stratum targets
Copyright (C) 2018-2025 Free Software Foundation, Inc.
This file is part of GDB.
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 3 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program. If not, see <http://www.gnu.org/licenses/>. */
#ifndef GDB_PROCESS_STRATUM_TARGET_H
#define GDB_PROCESS_STRATUM_TARGET_H
#include "target.h"
#include "gdbsupport/gdb-checked-static-cast.h"
#include "gdbsupport/unordered_set.h"
#include "gdbthread.h"
/* Abstract base class inherited by all process_stratum targets. */
class process_stratum_target : public target_ops
{
public:
~process_stratum_target () override = 0;
strata stratum () const final override { return process_stratum; }
/* Return a string representation of this target's open connection.
This string is used to distinguish different instances of a given
target type. For example, when remote debugging, the target is
called "remote", but since we may have more than one remote
target open, connection_string() returns the connection serial
connection name, e.g., "localhost:10001", "192.168.0.1:20000",
etc. This string is shown in several places, e.g., in "info
connections" and "info inferiors". */
virtual const char *connection_string () { return nullptr; }
/* We must default these because they must be implemented by any
target that can run. */
bool can_async_p () override { return false; }
bool supports_non_stop () override { return false; }
bool supports_disable_randomization () override { return false; }
/* This default implementation always returns the current inferior's
gdbarch. */
struct gdbarch *thread_architecture (ptid_t ptid) override;
/* Default implementations for process_stratum targets. Return true
if there's a selected inferior, false otherwise. */
bool has_all_memory () override;
bool has_memory () override;
bool has_stack () override;
bool has_registers () override;
bool has_execution (inferior *inf) override;
/* Default implementation of follow_exec.
If the current inferior and FOLLOW_INF are different (execution continues
in a new inferior), push this process target to FOLLOW_INF's target stack
and add an initial thread to FOLLOW_INF. */
void follow_exec (inferior *follow_inf, ptid_t ptid,
const char *execd_pathname) override;
/* Default implementation of follow_fork.
If a child inferior was created by infrun while following the fork
(CHILD_INF is non-nullptr), push this target on CHILD_INF's target stack
and add an initial thread with ptid CHILD_PTID. */
void follow_fork (inferior *child_inf, ptid_t child_ptid,
target_waitkind fork_kind, bool follow_child,
bool detach_on_fork) override;
/* Assume sub-classes are not shareable. Those that are need to mark
themselves as such. */
bool is_shareable () override
{ return false; }
/* True if any thread is, or may be executing. We need to track
this separately because until we fully sync the thread list, we
won't know whether the target is fully stopped, even if we see
stop events for all known threads, because any of those threads
may have spawned new threads we haven't heard of yet. */
bool threads_executing = false;
/* If THREAD is resumed and has a pending wait status, add it to the
target's "resumed with pending wait status" list. */
void maybe_add_resumed_with_pending_wait_status (thread_info *thread);
/* If THREAD is resumed and has a pending wait status, remove it from the
target's "resumed with pending wait status" list. */
void maybe_remove_resumed_with_pending_wait_status (thread_info *thread);
/* Return true if this target has at least one resumed thread with a pending
wait status. */
bool has_resumed_with_pending_wait_status () const
{ return !m_resumed_with_pending_wait_status.empty (); }
/* Return a random resumed thread with pending wait status belonging to INF
and matching FILTER_PTID. */
thread_info *random_resumed_with_pending_wait_status
(inferior *inf, ptid_t filter_ptid);
/* Search function to lookup a (non-exited) thread by 'ptid'. */
thread_info *find_thread (ptid_t ptid);
/* The connection number. Visible in "info connections". */
int connection_number = 0;
/* Whether resumed threads must be committed to the target.
When true, resumed threads must be committed to the execution
target.
When false, the target may leave resumed threads stopped when
it's convenient or efficient to do so. When the core requires
resumed threads to be committed again, this is set back to true
and calls the `commit_resumed` method to allow the target to do
so.
To simplify the implementation of targets, the following methods
are guaranteed to be called with COMMIT_RESUMED_STATE set to
false:
- resume
- stop
- wait
Knowing this, the target doesn't need to implement different
behaviors depending on the COMMIT_RESUMED_STATE, and can simply
assume that it is false.
Targets can take advantage of this to batch resumption requests,
for example. In that case, the target doesn't actually resume in
its `resume` implementation. Instead, it takes note of the
resumption intent in `resume` and defers the actual resumption to
`commit_resumed`. For example, the remote target uses this to
coalesce multiple resumption requests in a single vCont
packet. */
bool commit_resumed_state = false;
private:
/* List of threads managed by this target which simultaneously are resumed
and have a pending wait status.
This is done for optimization reasons, it would be possible to walk the
inferior thread lists to find these threads. But since this is something
we need to do quite frequently in the hot path, maintaining this list
avoids walking the thread lists repeatedly. */
thread_info_resumed_with_pending_wait_status_list
m_resumed_with_pending_wait_status;
};
/* Downcast TARGET to process_stratum_target. */
static inline process_stratum_target *
as_process_stratum_target (target_ops *target)
{
gdb_assert (target->stratum () == process_stratum);
return gdb::checked_static_cast<process_stratum_target *> (target);
}
/* Return a collection of targets that have non-exited inferiors. */
extern gdb::unordered_set<process_stratum_target *>
all_non_exited_process_targets ();
/* Switch to the first inferior (and program space) of TARGET, and
switch to no thread selected. */
extern void switch_to_target_no_thread (process_stratum_target *target);
#endif /* GDB_PROCESS_STRATUM_TARGET_H */