Re: [PATCH] Fixup convenience variables on endian switch

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

Daniel Jacobowitz wrote:
>>So you only really need to preserve convenience variables whose types
>>are builtin types, and don't go away when symbol tables are reloaded. 
>>Wouldn't it be simpler just to have clear_internalvars only clear
>>variables whose types belong to objfiles?

Unless I am mistaken even builtin types have to be refreshed. It is a 
long time since I did this work, but I'm sure they are not as simple as 
you make out. At least, they didn't use to be ... this work originally 
comes from a 5.3 baseline.

> I think you've switched patches - this is about updating variables on
> an endianness switch, not clearing them when we reload.  I think that
> one way or another, we ought to preserve the values or discard the
> convenience variables; leaving them corrupted fails my "can I explain
> this behavior to a user" test.

The current behaviour is to leave them corrupted.

>>Or you could define a hook that runs a user-defined command when the
>>architecture changes.  Then your script could define a command that
>>sets up your variables, and have GDB run that command when the
>>architecture is known.  We'd have to think about the best time to run
>>the hook, but I'm sure something reasonable could be worked out.

This doesn't actually seem easier - I have already done the work one way 
and it is totally reliable for builtin types (once configured for each 
host anyway). It also makes the user interface considerably less 
friendly and then there's there's Daniel's test to be passed - the user 
will say "why can't it Just Work?"

> Just seems nasty.  Why not preserve things that we know how to
> preserve, and clear anything we don't?  We know how to preserve
> scalars by reading them into a LONGEST, and floats by reading them into
> a DOUBLEST.  Structures require complicated recursion and unions are
> intractable.

I would prefer we didn't actually clear the value - we currently get it 
back if the endian switches again.

The more I think about this the more I think it might be nice to 
preserve the value of difficult types in the background, should the 
endian switch back (or type return from the dead), and present the value 
to the user as a message '$v = void <wrong endian>' (or '$v = void <type 
unknown>').

Just a thought ....

Andrew