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 <[email protected]> > 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 <[email protected]> > > 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 <[email protected]> >> Date: Thursday, 8 August, 2013 8:03 AM >> To: Andrew Kaylor <[email protected]> >> Cc: "[email protected]" <[email protected]>, Daniel Malea < >> [email protected]> >> >> 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 <[email protected]> >> >>> 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 <[email protected]> >>> >>> 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; [email protected] >>>> >>>> *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 <[email protected]> >>>> *Date: *Wednesday, 7 August, 2013 2:44 PM >>>> *To: *Daniel Malea <[email protected]> >>>> *Cc: *Andrew Kaylor <[email protected]>, "[email protected]" < >>>> [email protected]> >>>> *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 <[email protected]> >>>> *Date: *Tuesday, 6 August, 2013 5:27 PM >>>> *To: *Andrew Kaylor <[email protected]>, "[email protected]" < >>>> [email protected]> >>>> *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:[email protected] <[email protected]>] >>>> *Sent:* Tuesday, August 06, 2013 2:00 AM >>>> *To:* Kaylor, Andrew >>>> *Cc:* [email protected] >>>> *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 <[email protected]>**** >>>> >>>> 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:* [email protected] [mailto: >>>> [email protected]] *On Behalf Of *Kal Conley >>>> *Sent:* Sunday, August 04, 2013 11:27 AM >>>> *To:* [email protected]**** >>>> >>>> >>>> *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!**** >>>> >>>> **** >>>> >>>> ** ** >>>> >>>> ** ** >>>> >>>> ** ** >>>> >>> >>> >> >
_______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
