This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: MI: type prefixes for values


Daniel Jacobowitz wrote:

> OK, I checked this out.  Before, if all the variables are initialized:
> 
> ^done,locals=[{name="baz",value="2"},{name="blaz2",value="(int &)
> @0x5009c8: 1"},
> {name="blaz4",value="(int &) @0x5009c8: 1"},
> {name="blaz",value="(int &) @0x5009c8: 1"},
> {name="blaz3",value="(int &) @0x5009c8: 1"},
> {name="blaz5",value="(int &) @0x5009c8: 1"}]
> 
> If they aren't:
> 
> &"Cannot access memory at address 0x0\n"
> ^error,msg="Cannot access memory at address 0x0"
> 
> After:
> 
> ^done,locals=[{name="baz",value="10922"}
{name="blaz2",value="@0x2aaaaabc1ca0"},
> {name="blaz4",value="@0x4005e0"},{name="blaz",value="@0x0"},
> {name="blaz3",value="@0x40041b"},{name="blaz5",value="@0x400578"}]
> 
> Now we are showing only the reference, not the target.  I would have
> expected the target value.
> 
> Looking at Eclipse:
>   cdi/org/eclipse/cdt/debug/mi/core/cdi/model/type/IntegralValue.java
> 
>                 // Coming from a reference
>                 if (valueString.startsWith("@")) { //$NON-NLS-1$
>                         valueString = valueString.substring(1);
>                         int colon = valueString.indexOf(':');
>                         if (colon != -1) {
>                                 valueString = valueString.substring(colon
>                                 + 1);
>                         }

So, Eclipse is manually parsing the "value" string? I pretty sure I've heard
either Bob, or Eli say this is not good idea. In fact, I suspect I heard
both of them say this.

>                 } else {
> 
> It wants to show the value in its variables window, not the reference.
> So this patch would break it.
> 
> So, should we change common_val_print, do you think?

Short-term, this might be a solution. But note again that depending on
textual "value" field is bad idea in any case.

Long-term the right solution is:

  - Port the Apple change that allows to get variable objects for all
    local variables in one command.
  - Port Apple change that add 'typecode' field to variable objects
  - Add command/variable object format to deference references
  - Teach Eclipse that for variable object with "reference" typecode,
    it should dereference variable object, or whatever is appropriate.

This could be a long process, though. 


- Volodya




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]