Re: [lldb-dev] Loading debug symbols (C++, Ubuntu 14.04)
Hi,
thank you for investigating this.
So, what you are describing should normally work. Generally
obj_file->GetDebugSymbolFilePaths() (SymbolVendorELF.cpp:99) should
return the correct name to look for the debug file. E.g., in my case
for libpthread it returns "libpthread-2.19.so", and indeed the debug
file is found at
"/usr/lib/debug/lib/x86_64-linux-gnu/libpthread-2.19.so". This
information should come from the .gnu_debuglink section on the main
file. Could you check what does your file specify (e.g., something
like readelf -p .gnu_debuglink /lib/x86_64-linux-gnu/libpthread.so.0).
If the correct file name is listed there, then we need to figure out
why it's not picked up. If it has an incorrect file, then we need to
find another way to locate the file)
pl
On 9 May 2016 at 13:29, Stefan Kratochwil wrote:
> Hi Pavel,
>
> I stepped through SymbolVendorELF::CreateInstance(), and it seems that the
> problem lies within Symbols::LocateExecutableSymbolFile
> (Host/common/Symbols.cpp). This method looks at the correct locations:
>
> (gdb) print debug_file_search_paths
> $35 = {m_files = std::vector of length 3, capacity 4 = {
> {m_directory = {m_string = 0x7994f8 "/usr/lib"},
>m_filename = {m_string = 0x7fffe400ba88 "x86_64-linux-gnu"},
>m_is_resolved = true,
>m_syntax = lldb_private::FileSpec::ePathSyntaxPosix},
>
> {m_directory = {m_string = 0x7fffe400bae0
> "/home/stefan/git/dsu-ld/libdsu-project"},
>m_filename = {m_string = 0x7fffe400bac8 "."},
>m_is_resolved = true,
>m_syntax = lldb_private::FileSpec::ePathSyntaxPosix},
>
> {m_directory = {m_string = 0x7994f8 "/usr/lib"},
>m_filename = {m_string = 0x7fffe400bb18 "debug"},
>m_is_resolved = true,
>m_syntax = lldb_private::FileSpec::ePathSyntaxPosix}}}
>
>
> But it looks for the wrong file names. Under Ubuntu, the contents of a *-dbg
> packge are stored under /usr/lib/debug, using the exact same file names as
> their regular executable counterparts. In the case of apache2-dbg, the files
> under /usr/lib/debug are (for example):
>
> /usr/lib/debug/usr/bin/rotatelogs
> /usr/lib/debug/usr/sbin/apache2
> /usr/lib/debug/usr/lib/apache2/modules/mod_ssl.so
>
> and so on.
>
>
>
> If i now look at the file names lldb looks for, I find for
> /usr/lib/x86_64-linux-gnu:
> (gdb) print files
> $36 = std::vector of length 4, capacity 4 = {
> "/usr/lib/x86_64-linux-gnu/9d72ee0b01e9b2947c7f95e7b4ebbbf05a8aa5.debug",
>
> "/usr/lib/x86_64-linux-gnu/.debug/9d72ee0b01e9b2947c7f95e7b4ebbbf05a8aa5.debug",
>
> "/usr/lib/x86_64-linux-gnu/.build-id/B5/9D72EE0B01E9B2947C7F95E7B4EBBBF05A8AA5.debug",
>
> "/usr/lib/x86_64-linux-gnu/usr/lib/x86_64-linux-gnu/9d72ee0b01e9b2947c7f95e7b4ebbbf05a8aa5.debug"}
>
> For my /home/stefan/git/dsu-ld/libdsu-project/:
> (gdb) print files
> $38 = std::vector of length 4, capacity 4 = {
>
> "/home/stefan/git/dsu-ld/libdsu-project/./9d72ee0b01e9b2947c7f95e7b4ebbbf05a8aa5.debug",
>
> "/home/stefan/git/dsu-ld/libdsu-project/./.debug/9d72ee0b01e9b2947c7f95e7b4ebbbf05a8aa5.debug",
>
> "/home/stefan/git/dsu-ld/libdsu-project/./.build-id/B5/9D72EE0B01E9B2947C7F95E7B4EBBBF05A8AA5.debug",
>
> "/home/stefan/git/dsu-ld/libdsu-project/./usr/lib/x86_64-linux-gnu/9d72ee0b01e9b2947c7f95e7b4ebbbf05a8aa5.debug"}
>
>
> And finally for the /usr/lib/debug directory:
> (gdb) print files
> $39 = std::vector of length 4, capacity 4 = {
> "/usr/lib/debug/9d72ee0b01e9b2947c7f95e7b4ebbbf05a8aa5.debug",
> "/usr/lib/debug/.debug/9d72ee0b01e9b2947c7f95e7b4ebbbf05a8aa5.debug",
>
> "/usr/lib/debug/.build-id/B5/9D72EE0B01E9B2947C7F95E7B4EBBBF05A8AA5.debug",
>
> "/usr/lib/debug/usr/lib/x86_64-linux-gnu/9d72ee0b01e9b2947c7f95e7b4ebbbf05a8aa5.debug"}
>
>
> So, lldb expects that the uuid/build of the Module it is about to load is
> also contained in the symbol file name.
>
>
> Imho, we also have to take the FileSpec contents of the ModuleSpec we are
> currently looking at, and add its path to the files vector. But I am not
> that familiar with the whole lldb backend to tell for sure what would happen
> then.
>
>
> I also checked the current HEAD of the lldb source tree to see if there are
> any changes, compared with my older revision. There is only a slight
> difference in how Symbols::LoadExecutableSymbolFile uses the /usr/lib/debug
> directory:
>
> // Some debug files may stored in the module directory like this:
> // /usr/lib/debug/usr/lib/library.so.debug
> if (!file_dir.IsEmpty())
> files.push_back (dirname + file_dir.AsCString() + "/" ++
> symbol_filename);
>
>
>
> This would be in fact the solution to my problem, if it wouldn't use the
> symbol_filename (which contains a uuid, something the *-dbg packages don't
> have).
>
>
> Well, what do you think?
>
>
> Cheers,
> Stefan
>
>
>
>
>
>
> On 05/09/2016 11:23 AM, Pavel Labath wrote:
>>
>> You can also use SBCommandInterpreter::HandleCommand, which gives you
>> a bit more control over what happens.
>>
>> good luck with your thesis.
>>
>> pl
>>
>> On 9 May 2016 at 10:00, Stefan Kr
[lldb-dev] [Bug 27710] New: Ptrace interface doesnt allow un-aligned watchpoints on aarch64 linux
https://llvm.org/bugs/show_bug.cgi?id=27710 Bug ID: 27710 Summary: Ptrace interface doesnt allow un-aligned watchpoints on aarch64 linux Product: lldb Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-dev@lists.llvm.org Reporter: omair.jav...@linaro.org CC: llvm-b...@lists.llvm.org Classification: Unclassified watchpoint tests fail on aarch64 linux because we lack support for installing unalligned watchpoint. Following Tests Failing on aarch64-linux target: functionalities/watchpoint/watchpoint_commands/command/TestWatchpointCommandLLDB.py functionalities/watchpoint/watchpoint_commands/command/TestWatchpointCommandPython.py python_api/watchpoint/condition/TestWatchpointConditionAPI.py functionalities/watchpoint/watchpoint_events/TestWatchpointEvents.py functionalities/watchpoint/watchpoint_commands/condition/TestWatchpointConditionCmd.py LLDB Revision: 269168 -- You are receiving this mail because: You are the assignee for the bug. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [Bug 27710] Ptrace interface doesnt allow un-aligned watchpoints on aarch64 linux
https://llvm.org/bugs/show_bug.cgi?id=27710 Omair Javaid changed: What|Removed |Added Assignee|lldb-dev@lists.llvm.org |omair.jav...@linaro.org -- You are receiving this mail because: You are the assignee for the bug. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] LTO debug info
Thanks for the explanation and the patch.
I tried it and the exception is gone.
The debug info also seems complete. As complete as can be for an LTO build...
I attached a modified patch with the calls to ExtractDIEsIfNeeded() on separate
threads.
Should I submit it for review ?
-Philippe
From: Greg Clayton [gclay...@apple.com]
Sent: Tuesday, May 03, 2016 5:02 PM
To: Philippe Lavoie
Cc: lldb-dev@lists.llvm.org
Subject: Re: [lldb-dev] LTO debug info
> On May 3, 2016, at 6:35 AM, Philippe Lavoie
> wrote:
>
> The code accessing another CU while indexing is in DWARFCompileUnit::GetDIE.
> If the DIE is not in the current CU, it finds the CU that has it and calls
> its ::GetDIE method, accessing its m_die_array data...
>
> So the question is: is it a producer (CU should be self-contained) or a
> consumer (the indexing) bug ?
The indexing needs to be fixed. We probably need to start checking the DW_FORM
of an attribute before we try to get the DIE for it. So the problem seems to be
in DWARFCompileUnit::IndexPrivate() where when the tag is a DW_TAG_subprogram
it eventually does:
if (specification_die_form.IsValid())
{
DWARFDIE specification_die =
dwarf_cu->GetSymbolFileDWARF()->DebugInfo()->GetDIE
(DIERef(specification_die_form));
if (specification_die.GetParent().IsStructOrClass())
is_method = true;
}
This is the only call to GetDIE in the entire function. It is getting the DIE
so it can look to see who the parent it to see if the parent of the function is
a struct/class, which means it is a method, or anything else and the function
is just the basename of a raw function. So it seems like this should be OK to
access other DIEs as it isn't adding any information from the other DWARF file,
it is just using it to check who the parent of function (DW_TAG_subprogram) is.
So the real problem is that "ClearDIEs()" is being called too soon before
everyone is done using the DIEs. The reason this was being done is that you
might have 1 compile units and we want to partially parse the the DWARF and
only use what we need, but if we index everything we want to load the DIEs for
a compile unit and clear them after indexing if they weren't loaded before we
did the index so we don't take up loads of memory.
So what we need to do to fix this is:
1 - Run through all of the compile units first and see if each CU has the DIEs
parsed and remember this
2 - Index all compile units
3 - Clear any DIEs in any compile units that didn't have their DIEs parsed
_after_ all compile units have been indexed
A proposed patch is attached:
the main issue is now all DWARF is parsed on the current thread. So this patch
should be updated to run all of the ExtractDIEsIfNeeded() functions on separate
threads since this can be time consuming:
//--
// First figure out which compile units didn't have their DIEs already
// parsed and remember this. If no DIEs were parsed prior to this index
// function call, we are going to want to clear the CU dies after we
// are done indexing to make sure we don't pull in all DWARF dies, but
// we need to wait until all compile units have been indexed in case
// a DIE in one compile unit refers to another and the indexes accesses
// those DIEs.
//--
for (uint32_t cu_idx = 0; cu_idx < num_compile_units; ++cu_idx)
{
DWARFCompileUnit* dwarf_cu =
debug_info->GetCompileUnitAtIndex(cu_idx);
if (dwarf_cu)
{
// dwarf_cu->ExtractDIEsIfNeeded(false) will return zero if the
// DIEs for a compile unit have already been parsed.
clear_cu_dies[cu_idx] = dwarf_cu->ExtractDIEsIfNeeded(false) >
1;
}
}
>
> //--
> // GetDIE()
> //
> // Get the DIE (Debug Information Entry) with the specified offset by
> // first checking if the DIE is contained within this compile unit and
> // grabbing the DIE from this compile unit. Otherwise we grab the DIE
> // from the DWARF file.
> //--
> DWARFDIE
> DWARFCompileUnit::GetDIE (dw_offset_t die_offset)
> {
>if (die_offset != DW_INVALID_OFFSET)
>{
>if (m_dwo_symbol_file)
>return m_dwo_symbol_file->GetCompileUnit()->GetDIE(die_offset);
>
>if (ContainsDIEOffset(die_offset))
>{
>ExtractDIEsIfNeeded (false);
>DWARFDebugInfoEntry::iterator end = m_die_array.end();
>DWARFDebugInfoEntry::iterator pos =
> lower_bound(m_die_array.begin(), end, die_offset, CompareDIEOffset);
>if (pos != end)
>{
>if (die_offset == (*pos).GetOffset())
>
[lldb-dev] All windows Mutex objects are recursive???
From lldb/source/Host/windows/Mutex.cpp:
Mutex::Mutex () :
m_mutex()
{
m_mutex = static_cast(malloc(sizeof(CRITICAL_SECTION)));
InitializeCriticalSection(static_cast(m_mutex));
}
//--
// Default constructor.
//
// Creates a pthread mutex with "type" as the mutex type.
//--
Mutex::Mutex (Mutex::Type type) :
m_mutex()
{
m_mutex = static_cast(malloc(sizeof(CRITICAL_SECTION)));
InitializeCriticalSection(static_cast(m_mutex));
}
It also means that Condition.cpp doesn't act like its unix counterpart as the
pthread_contition_t requires that wait be called with a non recursive mutex.
Not sure what or if any issues are resulting from this, but I just thought
everyone should be aware.
Greg Clayton
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] All windows Mutex objects are recursive???
Yes, eventually we should move to std::mutex and std::condition_variable,
in which case it behaves as expected (std::mutex is non recursive,
std::mutex is recursive).
On Wed, May 11, 2016 at 2:20 PM Greg Clayton via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
> From lldb/source/Host/windows/Mutex.cpp:
>
>
> Mutex::Mutex () :
> m_mutex()
> {
> m_mutex =
> static_cast(malloc(sizeof(CRITICAL_SECTION)));
> InitializeCriticalSection(static_cast(m_mutex));
> }
>
> //--
> // Default constructor.
> //
> // Creates a pthread mutex with "type" as the mutex type.
> //--
> Mutex::Mutex (Mutex::Type type) :
> m_mutex()
> {
> m_mutex =
> static_cast(malloc(sizeof(CRITICAL_SECTION)));
> InitializeCriticalSection(static_cast(m_mutex));
> }
>
>
> It also means that Condition.cpp doesn't act like its unix counterpart as
> the pthread_contition_t requires that wait be called with a non recursive
> mutex. Not sure what or if any issues are resulting from this, but I just
> thought everyone should be aware.
>
> Greg Clayton
>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] All windows Mutex objects are recursive???
I mean std::recursive_mutex is recursive
On Wed, May 11, 2016 at 3:01 PM Zachary Turner wrote:
> Yes, eventually we should move to std::mutex and std::condition_variable,
> in which case it behaves as expected (std::mutex is non recursive,
> std::mutex is recursive).
>
>
>
> On Wed, May 11, 2016 at 2:20 PM Greg Clayton via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
>> From lldb/source/Host/windows/Mutex.cpp:
>>
>>
>> Mutex::Mutex () :
>> m_mutex()
>> {
>> m_mutex =
>> static_cast(malloc(sizeof(CRITICAL_SECTION)));
>> InitializeCriticalSection(static_cast(m_mutex));
>> }
>>
>> //--
>> // Default constructor.
>> //
>> // Creates a pthread mutex with "type" as the mutex type.
>> //--
>> Mutex::Mutex (Mutex::Type type) :
>> m_mutex()
>> {
>> m_mutex =
>> static_cast(malloc(sizeof(CRITICAL_SECTION)));
>> InitializeCriticalSection(static_cast(m_mutex));
>> }
>>
>>
>> It also means that Condition.cpp doesn't act like its unix counterpart as
>> the pthread_contition_t requires that wait be called with a non recursive
>> mutex. Not sure what or if any issues are resulting from this, but I just
>> thought everyone should be aware.
>>
>> Greg Clayton
>>
>> ___
>> lldb-dev mailing list
>> lldb-dev@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] All windows Mutex objects are recursive???
It would be nice to get a patch that gets rid of the Mutex.h/Mutex.cpp and
switches over to using C++11 std::mutex/std::recursive_mutex and get rid of
Condition.h/Condition.cpp for std::condition_variable. Then we can be more
consistent. We need to make sure the C++ standard libraries are ready on all
platforms first though.
Greg
> On May 11, 2016, at 3:01 PM, Zachary Turner wrote:
>
> I mean std::recursive_mutex is recursive
>
> On Wed, May 11, 2016 at 3:01 PM Zachary Turner wrote:
> Yes, eventually we should move to std::mutex and std::condition_variable, in
> which case it behaves as expected (std::mutex is non recursive, std::mutex is
> recursive).
>
>
>
> On Wed, May 11, 2016 at 2:20 PM Greg Clayton via lldb-dev
> wrote:
> From lldb/source/Host/windows/Mutex.cpp:
>
>
> Mutex::Mutex () :
> m_mutex()
> {
> m_mutex =
> static_cast(malloc(sizeof(CRITICAL_SECTION)));
> InitializeCriticalSection(static_cast(m_mutex));
> }
>
> //--
> // Default constructor.
> //
> // Creates a pthread mutex with "type" as the mutex type.
> //--
> Mutex::Mutex (Mutex::Type type) :
> m_mutex()
> {
> m_mutex =
> static_cast(malloc(sizeof(CRITICAL_SECTION)));
> InitializeCriticalSection(static_cast(m_mutex));
> }
>
>
> It also means that Condition.cpp doesn't act like its unix counterpart as the
> pthread_contition_t requires that wait be called with a non recursive mutex.
> Not sure what or if any issues are resulting from this, but I just thought
> everyone should be aware.
>
> Greg Clayton
>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [Bug 27719] New: No way to send stdin to remote process from command line
https://llvm.org/bugs/show_bug.cgi?id=27719 Bug ID: 27719 Summary: No way to send stdin to remote process from command line Product: lldb Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-dev@lists.llvm.org Reporter: vi...@nethacker.com CC: llvm-b...@lists.llvm.org Classification: Unclassified When I connect to a remote process, I get the (lldb) prompt back after launching a process that needs stdin vharron@tifa:~/ll/tot/lldb/test$ ../../build/host/bin/lldb (lldb) log enable -Tpn -f /tmp/packet.log gdb-remote all (lldb) log enable -Tpn -f /tmp/lldb.log lldb all (lldb) platform select remote-linux Platform: remote-linux Connected: no (lldb) platform connect connect://192.168.100.132:5432 Platform: remote-linux Triple: x86_64--linux-gnu OS Version: 3.13.0 (3.13.0-32-generic) Kernel: #57-Ubuntu SMP Tue Jul 15 03:51:08 UTC 2014 Hostname: ubuntu Connected: yes WorkingDir: /home/vharron/host (lldb) platform settings --working-dir /tmp option[4] --user-write has a short option -w that conflicts with option[0] --working-dir, short option won't be used for --user-write (lldb) file ~/ll/tot/lldb/test/python_api/process/io/process_io Current executable set to '~/ll/tot/lldb/test/python_api/process/io/process_io' (x86_64). (lldb) process launch -e /tmp/error.txt Process 6436 launched: '/usr/local/google/home/vharron/ll/tot/lldb/test/python_api/process/io/process_io' (x86_64) Hello world. (lldb) error: No auto repeat. (lldb) kill Process 6436 stopped Process 6436 exited with status = 9 (0x0009) (lldb) process launch Process 6460 launched: '/usr/local/google/home/vharron/ll/tot/lldb/test/python_api/process/io/process_io' (x86_64) Hello world. (lldb) We also need a test to protect this functionality once implemented. -- You are receiving this mail because: You are the assignee for the bug. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
