Re: [PATCH] keeping convenience variables (take 2)

[Andrew STUBBS <andrew.stubbs@st.com>]

Jim Blandy wrote:
> I may be missing something, be patient:
> 
> If I understand the original motivation for this, you don't actually
> need to keep around any values that aren't using the builtin types. 
> Or at least, that could be using the built-in types; it wasn't clear
> whether they actually did.

Yes, most likely they are all builtin types, but when I first did the 
work (in 5.3) I found that it could not be assumed that the builtin 
types would stay in the same place. I do not remember under what 
circumstances I observed this. So I fixed it and the result was that we 
got 'textual compatibility' of all other types for free. Now it does 
appear that builtin types can be safely left alone - there have been 
many changes to the code in this area.

> I'm uncomfortable with this whole "print type name and then re-parse
> later" approach.  I think it's a real kludge.  And the fact that it
> doesn't seem really necessary for the problem that originally
> motivated the change is a red flag, it seems to me.

You may be right - I probably don't _need_ it. However, it does work - 
it provides this 'textual compatibility' very effectively. A better way 
to print the type name might be nice though.

Your point about it not being necessary might be a good reason not to do 
something in the first place, but it is not, in itself, a good reason to 
disregard something that has _already_ been done (mostly anyway). This 
is especially true when what has been done is 'nice to have'.

> I can certainly see that it's useful to keep the convenience variables
> around across symfile selections and endianness switches; I just think
> we should find a better way to handle the types than this.

Well, we could recursively copy the entire type list for type and 
enclosing_type. This would certainly be enough to print the value and to 
use it in some expressions. I can imagine that there might be some 
issues because these types would exist outside of the normal type table 
and/or might clash with types in that table.

However, this would require intimate knowledge of the value and type 
structures and everything they reference. Also, it would be impossible 
to change the value, even though the existing contents could be read, 
because parse_expression() wouldn't see the types.

It would need a flag in the internalvar to say it would need freeing if 
the value changes to something else.

It might then be possible to match a copied type up against new types at 
some point (still with all the problems of context etc.), but this does 
not seem pretty - not least because a lot of pointer types are generated 
on the fly (something parse_expression does for us in my technique).

If anybody has any other suggestions or insight on these matters then 
that will be welcome.

> If the convenience variables you set up in your script, holding
> addresses and such, don't refer to the builtin types, why don't they? 
> Could they?  I understand that changing architectures or 
> architectural variants affects the builtin types, but it seems more
> feasible to track those changes than to try to track objfile-based
> types as they disappear and reappear.

Another question is 'why wouldn't they?'

I make no attempt the track changes across architectural variants (other 
than endian) or indeed from one architecture to another. Doing that 
would require actual comparison of the before and after types and a type 
conversion of some kind.

It seems much harder to me than just extracting type information (in 
whatever form) and keeping it or reinstating it later. Perhaps I 
misunderstand your point.


If I understand you, I think your problem is that the conversion process 
is a) incomplete with respect to non-C languages; b) prone to mistakes 
with commonly used type-names; and c) different to how it was before.

I think the first two can be fixed by means of a better name capturing 
technique (GDB can print this to screen, but is there a way to capture 
it in a string?) and by comparing more than just the name (size of base 
type, number of fields, perhaps some kind of checksum???).

Andrew Stubbs