This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: The 'x' command: size problem
On Wednesday 07 September 2005 17:13, Daniel Jacobowitz wrote:
> On Wed, Sep 07, 2005 at 10:53:34AM +0400, Vladimir Prus wrote:
> > By "asynchronous" I mean that after sending a command to gdb, I can't
> > just immediately get the result. I need to return to Qt message loop and
> > wait why gdb reply is sent to my object. So, instead of:
> >
> > unsigned size = gdb_eval("sizeof(g)");
> >
> > I need to add another method to my class that will be called when result
> > of "sizeof" arrives, and this complicates the implementation quite a bit.
>
> This is a problem people have solved a thousand times...
Yes, and I've solved it too today, so that gives 1001 times. But the solution
is not pretty, and if 'x' allowed expression in both parameters I would not
need it. The same issue is in MI:
-data-read-memory &i b 1 1 sizeof(i)
does not work, while
-data-read-memory &i x 1 1 4
works fine. Is it's hard to evaluate 'num-column' argument as expression?
And BTW, docs don't even mention this restriction in MI.
> > > And it'll give you a whole new host of issues keeping up with the
> > > changing interface.
> >
> > But at least (assuming the interface is a nice C++ one), something like:
> >
> > get_memory(std::vector<char>& c)
> >
> > is crystal clear, while documentation of MI's -data-read-memory output
> > format is very unclear. It does not document what's "table", or "next
> > page" is and does not link to any definitions of those terms.
>
> Please, then, feel free to improve the documentation.
Oh.. if only it were in Docbook :-(
Besides, how can I improve documentation if I don't know definitions of those
terms, to begin with?
> Really, a C++
> interface would be just as complicated. Even in your example. Where
> would you get the memory from? How much would you get?
Ok, the real interface would be:
void get_memory(unsigned address, unsigned amount_in_bytes,
vector<char>& result)
> What would it do on errors?
Well, though a type defined from gdb_exception. I think think the above
prototype is clearer, and much shorter that documentation for
-data-read-memory, that does not even documents everything.
> > > I don't see how it would eliminate the need for asynchronous
> > > interfaces, either.
> >
> > I'd be talking with gdb in a separate thread. At least in Qt4, it will be
> > possible to send requests from GUI thread to debugger controller thread,
> > fully transparently. For Qt3, I'd implement such
> > across-threads-command-queue myself.
>
> Then you're going to need to asynchronously wait for the gdb thread to
> return data to your GUI thread. If you're willing to block waiting for
> that, then block waiting for GDB to print output!
No, I don't think that's needed. Say, user ask for a value of variable. GUI
thread invokes a method in gdb controller thread (across thread boundary).
The gdb controller gets all the necessary data by synchnonious calls to gdb
library and when done, does cross-thread call to GUI thread, saying "add var
foo with value 10" to the list of variables. No need to block anything.
- Volodya