Re: The 'x' command: size problem

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

Daniel Jacobowitz wrote:

> On Tue, Sep 06, 2005 at 07:35:12PM +0400, Vladimir Prus wrote:
>> No, it's not very hard. But given anynchronious nature of communication
>> with gdb I'm trying to limit the number of queries to minimum, to
>> minimize the amount of data I have to keep.
> 
> The MI data stream is basically synchronous.  Sure, there are
> asynchronous notifications in it.  But a synchronous reply always
> corresponds to the previously implemented synchronous command, doesn't
> it?  It's serialized, so if you have a lot of different threads wanting
> to bang away at GDB, sure you're going to need some bookkeeping.

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.

>> <aside>
>> I might be wrong, but I feel it would be much better if gdb were a
>> library that I could link to. That would eliminate most anynchonious
>> communication and won't require to keep track which gdb reply corresponds
>> to which previously issued command and where the result of the command
>> must be sent inside the frontend.
>> </aside>
> 
> 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.

> And GDB does some fairly complicated things using 
> signals and wait, which can yield very surprising behavior if you're
> running it in the same context as your GUI.

Can't comment on this. 

> 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.

- Volodya