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
