This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: MI: "^running" issues
On Thursday 06 September 2007 20:41:01 Vladimir Prus wrote:
> > Those are always bugs, and we fix them when we find them, but yes that
> > did happen - hasn't happened in a while though. What happens more
> > often now for us is that we rely a lot on calling functions to inspect
> > opaque data types when the target stops. This often goes bad - people
> > right data inspectors that can deadlock for instance... So it's
> > useful to have some "resync with gdb" action that check's gdb's state
> > and does the right thing based on what it is.
>
> You mean, calling functions in the program? Then, presumably if they
> hang, you get to interrupt their execution and somehow restore program
> context? Why do you need to know if inferior is running, in this case?
> As soon as you call a function in program, program is running ;-)
For a while. Then it may stop. Most times you get a notice. Sometimes
you don't. Sometimes (most notably gdb/cygwin) the notice gets mangled
with whatever output the called "data dumper function" produces and
it is no more recognizable by the "result parser". Sometimes "old" output
arrives after calling into the inferior.
Some of the scenarios might point to bugs in the Gui, some might not.
In any case, there are lots of reasons why one might want a method to
get absolute state information out of Gdb at "random" times.
> > > I presume this is only relevant when gdb is combined with some other
> > > code in the same process? Last time I've asked about this, I was
> > > told that it not supported, because gdb does fancy things with
> > > signals, or something like that.
It works well enough for simple cases. Most troubles I have had so far
is with memory allocation and result passing on Windows. So if one
manages to do the work without dynamic allocations and finds a way
that does not mangle "data dumper output" with ordinary gdb output,
the method is fairly robust. Most notably it also works when the data
dumper segfaults.
Of course, having a "real" interpreter within Gdb would be really nice...
Andre'