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

Andrew STUBBS
2005-11-22T17:14:13Z

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