> > Looking at how it works on Linux, it's the process stratum,
> > inf_ptrace_target, that answers this request.  On Windows, shouldn't
> > windows_nat_target answer this request?  After all, it's the
> > responsibility of windows_nat_target to communicate with the Windows
> > OS to debug processes natively on it.
> 
> Yeah, it's just that the Windows port doesn't really implement the
> feature at all, AFAICT.  Ideally it'd be implemented.  Otherwise,
> I guess handling the case of not having a target beneath
> here is reasonable.
> > 
> >> Also, The testcase I am proposing fails on the -list-thread-groups test
> >> when run on GNU/Linux because, on that platform, the command returns
> >> more output than the expect buffer can handle, resulting in an UNRESOLVED
> >> status. How does one usually handle this? The only why I can think of
> >> is a loop of gdb_test_multiple... Other ideas?
[...]
> Yeah, the best way to address this is to consume
> output in chunks, with exp_continue.  That fixes it for good.
> See for example:
> 
> commit 11859c310cd6b6fd892337a5ee1d36921e6d08d8

Thanks for the pointer. I've taken the liberty of updating our
testcase cookbook to reference it as well, so we know where to
look next time we hit that issue.

Attached is an updated version which follows the same principle.

gdb/ChangeLog:

        * windows-nat.c (windows_nat_target::xfer_partial): Return
        TARGET_XFER_E_IO if we need to delegate to the target beneath
        but BENEATH is NULL.

gdb/testsuite/ChangeLog:

        * gdb.mi/mi-list-thread-groups-no-inferior.exp: New testcase.

Test verified on x86_64-linux to confirm that the large amount of
output is properly handled.

OK to push?
-- 
Joel