[lldb-dev] Issue with displaying a union of templated type in debugger
jingham at apple.com
jingham at apple.com
Mon Aug 11 11:26:57 PDT 2014
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 <rtepub at gmail.com> 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
> lldb-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
More information about the lldb-dev
mailing list