Re: GDB/MI - Possible missing stop-reason on attach or misleading documentation

[Simon Marchi <simark@simark.ca>]

On 2022-03-03 03:35, Simon Sobisch via Gdb wrote:
> When attaching to a running progress (that currently "waits" in `getchar()`, but that likely doesn't matter) in async mode the following records are returned:
>
> =thread-group-started,id="i1",pid="12345"
> =thread-created,id="1",group-id="i1"
> =library-loaded,id=... many entries
> ~"0x00007fa0a626b7e0 in __read_nocancel () from /usr/lib64/libc.so.6\n"
> *stopped,frame={addr="0x00007fa0a626b7e0",func="__read_nocancel",args=[],from="/usr/lib64/libc.so.6",arch="i386:x86-64"},thread-id="1",stopped-threads="all",core="1"
>
> My understanding from
> https://sourceware.org/gdb//onlinedocs/gdb/GDB_002fMI-Async-Records.html was that the reason field is _always_ returned.
>
> Questions:
> * Did I look at the right place of the docs?

I think so.

> * Are all fields listed there should always be filled?

If it doesn't say otherwise, yes.  This looks like a bug.

>   If not I highly suggest to add a note about that.
> * Can the reason field be added in the attach case? I _guess_ that would
>   be either "location-reached" or "breakpoint-hit".

Or signal-received, same as you get when GDB interrupts a running thread
after the user does ^C.  It depends on the status the target returns.
Attaching is kind of like the user requesting the attached process to
stop.

Simon