[lldb-dev] lldb problems on linux
Kal Conley
kcconley at gmail.com
Thu Aug 8 08:21:15 PDT 2013
I figured out how to reproduce this. Just compile with clang
-fsanitize=address any program and you should see what I am seeing.
-Kal
2013/8/8 Kal Conley <kcconley at gmail.com>
> I am not able to post the source/binary of this inferior. I built it with
> clang-3.4. If I build with g++4.7 lldb loads the source information
> correctly, so this may be a clang bug if you think the generated dwarf info
> is wrong. On the other hand gdb does handle this binary without a problem.
> -Kal
>
>
> 2013/8/8 Malea, Daniel <daniel.malea at intel.com>
>
> Hmm, what compiler/version are you using to build the inferior you are
>> trying to debug? Any chance you can file a bug at llvm.org/bugs and
>> attach the problematic binary?
>>
>> Thanks,
>> Dan
>>
>> From: Kal Conley <kcconley at gmail.com>
>> Date: Thursday, 8 August, 2013 8:03 AM
>> To: Andrew Kaylor <andrew.kaylor at intel.com>
>> Cc: "lldb-dev at cs.uiuc.edu" <lldb-dev at cs.uiuc.edu>, Daniel Malea <
>> daniel.malea at intel.com>
>>
>> Subject: Re: [lldb-dev] lldb problems on linux
>>
>> If I apply the following to ignore .debug_aranges source debugging
>> works again:
>>
>> Index: source/Plugins/SymbolFile/DWARF/DWARFDebugInfo.cpp
>> ===================================================================
>> --- source/Plugins/SymbolFile/DWARF/DWARFDebugInfo.cpp (Revision
>> 187863)
>> +++ source/Plugins/SymbolFile/DWARF/DWARFDebugInfo.cpp (Arbeitskopie)
>> @@ -58,7 +58,7 @@
>>
>> m_cu_aranges_ap.reset (new DWARFDebugAranges());
>> const DataExtractor &debug_aranges_data =
>> m_dwarf2Data->get_debug_aranges_data();
>> - if (debug_aranges_data.GetByteSize() > 0)
>> + if (0 && debug_aranges_data.GetByteSize() > 0)
>> {
>> if (log)
>> log->Printf ("DWARFDebugInfo::GetCompileUnitAranges()
>> for \"%s\" from .debug_aranges",
>>
>>
>>
>> 2013/8/8 Kal Conley <kcconley at gmail.com>
>>
>>> I enabled logging... I am seeing this when I run
>>> (lldb) b main.cc:14
>>>
>>> <... Lots of other info ...>
>>> main-thread Address Line Column File ISA Flags
>>> main-thread ------------------ ------ ------ ------ --- -------------
>>> main-thread 0x00000000004afa70 8 0 1 0 is_stmt
>>> main-thread 0x00000000004afd2e 14 0 1 0 is_stmt
>>> prologue_end
>>> main-thread 0x00000000004afd69 16 0 1 0 is_stmt
>>> main-thread 0x00000000004afd94 20 0 1 0 is_stmt
>>> main-thread 0x00000000004afda3 23 0 1 0 is_stmt
>>> main-thread 0x00000000004afe6c 24 0 1 0 is_stmt
>>> main-thread 0x00000000004b017b 24 0 1 0 is_stmt
>>> end_sequence
>>> main-thread 0x00000000004b0180 2292 0 2 0 is_stmt
>>> main-thread 0x00000000004b02b3 2292 0 2 0 is_stmt
>>> prologue_end
>>> main-thread 0x00000000004b0322 2292 0 2 0 is_stmt
>>> end_sequence
>>> main-thread 0x00000000004b0330 494 0 78 0 is_stmt
>>> main-thread 0x00000000004b0409 494 0 78 0 is_stmt
>>> prologue_end
>>> main-thread 0x00000000004b04a1 494 0 78 0 is_stmt
>>> end_sequence
>>> main-thread 0x00000000004b04b0 2292 0 2 0 is_stmt
>>> main-thread 0x00000000004b05e3 2292 0 2 0 is_stmt
>>> prologue_end
>>> main-thmain-thread DWARFDebugInfo::GetCompileUnitAranges() for
>>> "/home/kal/test/test" from .debug_aranges
>>> main-thread DWARFDebugAranges::Sort(minimize = 1) with 23 entriesread
>>> 0x00000000004b0671 2292 0 2 0 is_stmt end_sequence
>>> main-thread DWARFDebugAranges::Sort() 11 entries after minimizing (12
>>> entries combined for 192 bytes saved)
>>> main-thread 0x00000000: [0x45d670 - 0x45d7a4)
>>> main-thread 0x00021392: [0x45d7b0 - 0x45d7be)
>>> main-thread 0x00000000: [0x45dbf0 - 0x465c0c)
>>> main-thread 0x0001d8d4: [0x465c10 - 0x467120)
>>> main-thread 0x00021392: [0x467120 - 0x468172)
>>> main-thread 0x0002429a: [0x468180 - 0x485d9c)
>>> main-thread 0x0005cd35: [0x485da0 - 0x485e1f)
>>> main-thread 0x0005dd15: [0x485e20 - 0x4865e5)
>>> main-thread 0x0005fff2: [0x4865f0 - 0x486b7c)
>>> main-thread 0x00061b4e: [0x486b80 - 0x487eff)
>>> main-thread 0x00064a9d: [0x487f00 - 0x488295)
>>> Breakpoint 1: no locations (pending).
>>> WARNING: Unable to resolve breakpoint to any actual locations.
>>>
>>> The address 0x00000000004afd2e for line 14 is correct. If i run "b
>>> main" I also get there. But that address isn't in the Aranges list.
>>> -Kal
>>>
>>>
>>> 2013/8/7 Kaylor, Andrew <andrew.kaylor at intel.com>
>>>
>>> I agree that logging is the best place to start. Without a better
>>>> idea of what’s failing, it’s hard to say where to start.****
>>>>
>>>> ** **
>>>>
>>>> You could try something like setting a breakpoint in the
>>>> CommandObjectBreakpointSet::DoExecute() function, and stepping through from
>>>> there. I think that’s likely to get you to the beginning of the DWARF
>>>> processing if setting a breakpoint is the first thing you do after creating
>>>> the target (or specifying it on the command line). It’s a long and winding
>>>> road from there to the meaty bits, but without some hints from the log
>>>> output it’s hard to say where a wrong turn might have been taken.****
>>>>
>>>> ** **
>>>>
>>>> SymbolFileDWARF::ParseCompileUnit() is another potentially interesting
>>>> starting place, but I think there’s a good chance you won’t get there if
>>>> you aren’t seeing any source information.****
>>>>
>>>> ** **
>>>>
>>>> -Andy****
>>>>
>>>> ** **
>>>>
>>>> *From:* Malea, Daniel
>>>> *Sent:* Wednesday, August 07, 2013 1:14 PM
>>>> *To:* Kal Conley
>>>> *Cc:* Kaylor, Andrew; lldb-dev at cs.uiuc.edu
>>>>
>>>> *Subject:* Re: [lldb-dev] lldb problems on linux****
>>>>
>>>> ** **
>>>>
>>>> Enabling logging is probably a good first place to start. If you're not
>>>> seeing source information, then maybe lldb is unable to parse some stuff
>>>> that clang is generating… to see what the DWARF parser is doing, you can:
>>>> ****
>>>>
>>>> ** **
>>>>
>>>> (lldb) log enable dwarf all****
>>>>
>>>> ** **
>>>>
>>>> There's many logging categories that can be enabled; some are quite
>>>> verbose..to see all of them, do:****
>>>>
>>>> ** **
>>>>
>>>> (lldb) log list****
>>>>
>>>> ** **
>>>>
>>>> Also, with the '-f' option, you can dump the output to a file for
>>>> easier perusal.****
>>>>
>>>> ** **
>>>>
>>>> ** **
>>>>
>>>> Cheers,****
>>>>
>>>> Dan****
>>>>
>>>> ** **
>>>>
>>>> *From: *Kal Conley <kcconley at gmail.com>
>>>> *Date: *Wednesday, 7 August, 2013 2:44 PM
>>>> *To: *Daniel Malea <daniel.malea at intel.com>
>>>> *Cc: *Andrew Kaylor <andrew.kaylor at intel.com>, "lldb-dev at cs.uiuc.edu" <
>>>> lldb-dev at cs.uiuc.edu>
>>>> *Subject: *Re: [lldb-dev] lldb problems on linux****
>>>>
>>>> ** **
>>>>
>>>> I am still seeing issues with source-level debugging. "target modules
>>>> dump sections" has symbol entries. Also source level debugging is working
>>>> in gdb, so I know that symbols are available.
>>>> The strange thing is, I tried the same thing with a simple "Hello
>>>> world" program and source level debugging worked. Both programs are being
>>>> compiled with clang-3.4.
>>>>
>>>> Can someone give me a tip where I can should put breakpoints in LLDB to
>>>> debug this?
>>>>
>>>> Thanks,
>>>> -Kal
>>>>
>>>> Am 8/7/13 12:04 AM, schrieb Kal Conley:****
>>>>
>>>> Hi Dan,
>>>> Sorry I wasn't clear. My fix fixes the test suite issue. The only
>>>> remaining issue is the source debugging issue. I haven't got to look into
>>>> that yet. I am on Debian Wheezy.
>>>> -Kal
>>>>
>>>> Am 8/6/13 11:44 PM, schrieb Malea, Daniel:****
>>>>
>>>> Thank you Kal for the fix! Much appreciated :)****
>>>>
>>>> ** **
>>>>
>>>> I committed it in r187818.****
>>>>
>>>> ** **
>>>>
>>>> So, just to clarify, you're still unable to run the test suite after
>>>> the fix? Which distro are you on?****
>>>>
>>>> ** **
>>>>
>>>> ** **
>>>>
>>>> Thanks,****
>>>>
>>>> Dan****
>>>>
>>>> ** **
>>>>
>>>> *From: *Kal Conley <kcconley at gmail.com>
>>>> *Date: *Tuesday, 6 August, 2013 5:27 PM
>>>> *To: *Andrew Kaylor <andrew.kaylor at intel.com>, "lldb-dev at cs.uiuc.edu" <
>>>> lldb-dev at cs.uiuc.edu>
>>>> *Subject: *Re: [lldb-dev] lldb problems on linux****
>>>>
>>>> ** **
>>>>
>>>> Hi Andy,
>>>> So I figured out the python issue. Host::GetLLDBPath() is broken. It
>>>> was failing for me because I am building in Release mode. It only works in
>>>> Debug mode by luck :) The problem is lines 1035+ in
>>>> source/Host/common/Host.cpp. llvm::Twine should only be used for temporary
>>>> objects! See http://llvm.org/docs/ProgrammersManual.html#dss-twine
>>>>
>>>> I have attached a patch this fixes the issue. I haven't found time to
>>>> investigate my other issue yet.
>>>>
>>>> Thanks!
>>>> -Kal
>>>>
>>>> Am 8/6/13 4:29 PM, schrieb Kaylor, Andrew:****
>>>>
>>>> Hmm… I’ve never seen the -P option print the wrong path. Looking at
>>>> the code (in Host::GetLLDBPath) it doesn’t even look possible for it to
>>>> print what you’re seeing.****
>>>>
>>>> ****
>>>>
>>>> On the other hand, the second directory you mention should be the
>>>> correct one. If you set PYTHONPATH to that does “python -c ‘import lldb’”
>>>> work?****
>>>>
>>>> ****
>>>>
>>>> -Andy****
>>>>
>>>> ****
>>>>
>>>> *From:* Kal Conley [mailto:kcconley at gmail.com <kcconley at gmail.com>]
>>>> *Sent:* Tuesday, August 06, 2013 2:00 AM
>>>> *To:* Kaylor, Andrew
>>>> *Cc:* lldb-dev at cs.uiuc.edu
>>>> *Subject:* Re: [lldb-dev] lldb problems on linux****
>>>>
>>>> ****
>>>>
>>>> Hi Andy,
>>>> I tried
>>>> export PYTHONPATH=`$llvm/build/Debug+Asserts/bin/lldb -P`
>>>> but it didn't work for me. If I run `build/bin/lldb -P` it outputs
>>>> "build/lib7/site-packages" which doesn't exist.
>>>> There is a directory build/lib/python-2.7/site-packages but if I set
>>>> the PYTHONPATH to this directory I get the same errors.****
>>>>
>>>> I can import lldb; in python successfully though.****
>>>>
>>>> Any other ideas?****
>>>>
>>>> -Kal****
>>>>
>>>> ****
>>>>
>>>> 2013/8/5 Kaylor, Andrew <andrew.kaylor at intel.com>****
>>>>
>>>> Hi Kal,****
>>>>
>>>> ****
>>>>
>>>> For the second problem, you need to set the PYTHONPATH environment
>>>> variable. Try this:****
>>>>
>>>> ****
>>>>
>>>> export PYTHONPATH=`$llvm/build/Debug+Asserts/bin/lldb -P`****
>>>>
>>>> ****
>>>>
>>>> Regarding the source information, I would start by using the following
>>>> command within lldb (after you have created the target you want to debug):
>>>> ****
>>>>
>>>> ****
>>>>
>>>> target modules dump sections****
>>>>
>>>> ****
>>>>
>>>> If you don’t see debug sections in that list, then that’s the problem.
>>>> If you do, try enabling DWARF logging (‘log enable dwarf all’) and see if
>>>> anything obvious turns up in the output when you try to set a breakpoint.
>>>> ****
>>>>
>>>> ****
>>>>
>>>> -Andy****
>>>>
>>>> ****
>>>>
>>>> *From:* lldb-dev-bounces at cs.uiuc.edu [mailto:
>>>> lldb-dev-bounces at cs.uiuc.edu] *On Behalf Of *Kal Conley
>>>> *Sent:* Sunday, August 04, 2013 11:27 AM
>>>> *To:* lldb-dev at cs.uiuc.edu****
>>>>
>>>>
>>>> *Subject:* [lldb-dev] lldb problems on linux****
>>>>
>>>> ****
>>>>
>>>> Hi,****
>>>>
>>>> I recently build lldb from trunk (revision 187708) and source-level
>>>> debugging isn't working for me. It seems its not loading any source
>>>> information. What is the best way to troubleshoot this?****
>>>>
>>>> Also make check-lldb doesn't work on Linux when building with CMake. I
>>>> just get error:
>>>>
>>>> This script requires lldb.py to be in either
>>>> /home/user/tools/llvm_3.4~svn187708/tools/lldb/build/Debug/LLDB.framework/Resources/Python,
>>>> /home/user/tools/llvm_3.4~svn187708/tools/lldb/build/Release/LLDB.framework/Resources/Python,
>>>> or
>>>> /home/user/tools/llvm_3.4~svn187708/tools/lldb/build/BuildAndIntegration/LLDB.framework/Resources/Python
>>>> ****
>>>>
>>>> I get the same error with lldb-3.3.****
>>>>
>>>> ****
>>>>
>>>> Thanks!****
>>>>
>>>> ****
>>>>
>>>> ** **
>>>>
>>>> ** **
>>>>
>>>> ** **
>>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20130808/e419f947/attachment.html>
More information about the lldb-dev
mailing list