Re: serious problems in GDB / LLDB debugger
Re: serious problems in GDB / LLDB debugger
- Subject: Re: serious problems in GDB / LLDB debugger
- From: Jim Ingham <email@hidden>
- Date: Tue, 16 Aug 2011 17:20:57 -0700
It does sound like the debug information is wrong here. If you can file a bug with bugreporter.apple.com, we will take a look. If you don't mind making the object file containing this code available, then just find that in your build folder and attach it to the bug, along with the name of the variable that is being printed wrong. If you had the actual definition of the type of this m_vfloat as well (from your C++ code) that would help too.
BTW, when trying to determine whether debug info for clang is wrong, it is better to compare to gcc-4.2 if possible, that's been around for a really long time and has fewer debug info bugs than clang (which has fewer than llvm-gcc at this point.)
Jim
On Aug 16, 2011, at 5:08 PM, J wrote:
> using apple llvm compiler 2.1, we get the following output of lldb:
>
> m_v float [16]
> [0] float 2
> [1] float 3
> [2] float 4
> [3] float 5
> [4] float 6
> [5] float 7
> [6] float 8
> [7] float 9
> [8] float 10
> [9] float 11
> [10] float 12
> [11] float 13
> [12] float 14
> [13] float 15
> [14] float 40
> [15] float 10
>
> for the same data given earlier.
>
> 'my' output gives the expected
>
> previousGT: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
>
> On Aug 17, 2011, at 1:33 AM, Quincey Morris wrote:
>
>> On Aug 16, 2011, at 15:24 , J wrote:
>>
>>> If it's an alignment/offset issue, why the two '1's repeated at the end of the array ?
>>
>> There's a repeating pattern in your data. If you imagine 2 of these arrays end to end, you'll get (in terms of successive floats):
>>
>> 1 0 0 0 0 1 0 0 0 0 1 0 0 0 0 1 1 0 0 0 0 1 0 0 0 0 1 0 0 0 0 1
>>
>> m_varray is supposed to be the first 16 of these. What I'm saying is that it's perhaps not the first 16, but 16 elements starting from #2. If the debug info is wrong, it may be showing up this way because the debugger is being told the wrong offset in the class layout.
>>
>> Another possibility is that your code is accessing these array elements via a pointer, and the pointer is off by 2 elements. Falling off the end of the array by a couple of elements *may* produce this sort of result without necessarily causing a crash.
>>
>>> I sure hope it's something fixable, but Ive had many problems the last couple of days relating
>>> to the debugger, both using gcc and llvm as compiler, and using gdb and lldb for debugging respectively.
>>> the problem reported here pertains to llvm gcc 4.2 as compiler and lldb as debugger.
>>> when I compile with gcc and use gdb as the debugger, things do seem to work properly, however
>>> I get the following message in the console for which I don't understand the cause and im unsure whether it's related:
>>>
>>> warning: Unable to read symbols for /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.3.2 (8H7)/Symbols/Developer/usr/lib/libXcodeDebuggerSupport.dylib (file not found).
>>> warning: No copy of libXcodeDebuggerSupport.dylib found locally, reading from memory on remote device. This may slow down the debug session.
>>
>> In Xcode 4.1, you should be able to compile with the clang llvm 2.1 compiler, which is not the same thing as gcc llvm 4.2. (There is also a clang llvm 3, but it's not available in Xcode 4.1 apparently.)
>>
>>> I'm not quite sure why you're talking about 'ivar's, could you explain ? the m_v array is an array of floats - not integers,
>>> or do I misunderstand your use of the word ivar ?.
>>
>> Sorry, I was talking Objective-C-ese. I mean "instance variable", not "integer variable".
>>
>>
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Xcode-users mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden