public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
* GDB/MI - Possible missing stop-reason on attach or misleading documentation
@ 2022-03-03  8:35 Simon Sobisch
  2022-03-03 15:44 ` Simon Marchi
  0 siblings, 1 reply; 2+ messages in thread
From: Simon Sobisch @ 2022-03-03  8:35 UTC (permalink / raw)
  To: gdb discussion list

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?
* Are all fields listed there should always be filled?
   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".

Simon

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: GDB/MI - Possible missing stop-reason on attach or misleading documentation
  2022-03-03  8:35 GDB/MI - Possible missing stop-reason on attach or misleading documentation Simon Sobisch
@ 2022-03-03 15:44 ` Simon Marchi
  0 siblings, 0 replies; 2+ messages in thread
From: Simon Marchi @ 2022-03-03 15:44 UTC (permalink / raw)
  To: Simon Sobisch, gdb discussion list

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

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2022-03-03 15:44 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-03-03  8:35 GDB/MI - Possible missing stop-reason on attach or misleading documentation Simon Sobisch
2022-03-03 15:44 ` Simon Marchi

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).