The 'x' command: size problem

The 'x' command: size problem

[Vladimir Prus]

Hello!

Suppose I want to print, in binary, content of some large object (for
example, network packet header).

I can use this:

   x /154 &packet

Assuming 154 is the size of the object, but neither:

   x /sizeof(packet) &packet

nor

   set $size = sizeof(packet)
   x /$size &packet

works. In fact, the x_command function in printcmd.c expects the the size
argument be always given as literal.

This limitation makes it somewhat harder to implement "show this
variable/expression in binary" command in a GUI. Are there any easy
workarounds?

- Volodya

Re: The 'x' command: size problem

[Daniel Jacobowitz]

On Tue, Sep 06, 2005 at 07:00:28PM +0400, Vladimir Prus wrote:
> works. In fact, the x_command function in printcmd.c expects the the size
> argument be always given as literal.
> 
> This limitation makes it somewhat harder to implement "show this
> variable/expression in binary" command in a GUI. Are there any easy
> workarounds?

Not as far as I know.  But you're in a GUI, i.e. hopefully something
with logic and capable of parsing GDB's responses.  Is it really that
hard to get the size and print out the right bytes?

-data-evaluate-expression "sizeof(i)"
^done,value="4"
(gdb)

-data-read-memory "&i" t 1 1 4
^done,addr="0xbf82ec04",nr-bytes="4",total-bytes="4",next-row="0xbf82ec08",prev-row="0xbf82ec00",next-page="0xbf82ec08",prev-page="0xbf82ec00",memory=[{addr="0xbf82ec04",data=["10011100","01011110","11101111","10110111"]}]
(gdb)

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: The 'x' command: size problem

[Vladimir Prus]

On Tuesday 06 September 2005 19:06, Paul Koning wrote:
> p/x packet
>
> will do the job.
>
> Or if you need to refer to some hex address and interpret it as the
> data:
>
> 	p/x *(struct packet *) 0x12342324

Good, but:

1. The output format of 'p' is very different from that of 'x'.
Given that I use 'x' for general case of 'print 1000 bytes starting at 
0x12345678', I'll have to detect when to use 'p', and when to parse output of 
'p', not output of 'x'.

2. What if user wants to see 5*sizeof(packet) bytes of memory from a given 
address?

   p/x (*(packet*)0x12345678)@5

will work but would require extra code to get that from "5*sizeof(packet)", 
would require extra code to parse output, and what about even more complex 
case of "sizeof(first_packet) + 5*sizeof(packet)"?

- Volodya

Re: The 'x' command: size problem

[Vladimir Prus]

On Tuesday 06 September 2005 19:24, Daniel Jacobowitz wrote:
> On Tue, Sep 06, 2005 at 07:00:28PM +0400, Vladimir Prus wrote:
> > works. In fact, the x_command function in printcmd.c expects the the size
> > argument be always given as literal.
> >
> > This limitation makes it somewhat harder to implement "show this
> > variable/expression in binary" command in a GUI. Are there any easy
> > workarounds?
>
> Not as far as I know.  But you're in a GUI, i.e. hopefully something
> with logic and capable of parsing GDB's responses.  Is it really that
> hard to get the size and print out the right bytes?
>
> -data-evaluate-expression "sizeof(i)"
> ^done,value="4"
> (gdb)
>
> -data-read-memory "&i" t 1 1 4
> ^done,addr="0xbf82ec04",nr-bytes="4",total-bytes="4",next-row="0xbf82ec08",
>prev-row="0xbf82ec00",next-page="0xbf82ec08",prev-page="0xbf82ec00",memory=[
>{addr="0xbf82ec04",data=["10011100","01011110","11101111","10110111"]}]
> (gdb)

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.

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

- Volodya

Re: The 'x' command: size problem

[Daniel Jacobowitz]

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.

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

I don't see how it would eliminate the need for asynchronous
interfaces, either.

I still think the MI communication model we've evolved is the best
choice.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: The 'x' command: size problem

[Eli Zaretskii]

> Date: Tue, 6 Sep 2005 11:24:48 -0400
> From: Daniel Jacobowitz <drow@false.org>
> Cc: gdb@sources.redhat.com
> 
> On Tue, Sep 06, 2005 at 07:00:28PM +0400, Vladimir Prus wrote:
> > works. In fact, the x_command function in printcmd.c expects the the size
> > argument be always given as literal.
> > 
> > This limitation makes it somewhat harder to implement "show this
> > variable/expression in binary" command in a GUI. Are there any easy
> > workarounds?
> 
> Not as far as I know.

Is that a bug, and if so, should we fix it ASAP?

Re: The 'x' command: size problem

[Daniel Jacobowitz]

On Tue, Sep 06, 2005 at 10:16:56PM +0300, Eli Zaretskii wrote:
> > Date: Tue, 6 Sep 2005 11:24:48 -0400
> > From: Daniel Jacobowitz <drow@false.org>
> > Cc: gdb@sources.redhat.com
> > 
> > On Tue, Sep 06, 2005 at 07:00:28PM +0400, Vladimir Prus wrote:
> > > works. In fact, the x_command function in printcmd.c expects the the size
> > > argument be always given as literal.
> > > 
> > > This limitation makes it somewhat harder to implement "show this
> > > variable/expression in binary" command in a GUI. Are there any easy
> > > workarounds?
> > 
> > Not as far as I know.
> 
> Is that a bug, and if so, should we fix it ASAP?

Personally, I don't think it's a bug.

It can't unambiguously accept x/sizeof(i), because of x/s.  I suppose
we could allow convenience variables here, but I don't think the
benefit is substantial.  For a frontend, it shouldn't be hard to find
the right size as a literal.  For a user, ditto.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: The 'x' command: size problem

[Vladimir Prus]

Daniel Jacobowitz wrote:

> On Tue, Sep 06, 2005 at 10:16:56PM +0300, Eli Zaretskii wrote:
>> > Date: Tue, 6 Sep 2005 11:24:48 -0400
>> > From: Daniel Jacobowitz <drow@false.org>
>> > Cc: gdb@sources.redhat.com
>> > 
>> > On Tue, Sep 06, 2005 at 07:00:28PM +0400, Vladimir Prus wrote:
>> > > works. In fact, the x_command function in printcmd.c expects the the
>> > > size argument be always given as literal.
>> > > 
>> > > This limitation makes it somewhat harder to implement "show this
>> > > variable/expression in binary" command in a GUI. Are there any easy
>> > > workarounds?
>> > 
>> > Not as far as I know.
>> 
>> Is that a bug, and if so, should we fix it ASAP?
> 
> Personally, I don't think it's a bug.
> 
> It can't unambiguously accept x/sizeof(i), because of x/s.  I suppose
> we could allow convenience variables here, but I don't think the
> benefit is substantial.  For a frontend, it shouldn't be hard to find
> the right size as a literal.  For a user, ditto.

By the same argumentation, it should not be too hard to find the address, so
'x' should accept literal address only, that is:

   x/4 &g

should be disallowed and user will be required to write:

   print &g
   x/4 0xWHATEVER

It's a bit inconsistent that arbitrary expression is allowed to address, but
not for size.

- Volodya

 

Re: The 'x' command: size problem

[Vladimir Prus]

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

Re: The 'x' command: size problem

[Daniel Jacobowitz]

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

> > 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.  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?  What would it
do on errors?

> > 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!  Really, it takes
about the same amount of time.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: The 'x' command: size problem

[Vladimir Prus]

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

Re: The 'x' command: size problem

[Eli Zaretskii]

> From: Vladimir Prus <ghost@cs.msu.su>
> Date: Wed, 7 Sep 2005 17:42:11 +0400
> 
> > Please, then, feel free to improve the documentation.  
> 
> Oh.. if only it were in Docbook :-(

Don't worry about that: if you don't know Texinfo, write in English
and I will add the Texinfo markup (it's a rather trivial mechanical
job).

> Besides, how can I improve documentation if I don't know definitions of those
> terms, to begin with?

Well, perhaps if you look into the relevant MI sources and play a bit
with that command, you will come up with a pretty much good idea of
what its output is supposed to look like?