Re: [PATCH] Implement debugging of WOW64 processes

[Tom Tromey <tom@tromey.com>]

>>>>> "Hannes" == Hannes Domani via gdb-patches <gdb-patches@sourceware.org> writes:

Hannes> For WOW64 processes, the Wow64* variants of SuspendThread,
Hannes> GetThreadContext, SetThreadContext, and GetThreadSelectorEntry have to
Hannes> be used instead.
Hannes> And instead of EnumProcessModules, EnumProcessModulesEx with
Hannes> LIST_MODULES_32BIT is necessary.

I rebased my series to share some of the Windows code between gdb and
gdbserver over this patch.  I'm going to re-submit this shortly (I'm
testing it now).

That showed me that this patch modified gdb, but not gdbserver.  That's
fine; while we normally prefer parallel changes, I think we haven't
generally required it.

However, after some discussion on irc about this, I started wondering
again if we should move to a model where we always use gdbserver as the
back end.

This would remove any possibility of divergence -- there would only be a
single back-end for a given port.

This would mean porting gdbserver to more hosts.  I suppose we'd want to
keep the target stack as-is, to support core files and remote-sim.  This
is good in a way because it would mean less work to make the transition.

I looked through this:

    https://sourceware.org/gdb/wiki/LocalRemoteFeatureParity

and it looks like most of the items are done.

Tom