This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: The 'x' command: size problem
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