This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: Language of registers
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