RE: -var-update using formatted value

[Nick Roberts <nickrob@snap.net.nz>]

[aside - can you please fit your messages into 80 columns]

 > I guess the problem is that GDB makes the assumption that the front-end only cares about the 
 > last value retrieved by evaluate-expression. Although this is sometimes the case, other times
 > it is not.

Previously -var-evaluate-expression was needed because values weren't displayed
when variable objects were created (-var-create now includes the value field,
-var-list-children has the --all-values option).  Given that -var-update
provides a record of all changes, I'm not sure that -var-evaluate-expression is
necessary now.

 > To solve this in GDB:
 > Since both use cases are valid (at least to me), the only way I can think to solve this is 
 > to have an extra flag to var-update.  Something like [--content-changed | --displayed-value-changed]
 > It would be a separate flag than the --no-values one.
 > The front-end could then decide which behavior it wants.  
 > It's not pretty but that is all I got.
 > I know submitting a patch is the proper thing to do, but I didn't think this idea was going
 > to be accepted easily, so I'm suggesting it first.
 > 
 > To solve this in the front-end:
 > I originally thought I could always use the natural format before doing a var-update, but it is not
 > that simple since I have to use the natural format for the root but also for all of the children 
 > of that root.  So my choices are:
 > 1- don't cache (this causes the most increase in front-end-to-GDB communication)

Generally I don't think changing the format of already retrieved values is
expensive.

You said:

    GDB itself is running on a potentially slow
    processor, with a small bandwidth connection to the front-end.

Could you expand on that scenario?

 > 2- when changing the format of a varObject and getting the value, immediately set it back to natural
 >        (this will keep all varObjects, roots and children, at natural)
 > 3- before doing a -var-update on the root, set the root AND all its children to natural
 > 4- creating a variable object for each format.  This turns out not to be efficient (if I understood
 >       correctly) because each of the five varObjects will need to be var-updated and will need to go 
 >       read the raw value in memory, instead of doing this once.
 > 
 > Solutions 2 or 3 are my best choices I believe.  But it would be nice to have GDB support this.

They're quite intrusive changes for what seems like a very specialised case.

-- 
Nick                                           http://www.inet.net.nz/~nickrob