[lldb-dev] lldb problems on linux
Kal Conley
kcconley at gmail.com
Wed Aug 14 05:00:00 PDT 2013
Is there really a requirement that .debug_aranges must cover every debug
section in the entire program? I couldn't find this in the DWARF spec.
Seems like LLDB should try .debug_aranges first then fallback gracefully.
The way it is currently, if you link in any object file that happens to
have a .debug_aranges section, then you can't debug the rest of the program
with LLDB. The test below demonstrates the problem. Note that gcc generates
a .debug_aranges section and clang does not.
-----------------------------------
#clang --version
clang version 3.4 (188254)
Target: x86_64-unknown-linux-gnu
Thread model: posix
#gcc --version
gcc (Debian 4.7.2-5) 4.7.2
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
#cat a.c
int a() {
return 0;
}
#cat main.c
extern int a();
int main() {
return a();
}
#gcc -c -g a.c -o a.o
#clang -g a.o main.c -o test
#lldb test
Current executable set to 'test' (x86_64).
(lldb) b main.c:3
Breakpoint 1: no locations (pending).
WARNING: Unable to resolve breakpoint to any actual locations.
(lldb) b a.c:2
Breakpoint 2: where = test`a + 4 at a.c:2, address = 0x00000000004004b0
-----------------------------------
Note how LLDB can only set breakpoints in code that correspond to object
files that have .debug_aranges info.
-Kal
2013/8/9 Greg Clayton <gclayton at apple.com>
> It sounds like the .debug_aranges section the compiler is generating is
> not correct, and that is what is messing everything up. If we have a
> .debug_aranges section, we use it. If it is missing, then we auto generate
> it by pulling in all DWARF and calculating it by hand. This is bad because
> it consumes time and memory to pull in all DWARF just to generate the
> address ranges.
>
> File a bug against clang with your repro steps.
>
> Greg
>
> On Aug 8, 2013, at 8:21 AM, Kal Conley <kcconley at gmail.com> wrote:
>
> > 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]
> > 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!
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > lldb-dev mailing list
> > lldb-dev at cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20130814/b562c3c5/attachment.html>
More information about the lldb-dev
mailing list