Re: MI: type prefixes for values

[Daniel Jacobowitz <drow at false dot org>]

On Fri, Mar 24, 2006 at 11:30:54AM +0300, Vladimir Prus wrote:
> > 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.

Heck, I've said it too.  However, in the real world, we need to be a
bit careful of frontends which do it.  I strongly discourage new
frontends doing so, but I also try not to break existing frontends
which do - this is an extension of "be liberal in what you accept,
but conservative in what you generate".

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

That's not actually what I meant - I'm not thinking of MI here. 
common_val_print gets called from a number of places:

- varobj c_value_of_variable, used by Insight and MI
  (-var-list-children, -var-evaluate-expression, -var-assign,
   -var-update).

- print_frame_args, where it is used to deliberately print
  only the address of a reference.  I'm not entirely sure why.

- Languages, to implement value_print - not relevant right now.

> Long-term the right solution is:
> 
>   - Port the Apple change that allows to get variable objects for all
>     local variables in one command.

This sounds sensible.

>   - Port Apple change that add 'typecode' field to variable objects

I understand why they did this, but should we really be exposing GDB's
internal type system this way?  I'd want to see what it gets used for,
and probably define it independently of the existing type codes.

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

Yes indeed.  Hmm.

-- 
Daniel Jacobowitz
CodeSourcery