Re: The 'x' command: size problem

[Vladimir Prus <ghost@cs.msu.su>]

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