Formatting of function pointer value

Formatting of function pointer value

[Vladimir Prus]

Hello,
consider the following snippet:

    B* p2 = (B*)0x12345678;
    int (*p3)(int) = (fp)0x000000AE;

the value of p2 is printed like this:

   (gdb)info local
   ....
   p2 = (B *) 0xb8000540


the value of *p3 is printed like this:

   (gdb) print *p3 
   $1 = {int (int)} 0xb7ee6e9c <__DTOR_END__+4>

I have a couple of questions:

1. Why in both cases the type of value is printed? There's already 'whatis'
command. I've checked that code and it's printed unconditionally. As the
result, a GDB frontend must strip the type.

2. Why the type is enclosed in parenthesis in the first case, and in braces
in the second case? This entails additonal problems for GUI frontend, for
example, at the moment KDevelop thinks that the opening brace in the second
case starts a composite.

- Volodya

  

Re: Formatting of function pointer value

[Vladimir Prus]

Vladimir Prus wrote:


> the value of *p3 is printed like this:
> 
>    (gdb) print *p3
>    $1 = {int (int)} 0xb7ee6e9c <__DTOR_END__+4>

Even more strange is this:

   (gdb) print p3 
   $2 = (int (*)(int)) 0xb7ee6e9c <__DTOR_END__+4>
   (gdb) print *p3 
   $3 = {int (int)} 0xb7ee6e9c <__DTOR_END__+4>

Why does formatting of the type different in the second case, and uses
braces instead of parenthesis?

- VOlodya

Re: Formatting of function pointer value

[Daniel Jacobowitz]

On Fri, Jul 08, 2005 at 12:00:44PM +0400, Vladimir Prus wrote:
> 
> Hello,
> consider the following snippet:
> 
>     B* p2 = (B*)0x12345678;
>     int (*p3)(int) = (fp)0x000000AE;
> 
> the value of p2 is printed like this:
> 
>    (gdb)info local
>    ....
>    p2 = (B *) 0xb8000540
> 
> 
> the value of *p3 is printed like this:
> 
>    (gdb) print *p3 
>    $1 = {int (int)} 0xb7ee6e9c <__DTOR_END__+4>
> 
> I have a couple of questions:
> 
> 1. Why in both cases the type of value is printed? There's already 'whatis'
> command. I've checked that code and it's printed unconditionally. As the
> result, a GDB frontend must strip the type.

It is a feature, not a bug.  Why is your frontend using the
command-line interface?  DON'T do that!  Use MI nowadays, please please
please.

The type is included because "print p2; $1 = 0x12345678" is very
uninformative; that's how we print integers, not pointers.

> 2. Why the type is enclosed in parenthesis in the first case, and in braces
> in the second case? This entails additonal problems for GUI frontend, for
> example, at the moment KDevelop thinks that the opening brace in the second
> case starts a composite.

Code addresses are treated specially.  Same reason why you get a symbol
name, I expect...

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: Formatting of function pointer value

[Daniel Jacobowitz]

On Fri, Jul 08, 2005 at 12:50:48PM +0400, Vladimir Prus wrote:
> Vladimir Prus wrote:
> 
> 
> > the value of *p3 is printed like this:
> > 
> >    (gdb) print *p3
> >    $1 = {int (int)} 0xb7ee6e9c <__DTOR_END__+4>
> 
> Even more strange is this:
> 
>    (gdb) print p3 
>    $2 = (int (*)(int)) 0xb7ee6e9c <__DTOR_END__+4>
>    (gdb) print *p3 
>    $3 = {int (int)} 0xb7ee6e9c <__DTOR_END__+4>
> 
> Why does formatting of the type different in the second case, and uses
> braces instead of parenthesis?

One is a pointer to function, the other is a function.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: Formatting of function pointer value

[Vladimir Prus]

Daniel Jacobowitz wrote:

> On Fri, Jul 08, 2005 at 12:00:44PM +0400, Vladimir Prus wrote:
>> 
>> Hello,
>> consider the following snippet:
>> 
>>     B* p2 = (B*)0x12345678;
>>     int (*p3)(int) = (fp)0x000000AE;
>> 
>> the value of p2 is printed like this:
>> 
>>    (gdb)info local
>>    ....
>>    p2 = (B *) 0xb8000540
>> 
>> 
>> the value of *p3 is printed like this:
>> 
>>    (gdb) print *p3
>>    $1 = {int (int)} 0xb7ee6e9c <__DTOR_END__+4>
>> 
>> I have a couple of questions:
>> 
>> 1. Why in both cases the type of value is printed? There's already
>> 'whatis' command. I've checked that code and it's printed
>> unconditionally. As the result, a GDB frontend must strip the type.
> 
> It is a feature, not a bug.  Why is your frontend using the
> command-line interface?  

Well, the debugger part in KDevelop was not written by me, so I don't know
why command-line interface, and not MI is used.

> DON'T do that!  Use MI nowadays, please please 
> please.

I'm sorry, but section 24 of gdb manual does not say why MI is better. Can
you give the reasons?

> The type is included because "print p2; $1 = 0x12345678" is very
> uninformative; that's how we print integers, not pointers.

I suppose that if I do "print p2" I have some idea what type of 'p2' is; I
don't print program variables at random. 

- Volodya

Re: Formatting of function pointer value

[Vladimir Prus]

Daniel Jacobowitz wrote:

> On Fri, Jul 08, 2005 at 12:50:48PM +0400, Vladimir Prus wrote:
>> Vladimir Prus wrote:
>> 
>> 
>> > the value of *p3 is printed like this:
>> > 
>> >    (gdb) print *p3
>> >    $1 = {int (int)} 0xb7ee6e9c <__DTOR_END__+4>
>> 
>> Even more strange is this:
>> 
>>    (gdb) print p3
>>    $2 = (int (*)(int)) 0xb7ee6e9c <__DTOR_END__+4>
>>    (gdb) print *p3
>>    $3 = {int (int)} 0xb7ee6e9c <__DTOR_END__+4>
>> 
>> Why does formatting of the type different in the second case, and uses
>> braces instead of parenthesis?
> 
> One is a pointer to function, the other is a function.

I'm sorry, I don't understand this. Is human user supposed to know that '{'
starts a function? What harm will it make if parenthesis are used in both
cases?

- Volodya


 

Re: Formatting of function pointer value

[Nick Roberts]

 > > It is a feature, not a bug.  Why is your frontend using the
 > > command-line interface?  
 > 
 > Well, the debugger part in KDevelop was not written by me, so I don't know
 > why command-line interface, and not MI is used.
 > 
 > > DON'T do that!  Use MI nowadays, please please 
 > > please.
 > 
 > I'm sorry, but section 24 of gdb manual does not say why MI is better. Can
 > you give the reasons?

CLI output is intended for the user.  It can change with a new release, and on
the state of execution in ways which are not easy to anticipate without
reading the source code.  Provided that it still makes sense, that is not a
problem to the user but it can be to a frontend, if it is trying to parse the
output in a very precise manner.  MI has a more formal syntax and so is not as
variable.  Once it is fully developed, its output should be stable and if it
does change, some backward compatibility will probably be maintained.

Nick

Re: Formatting of function pointer value

[Vladimir Prus]

Vladimir Prus wrote:

> Daniel Jacobowitz wrote:
> 
>> On Fri, Jul 08, 2005 at 12:50:48PM +0400, Vladimir Prus wrote:
>>> Vladimir Prus wrote:
>>> 
>>> 
>>> > the value of *p3 is printed like this:
>>> > 
>>> >    (gdb) print *p3
>>> >    $1 = {int (int)} 0xb7ee6e9c <__DTOR_END__+4>
>>> 
>>> Even more strange is this:
>>> 
>>>    (gdb) print p3
>>>    $2 = (int (*)(int)) 0xb7ee6e9c <__DTOR_END__+4>
>>>    (gdb) print *p3
>>>    $3 = {int (int)} 0xb7ee6e9c <__DTOR_END__+4>
>>> 
>>> Why does formatting of the type different in the second case, and uses
>>> braces instead of parenthesis?
>> 
>> One is a pointer to function, the other is a function.
> 
> I'm sorry, I don't understand this. Is human user supposed to know that
> '{' starts a function? What harm will it make if parenthesis are used in
> both cases?

BTW, the code in question says:

      /* FIXME, we should consider, at least for ANSI C language,
         eliminating the distinction made between FUNCs and POINTERs to
         FUNCs.  */
      fprintf_filtered (stream, "{");
      type_print (type, "", stream, -1);
      fprintf_filtered (stream, "} ");

Is "FIXME" still relevant?

- Volodya

Re: Formatting of function pointer value

[Vladimir Prus]

Nick Roberts wrote:

>  > > It is a feature, not a bug.  Why is your frontend using the
>  > > command-line interface?
>  > 
>  > Well, the debugger part in KDevelop was not written by me, so I don't
>  > know why command-line interface, and not MI is used.
>  > 
>  > > DON'T do that!  Use MI nowadays, please please
>  > > please.
>  > 
>  > I'm sorry, but section 24 of gdb manual does not say why MI is better.
>  > Can you give the reasons?
> 
> CLI output is intended for the user.  It can change with a new release,
> and on the state of execution in ways which are not easy to anticipate
> without
> reading the source code.  Provided that it still makes sense, that is not
> a problem to the user but it can be to a frontend, if it is trying to
> parse the
> output in a very precise manner.  MI has a more formal syntax and so is
> not as
> variable.  Once it is fully developed, 

So it's not stable yet?

> its output should be stable and if 
> it does change, some backward compatibility will probably be maintained.

Ok, the the only advantage of MI is stable output format. Can you tell me
how it's achieved? For example, looking at the code that prints function
values (what worries me in the first place):

   fprintf_filtered (stream, "{");
   type_print (type, "", stream, -1);
   fprintf_filtered (stream, "} ");

As I right in assuming that exactly the same output will be produced for MI
mode and for CLI mode? If so, then how MI can be more stable than CLI, if
the output is the same?

- Volodya

Re: Formatting of function pointer value

[Vladimir Prus]

Vladimir Prus wrote:

> Ok, the the only advantage of MI is stable output format. Can you tell me
> how it's achieved? For example, looking at the code that prints function
> values (what worries me in the first place):
> 
>    fprintf_filtered (stream, "{");
>    type_print (type, "", stream, -1);
>    fprintf_filtered (stream, "} ");
> 
> As I right in assuming that exactly the same output will be produced for
> MI mode and for CLI mode? If so, then how MI can be more stable than CLI,
> if the output is the same?

To clarify more, here's what I get with MI:

   -data-evaluate-expression *p3
   ^done,value="{int (int)} 0xb7ee6e9c <__DTOR_END__+4>"
   (gdb)
   -var-create VP3 0 *p3
   ^done,name="VP3",numchild="0",type="int (int)"
   (gdb)
   -var-evaluate-expression VP3
   ^done,value="{int (int)} 0xb7ee6e9c <__DTOR_END__+4>"

The type enclosed in {} is still there.

- Volodya

Re: Formatting of function pointer value

[Nick Roberts]

 > > CLI output is intended for the user.  It can change with a new release,
 > > and on the state of execution in ways which are not easy to anticipate
 > > without reading the source code.  Provided that it still makes sense,
 > > that is not a problem to the user but it can be to a frontend, if it is
 > > trying to parse the output in a very precise manner.  MI has a more
 > > formal syntax and so is not as variable.  Once it is fully developed,
 > 
 > So it's not stable yet?

The manual says:

   Note that GDB/MI is still under construction, so some of the
features described below are incomplete and subject to change.

 > > its output should be stable and if 
 > > it does change, some backward compatibility will probably be maintained.
 > 
 > Ok, the the only advantage of MI is stable output format. 

I've not said that.  It also uses variable objects, it aims to be
asynchronous...

> Can you tell me how it's achieved?

As I've already said, it has a more formal syntax.

 > For example, looking at the code that prints function values (what worries
 > me in the first place):
 > 
 >    fprintf_filtered (stream, "{");
 >    type_print (type, "", stream, -1);
 >    fprintf_filtered (stream, "} ");

I don't understand the point of the example.

 > As I right in assuming that exactly the same output will be produced for MI
 > mode and for CLI mode?

No, you're wrong to assume that.  That should be clear from the examples
in the manual.

Nick

 > If so, then how MI can be more stable than CLI, if the output is the same?

Re: Formatting of function pointer value

[Andreas Schwab]

Vladimir Prus <ghost@cs.msu.su> writes:

> I'm sorry, I don't understand this. Is human user supposed to know that '{'
> starts a function? What harm will it make if parenthesis are used in both
> cases?

`{TYPE} ADDR' is a special syntax for expressions in gdb and is actually a
shorthand for `*(TYPE *) ADDR'.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Formatting of function pointer value

[Vladimir Prus]

Nick Roberts wrote:

>  > > its output should be stable and if
>  > > it does change, some backward compatibility will probably be
>  > > maintained.
>  > 
>  > Ok, the the only advantage of MI is stable output format.
> 
> I've not said that.  It also uses variable objects, it aims to be
> asynchronous...

Could you give more details? Basically, Daniel suggested that I use MI
instead of CLI. I've asked about the reasons why I should, and if possible,
I'd like to see all reasons, with a easy to understand descriptions.

For example, the term "variable objects" says nothing to me, and it's
description:

   For the implementation of a variable debugger window (locals, watched
   expressions, etc.), we are proposing the adaptation of the existing code
   used by `Insight'.

does not sched might light either.

>> Can you tell me how it's achieved?
> 
> As I've already said, it has a more formal syntax.
> 
>  > For example, looking at the code that prints function values (what
>  > worries me in the first place):
>  > 
>  >    fprintf_filtered (stream, "{");
>  >    type_print (type, "", stream, -1);
>  >    fprintf_filtered (stream, "} ");
> 
> I don't understand the point of the example.

The point of the example is that this code seem to be executed both in MI
and CLI modes. So, if '{' is changed to '(', it will equally affect MI and
CLI, which makes me wonder why MI is more stable that CLI.

As you can see from my other post, the formatting of value is indeed the
same for MI and CLI.

- Volodya

Re: Formatting of function pointer value

[Nick Roberts]

 > >  > Ok, the the only advantage of MI is stable output format.
 > > 
 > > I've not said that.  It also uses variable objects, it aims to be
 > > asynchronous...
 > 
 > Could you give more details? Basically, Daniel suggested that I use MI
 > instead of CLI.

I think thats sound advice.  If you use CLI for KDevelop (?) and then GDB
developers change the CLI output, it will break things for you and you'll have
wasted a lot of effort.

 > I've asked about the reasons why I should, and if possible, I'd like to see
 > all reasons, with a easy to understand descriptions.

I don't think you'll get that.  GDB is a voluntary project.  You just have
to work with what's available (or pay someone).

 > For example, the term "variable objects" says nothing to me, and it's
 > description:
 > 
 >    For the implementation of a variable debugger window (locals, watched
 >    expressions, etc.), we are proposing the adaptation of the existing code
 >    used by `Insight'.
 >
 > does not sched might light either.

I've learnt what I know about variable objects from using Insight, reading
the manual and looking at the source code.  I still don't understand the
asynchronous operation which only works under limited conditions.

 ...
 > >  > For example, looking at the code that prints function values (what
 > >  > worries me in the first place):
 > >  > 
 > >  >    fprintf_filtered (stream, "{");
 > >  >    type_print (type, "", stream, -1);
 > >  >    fprintf_filtered (stream, "} ");
 > > 
 > > I don't understand the point of the example.
 > 
 > The point of the example is that this code seem to be executed both in MI
 > and CLI modes. So, if '{' is changed to '(', it will equally affect MI and
 > CLI, which makes me wonder why MI is more stable that CLI.

If you are going to generalise the whole of MI and CLI from this one very
small example, then I can see that it would make you wonder why MI is more
stable that CLI

 > As you can see from my other post, the formatting of value is indeed the
 > same for MI and CLI.

Yes, but you can easily parse the MI output and replace '{' with whatever
you want.

Nick

Re: Formatting of function pointer value

[Daniel Jacobowitz]

On Mon, Jul 11, 2005 at 10:34:55AM +0200, Andreas Schwab wrote:
> Vladimir Prus <ghost@cs.msu.su> writes:
> 
> > I'm sorry, I don't understand this. Is human user supposed to know that '{'
> > starts a function? What harm will it make if parenthesis are used in both
> > cases?
> 
> `{TYPE} ADDR' is a special syntax for expressions in gdb and is actually a
> shorthand for `*(TYPE *) ADDR'.

Woah... and yes, it's in the manual.  Thanks, Andreas; I've never seen
that syntax before!

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: Formatting of function pointer value

[Daniel Jacobowitz]

On Mon, Jul 11, 2005 at 11:40:21AM +0400, Vladimir Prus wrote:
> Vladimir Prus wrote:
> 
> > Ok, the the only advantage of MI is stable output format. Can you tell me
> > how it's achieved? For example, looking at the code that prints function
> > values (what worries me in the first place):
> > 
> >    fprintf_filtered (stream, "{");
> >    type_print (type, "", stream, -1);
> >    fprintf_filtered (stream, "} ");
> > 
> > As I right in assuming that exactly the same output will be produced for
> > MI mode and for CLI mode? If so, then how MI can be more stable than CLI,
> > if the output is the same?
> 
> To clarify more, here's what I get with MI:
> 
>    -data-evaluate-expression *p3
>    ^done,value="{int (int)} 0xb7ee6e9c <__DTOR_END__+4>"
>    (gdb)
>    -var-create VP3 0 *p3
>    ^done,name="VP3",numchild="0",type="int (int)"
>    (gdb)
>    -var-evaluate-expression VP3
>    ^done,value="{int (int)} 0xb7ee6e9c <__DTOR_END__+4>"
> 
> The type enclosed in {} is still there.

The intention is that this is a user-readable value, to be displayed. 
There's limited facility for computing values with machine-readable
results, probably because there has been limited need for it to date.
You can get some information more precisely - for instance the type.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: Formatting of function pointer value

[Vladimir Prus]

Daniel Jacobowitz wrote:

>> To clarify more, here's what I get with MI:
>> 
>>    -data-evaluate-expression *p3
>>    ^done,value="{int (int)} 0xb7ee6e9c <__DTOR_END__+4>"
>>    (gdb)
>>    -var-create VP3 0 *p3
>>    ^done,name="VP3",numchild="0",type="int (int)"
>>    (gdb)
>>    -var-evaluate-expression VP3
>>    ^done,value="{int (int)} 0xb7ee6e9c <__DTOR_END__+4>"
>> 
>> The type enclosed in {} is still there.
> 
> The intention is that this is a user-readable value, to be displayed.

Hmm.. since MI is for gdb frontends, this just imposes work for frontend. It
frontend wants to display the type, it can get this information easily with
extra MI command, while stripping '{}' is somewhat hacky. Especially
because {} is also used to delimit arrays.

> There's limited facility for computing values with machine-readable
> results, probably because there has been limited need for it to date.

So, 
1. It's not possible to avoid those {} in the current code, using MI or CLI.
2. It's not likely that this will change
Right?

If so, then I'll just drop the ball, and use a hacky {}-stripping code in
kdevelop.

- Volodya




 

Re: Formatting of function pointer value

[Daniel Jacobowitz]

On Mon, Jul 11, 2005 at 05:12:47PM +0400, Vladimir Prus wrote:
> > There's limited facility for computing values with machine-readable
> > results, probably because there has been limited need for it to date.
> 
> So, 
> 1. It's not possible to avoid those {} in the current code, using MI or CLI.
> 2. It's not likely that this will change
> Right?

That's the opposite of what I said.  If there's a need for printing the
values in some "raw" form, then a new MI command can be added to do so.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: Formatting of function pointer value

[Vladimir Prus]

Daniel Jacobowitz wrote:

> On Mon, Jul 11, 2005 at 05:12:47PM +0400, Vladimir Prus wrote:
>> > There's limited facility for computing values with machine-readable
>> > results, probably because there has been limited need for it to date.
>> 
>> So,
>> 1. It's not possible to avoid those {} in the current code, using MI or
>> CLI. 2. It's not likely that this will change
>> Right?
> 
> That's the opposite of what I said.  If there's a need for printing the
> values in some "raw" form, then a new MI command can be added to do so.

But why a new command? MI is for frontends and they don't need any
decoration of the value. Why not eliminate {} in MI mode?

- Volodya