Re: [RFC] (windows) GDB/MI crash when using "-list-thread-groups --available"

[Simon Marchi <simon dot marchi at polymtl dot ca>]

On 2018-05-10 14:58, Joel Brobecker wrote:
> Hello,
>
> On Windows, using the "-list-thread-groups --available" GDB/MI command
> before an inferior is being debugged:
>
>     % gdb -q -i=mi
>     =thread-group-added,id="i1"
>     =cmd-param-changed,param="auto-load safe-path",value="/"
>     (gdb)
>     -list-thread-groups --available
>     Segmentation fault
>
> Ooops!
>
> The SEGV happens because the -list-thread-groups --available command
> triggers a windows_nat_target::xfer_partial call for a 
> TARGET_OBJECT_OSDATA
> object.  Until a program is being debugged, the target_ops layer that
> gets the call is the Windows "native" layer. Except for a couple of
> specific objects (TARGET_OBJECT_MEMORY and TARGET_OBJECT_LIBRARIES),
> this layer's xfer_partial method delegates the xfer of other objects
> to the target beneath:
>
>     default:
>       return beneath->xfer_partial (object, annex,
>                                     readbuf, writebuf, offset, len,
>                                     xfered_len);
>
> Unfortunately, there is no "beneath layer" in this case, so
> beneath is NULL and dereferencing it leads to the SEGV.
>
> This patch fixes the issue by checking beneath before trying
> to delegate the request. But I am wondering whether this is
> the right place to fix this issue, or whether we should expect
> BENEATH to never be NULL. Ideas?

So when an inferior is started, "-list-thread-groups --available" works 
correctly on Windows?  What is the target beneath then, which provides 
the list of available processes on Windows?

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.

> 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?

What's the difference between the new test case and 
gdb.mi/list-thread-groups-available.exp?  In that one too, 
-list-thread-groups --available is executed with no inferior started.  
It also uses mi_gdb_test though, so it probably hits the same 
limitation.

As a quick and dirty hack, is it possible to just increase temporarily 
the size of the buffer to something that will surely be large enough?  
Otherwise, using gdb_test_multiple or maybe gdb_expect to consume the 
output little by little sounds good.

Simon