This is the mail archive of the 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: [RFC - Python] New ObjFile event & GDB Async

On Thu, Sep 1, 2011 at 1:00 PM, Kevin Pouget <> wrote:
> On Thu, Sep 1, 2011 at 12:18 PM, Eli Zaretskii <> wrote:
>>> From: Kevin Pouget <>
>>> Date: Thu, 1 Sep 2011 11:17:51 +0200
>>> Cc:,
>>> ?This event indicates that the inferior or one of its threads has received as
>>> ?signal. ?@code{gdb.SignalEvent} has the following attributes:
>>> +@item events.newobjfile
>>> +Emits @code{gdb.NewObjFileEvent} which indicates that a new object-file has
>>> +been loaded by @value{GDBN}.
>>> +
>>> +During the callback, ``current objfile'' will be set to the new object file.
>>> +
>>> ?@table @code
>>> ?@defivar SignalEvent stop_signal
>>> ?A string representing the signal received by the inferior. ?A list of possible
>>> @@ -22949,10 +22955,10 @@ The following objfile-related functions are available in the
>> The addition doesn't look right: shouldn't it be _after_ the following
>> @table line? ?events.newobjfile is an attribute of the same object as
>> stop_signal, right?
> sorry; I moved the paragraph to the right place.
>>> +When auto-loading a Python script (@pxref{Auto-loading}) and during new
>>> +object-file callbacks, @value{GDBN} sets the ``current objfile'' to the
>> Why did you use "new" here? ?New in relation to what?
> "new" here refers to object-file, but I'm not sure I can write "during
> new-object-file callbacks", can I?
> I also added a label reference to make things clearer here:
>> During the callback, ``current objfile'' will be set to the new object file
>> (@pxref{Objfiles In Python}).
> (I'm not sure why there is no `_' between 'current' and 'objfile', I
> copied it from another place --- @value{GDBN} sets the ``current
> objfile'' to the
> corresponding objfile.)
> Kevin


A new problem showed up with this patch, which make it crash certainly
because of the async mode.

(the patch intends to provide a Python binding for the 'new
objectfile' observer. There's nothing complicated in the code, just
emit a new event upon observer notification, which triggers the Python
function registered for this event)

However, when I want to execute `gdb.execute("some function")` during
the callback, the execution ends up in:

#0  0x... in poll () from /lib64/
#1  0x... in gdb_wait_for_event (block=1)    at gdb/event-loop.c:864
#2  0x... in gdb_do_one_event ()    at gdb/event-loop.c:462
#3  0x... in execute_command (p=0x1bd5e2c "off", from_tty=0)    at
#4  0x... in execute_gdb_command (self=0x0, args=0x..., kw=0x0)    at
#5 ... python backtrace

because of this condition in top.c:
// gdb.execute("some function") was "set confirm off"
// interpreter_async = 0
// sync_execution = 1
450	      if (!interpreter_async && sync_execution)
451		{
452		  while (gdb_do_one_event () >= 0)
453		    if (!sync_execution)
454		      break;

This is in opposition with the 'stop' event where every thing is ok and
// interpreter_async = 0
// sync_execution = 0

I hope you'll understand the situation, do you know if there is any
'easy' way to solve that?

Many thanks,


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