This sort of bug tends to be either a debug information problem or the debugger
misinterpreting it somehow. If the y & g fields were present, but with the
wrong values, is is more likely the latter cause, if they are just missing, it
is more likely the former. That being said this problem doesn't reproduce in
TOT lldb using a pretty recent clang-600 branch compiler. The lldb equivalent
of the Xcode locals view is what gets printed out with the "frame variable"
command, and your example shows:
(lldb) frame var foo
(vec2<float>) foo = {
= {
x = 2
r = 2
}
= {
y = 3
g = 3
}
}
which is right. What version of clang are you using when you see this?
Jim
> On Aug 6, 2014, at 9:46 PM, Rich Eakin <[email protected]> wrote:
>
> I'm not sure if this has been reported, but I have come across an issue with
> trying to view data that is within a union Xcode's debug view, specifically
> when the data type is templated. Please consider the following:
>
> template <typename T>
> struct vec2 {
> union { T x, r; };
> union { T y, g; };
> };
>
> int main()
> {
> vec2<float> foo = { 2.0f, 3.0f };
> return 0;
> }
>
> If I place a breakpoint on the return statement and exam foo, I see two tabs
> with no name. Clicking on either tab shows an array of 'y = 3, g = 3', while
> there is no sign of x (or r). Something is going wrong here.
>
> However if I remote the templating:
>
> struct vec2 {
> union { float x, r; };
> union { float y, g; };
> };
>
> int main()
> {
> vec2 foo = { 2.0f, 3.0f };
> return 0;
> }
>
> and example the data in the same manner, I see that one tab has an array of
> 'x = 2, r = 2', and the other is 'y = 3, g = 3'. Is this a known issue? I
> discovered this while trying to make use of the popular glm math library
> (http://glm.g-truc.net/), which uses unions in this manner to follow the GLSL
> types spec.
>
> As an aside, I think the display of unions in general (even without the
> templates) is not ideal, at first glance it is difficult to make out what the
> data is at all, given that it is a) hidden underneath tabs with no names and
> b) duplicated. Has there been any thought towards how to better represent
> this data in the debugger?
>
> Thanks,
> Rich
>
> _______________________________________________
> lldb-dev mailing list
> [email protected]
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
_______________________________________________
lldb-dev mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
