[lldb-dev] lldb problems on linux

Malea, Daniel daniel.malea at intel.com
Thu Aug 8 07:58:54 PDT 2013


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<mailto:kcconley at gmail.com>>
Date: Thursday, 8 August, 2013 8:03 AM
To: Andrew Kaylor <andrew.kaylor at intel.com<mailto:andrew.kaylor at intel.com>>
Cc: "lldb-dev at cs.uiuc.edu<mailto:lldb-dev at cs.uiuc.edu>" <lldb-dev at cs.uiuc.edu<mailto:lldb-dev at cs.uiuc.edu>>, Daniel Malea <daniel.malea at intel.com<mailto: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<mailto: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<mailto: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<mailto: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<mailto:kcconley at gmail.com>>
Date: Wednesday, 7 August, 2013 2:44 PM
To: Daniel Malea <daniel.malea at intel.com<mailto:daniel.malea at intel.com>>
Cc: Andrew Kaylor <andrew.kaylor at intel.com<mailto:andrew.kaylor at intel.com>>, "lldb-dev at cs.uiuc.edu<mailto:lldb-dev at cs.uiuc.edu>" <lldb-dev at cs.uiuc.edu<mailto: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<mailto:kcconley at gmail.com>>
Date: Tuesday, 6 August, 2013 5:27 PM
To: Andrew Kaylor <andrew.kaylor at intel.com<mailto:andrew.kaylor at intel.com>>, "lldb-dev at cs.uiuc.edu<mailto:lldb-dev at cs.uiuc.edu>" <lldb-dev at cs.uiuc.edu<mailto: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]
Sent: Tuesday, August 06, 2013 2:00 AM
To: Kaylor, Andrew
Cc: lldb-dev at cs.uiuc.edu<mailto: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<mailto: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> [mailto: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<mailto: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!










More information about the lldb-dev mailing list