Re: Language of registers

[Vladimir Prus <vladimir@codesourcery.com>]

On Monday 27 November 2006 17:03, Daniel Jacobowitz wrote:
> On Sat, Nov 25, 2006 at 02:21:43PM +0300, Vladimir Prus wrote:
> > At the moment, MI varobj assume that register values have a language. As
> > result, if you try to look at values of $xmm1 in a C++ program, you'll
> > find that this registers has a 'public' field -- which is not reasonable.
>
> I'm unsure.  Maybe it's actually right the way it is?  All of GDB's
> other forms of output adjust with the current language.  For instance,
> in the CLI:
>
> (gdb) set lang ada
> (gdb) p $xmm1
> $4 = (v4_float => (0 => 0.0, 0.0, 0.0, 0.0), 

First of all, varobjs don't know anything about Ada. Further, unlike CLI, 
varobj don't have any language-specific formatting -- it's just tree of 
values. 

Language-specific code in varobj.c basically does two things:

	- Add those public child for C++
	- Escapes "." for Java (to avoid conflict with "." used in between
	varobj levels themself)

Neither seems reasonable to do for registers.

> I'd suggest that we don't need the fake "public" child for things of
> struct/union (as opposed to class) type that are 100% public.  We can't
> reliably detect struct vs class because debug info is often lacking the
> distinction, but union is easy.  I don't know if this might break some
> MI frontend though.  But the "public" child isn't even documented.

You're right that such a change will make my patch unnecessary. I'm not sure 
what frontend authors say, though. Personally, I don't see any reason why a 
debugger should group members by accessibility, and KDevelop just hides those 
pseudo-fields. Eclipse, on the other hand, shows them, but probably will work 
just fine without.

The change does not seem very complex, but the changes to testcases will be 
huge, so I'd like to check. Does everybody agree with removing "public" 
pseudo-field from structures that have only public fields?

- Volodya


Does everybody agree with removing 'pu