public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: Phil Muldoon <pmuldoon@redhat.com>
To: Kevin Pouget <kevin.pouget@gmail.com>
Cc: gdb@sourceware.org
Subject: Re: GDB Python API: stop/continue after breakpoint
Date: Wed, 20 Apr 2011 15:15:00 -0000	[thread overview]
Message-ID: <m3bp01ar9l.fsf@redhat.com> (raw)
In-Reply-To: <BANLkTikdOZEf4_85TA=Aj8+zBmPGX8-sBw@mail.gmail.com> (Kevin	Pouget's message of "Wed, 20 Apr 2011 10:58:46 -0400")

Kevin Pouget <kevin.pouget@gmail.com> writes:

> Hello,
>
> I'm coming back to this post because I've got a bit of an issue here:
>
> basically, I need (and I'm looking for to helping for it!) a sharp
> control of the inferior execution from the python interface, but I'm
> facing some limitations:
>
> * in MyBreakpoint.stop(), I can say continue/stop the inferior, but I
> can't run "finish" (or "next" or what ever, I guess), because the
> inferior is still considered as running:
>> "gdb.error: Cannot execute this command while the selected thread is running."

At this point GDB is deciding whether to stop the inferior and
return control to the console or not.  (Really, at this point, the
inferior is stopped, by ptrace, but GDB is trying to work out if it
should really maintain the stop, or resume the inferior).  So in GDB's
internal data store, the inferior (thread) is still "running" and will
be so until a firm stop decision is reached.  Because of this
intermediate state, you cannot issue cannot step/next/continue/finish or
other inferior control commands.  This is really a very simplistic view
of what is going on.  I've glossed over a lot.


> * in event.stop.connect() that's possible, but I can't
> `gdb.execute("continue")' the execution because I would miss any
> "non-python" reasons to stop (ie, a user-breakpoint, a signal ...)

The only thing I can think to do here is set some of your own data in
your Python module.  Breakpoint.stop sets some flag or data, and the
event.connect can pick up on that. But there are gaps in the API.  File
bugs, I look there daily. 

I hope this helped some!

Cheers,

Phil

  reply	other threads:[~2011-04-20 15:15 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-11 16:09 Kevin Pouget
2011-03-11 16:25 ` Phil Muldoon
     [not found]   ` <AANLkTin_a87WgchmZnzi9_XX4DXh8q-r3P7EyyDAzTA4@mail.gmail.com>
2011-03-11 17:52     ` Kevin Pouget
2011-04-20 14:59       ` Kevin Pouget
2011-04-20 15:15         ` Phil Muldoon [this message]
2011-04-20 15:39         ` Tom Tromey
2011-04-21 13:01           ` Kevin Pouget
     [not found]             ` <BANLkTinwMfsxA24q-5ekbapVdM_OP6rOsQ@mail.gmail.com>
2011-04-21 14:32               ` Kevin Pouget
2011-04-20 15:20       ` Tom Tromey
2011-03-21 14:20   ` Kevin Pouget
2011-03-21 14:39     ` Phil Muldoon
2011-03-21 15:11       ` Kevin Pouget

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m3bp01ar9l.fsf@redhat.com \
    --to=pmuldoon@redhat.com \
    --cc=gdb@sourceware.org \
    --cc=kevin.pouget@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).