This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: MI attach stop reason


On 04/30/2013 04:30 PM, Andrew Burgess wrote:
> At the end of the email is a trace for a simple test of attaching to an
> already running process using the MI interface using the "-target-attach
> <pid>" command syntax.
> 
> After sending the -target-attach gdb replies with a "*stopped" message,
> this seems fine, however, there's no reason field given.

What do you need it for, btw?  What is the problem you're trying to solve?
It was my understanding that when frontends see a *stopped with no
particular reason attached, that they will just refresh all their
inferior-related state, which is something they'd need to do anyway
after an attach.

> Now, obviously, the reason for the stop is the attach, however, it seems
> like including a reason field would provide a more consistent interface, do
> folk generally agree or disagree with this?

I'd rather just report a stop as if we'd used "interrupt" to
pause the target, in non-stop mode.  That means reporting signal-received,
with signal 0, indicating inferior/thread was just quietly quiesced:

  *stopped,reason="signal-received",signal-name="0",signal-meaning="Signal 0",frame={addr="0x0000003d25eba6ed",func="nanosleep",args=[],from="/lib64/libc.so.6"},thread-id="3",stopped-threads=["3"],core="0"

(Attaching may actually result in reporting some real signal,
see attach-into-signal.exp.)

> 
> Next I had a look down the reason list that's here:
> 
>   http://sourceware.org/gdb/current/onlinedocs/gdb/GDB_002fMI-Async-Records.html
> 
> and I think there are only two options, one would be to reuse the
> "signal-received" reason, though I'm not sure this is great, 

We already use signal 0 to indicate "stopped because gdb wanted the
thread to pause, no matter how that's implemented behind the scenes
in the target backend.  E.g., on Linux/ptrace, w/ non-stop, pausing a thread
is implemented with sending SIGSTOPs currently, but the frontend
doesn't see that, it just sees a stop with signal 0.

> or I could add a new reason "attached".

I'm not off-hand seeing a case where having a new stop-reason would
help disambiguate.  It's either

"attach" -> "stopped for some noteworthy event"

or

"attach" -> "stopped for no other reason than GDB quiescing the target/thread"

and we have these covered already.

The main reason I'm hesitant with adding an attach stop reason, is
with attaching to multi threaded programs, in an async/non-stop world,
where we may want to report a stop for each thread found, like
when connecting to a remote target in non-stop mode.  Such a stop
reason would make this somewhat more complicated, for needing to track
extra state in threads the core doesn't even know about.

Thanks,
-- 
Pedro Alves


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]