[lldb-dev] Mac build documentation out-of-date

[Sebastian Theophil via lldb-dev]

Hi,

I’ve tried to build lldb from scratch for the first time and noticed the build 
documentation is quite out-of-date.

http://lldb.llvm.org/build.html says to build the top-level Xcode project (with 
Xcode4 no less!), which references files that do not exist.
docs/building-with-debug-llvm.txt refers to a scripts/build-llvm.pl script that 
doesn’t exist

Instead, there’s a build-lldb-llvm-clang script and also a buildbot.py, neither 
of which is documented on the build.html website?

Building Xcode projects using CMake did work but the created Xcode project does 
not sign the binary, I had to do that by hand. (The codesigning docs still 
work!)

What’s the general idea? What is the recommended way to build lldb from Trunk 
at least on the Mac? If I knew, I might be able to fix the documentation.

Regards
Sebastian

--
Dr. Sebastian Theophil | 
stheop...@think-cell.com
Senior Software Engineer

We are looking for C++ Developers: http://www.think-cell.com/career

think-cell Software GmbH
http://www.think-cell.com
Chausseestr. 8/Ephone / fax +49 30 666473-10 / -19
10115 Berlin, Germany   US phone / fax  +1 800 891 8091 / +1 212 504 3039
Amtsgericht Berlin-Charlottenburg, HRB 85229 | European Union VAT Id DE813474306
Directors: Dr. Markus Hannebauer, Dr. Arno Schödl

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Listing memory regions in lldb

[Howard Hellyer via lldb-dev]

>> - Using GetMemoryRegionInfo to iterate might be quite expensive if 
there are many small memory regions.
> 
> Remember that the other use for GetMemoryRegionInfo() might be a user 
just asking about an address they have in a register or variable that is a 
pointer. So if we do add a more complex iteration scheme, feel free to do 
so, but please leave the call that ask about a single address intact so it 
can be used by clients

Yep, that's sensible. It gives a user an easy way to check things like 
"Does this char* really point to an area of writable memory?"

>> - Using GetMemoryRegionInfo over a remote connection on Linux and Mac 
worked well but seemed to coalesce some of the memory regions together.
> 
> You might want to add an extra parameter to not coalesce regions. Or if 
we start adding names to the memory regions (".text", ".data") or types 
(stack, heap, section from a file, guard page) then we might just start 
not coalescing the regions so we can see these differences. Or we can add 
more options to the API:

This may not be an issue. After a bit more digging I think it might be 
safer to have individual Process plug-ins implement 
GetMemoryRegionInfoList directly and they can use the GetMemoryRegionInfo 
iteration pattern if it's safe.

> SBMemoryRegionInfoList SBTarget::GetMemoryRegions(bool coalesce);

> Hopefully my comments have provided some insight. Let me know what you 
come up with.

I agree the SBMemoryRegionInfoList approach makes the most sense, it's 
much safer.

I think in my prototyping the main difference is that I've put 
GetMemoryRegions/GetMemoryRegionInfo on SBProcess simply because that's 
where the internal GetMemoryRegions/GetMemoryRegionInfo functions it calls 
are but I'm happy with either if you have a preference.

I'm assuming the best way forward is to submit patches is via 
http://reviews.llvm.org/ ?

Rather than submit a monolithic one is I was going to submit one for the 
SB API changes first, calling 
lldb_private::Process::GetMemoryRegionInfoList with that having a default 
unsupported impl like lldb_private::Process::GetMemoryRegionInfo.

After that I can submit patches to fill in 
lldb_private::Process::GetMemoryRegionInfoList (and GetMemoryRegionInfo 
where's it's missing) on a per platform basis. (The alternative was to 
start with a command that exploits the new Process API for listing regions 
and work out from there, down into the process plug-ins and up into the SB 
API.)

Let me know if there's a better way to do this!

Howard Hellyer
IBM Runtime Technologies, IBM Systems ___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Listing memory regions in lldb

[Greg Clayton via lldb-dev]

> On May 20, 2016, at 3:27 AM, Howard Hellyer  wrote:
> 
> >> - Using GetMemoryRegionInfo to iterate might be quite expensive if there 
> >> are many small memory regions.
> > 
> > Remember that the other use for GetMemoryRegionInfo() might be a user just 
> > asking about an address they have in a register or variable that is a 
> > pointer. So if we do add a more complex iteration scheme, feel free to do 
> > so, but please leave the call that ask about a single address intact so it 
> > can be used by clients
> 
> Yep, that's sensible. It gives a user an easy way to check things like "Does 
> this char* really point to an area of writable memory?"
> 
> >> - Using GetMemoryRegionInfo over a remote connection on Linux and Mac 
> >> worked well but seemed to coalesce some of the memory regions together.
> > 
> > You might want to add an extra parameter to not coalesce regions. Or if we 
> > start adding names to the memory regions (".text", ".data") or types 
> > (stack, heap, section from a file, guard page) then we might just start not 
> > coalescing the regions so we can see these differences. Or we can add more 
> > options to the API:
> 
> This may not be an issue. After a bit more digging I think it might be safer 
> to have individual Process plug-ins implement GetMemoryRegionInfoList 
> directly and they can use the GetMemoryRegionInfo iteration pattern if it's 
> safe.
> 
> > SBMemoryRegionInfoList SBTarget::GetMemoryRegions(bool coalesce);
> 
> > Hopefully my comments have provided some insight. Let me know what you come 
> > up with.
> 
> I agree the SBMemoryRegionInfoList approach makes the most sense, it's much 
> safer.
> 
> I think in my prototyping the main difference is that I've put 
> GetMemoryRegions/GetMemoryRegionInfo on SBProcess simply because that's where 
> the internal GetMemoryRegions/GetMemoryRegionInfo functions it calls are but 
> I'm happy with either if you have a preference.

On SBProcess is fine.

> I'm assuming the best way forward is to submit patches is via 
> http://reviews.llvm.org/ ?

Yep!

> 
> Rather than submit a monolithic one is I was going to submit one for the SB 
> API changes first, calling lldb_private::Process::GetMemoryRegionInfoList 
> with that having a default unsupported impl like 
> lldb_private::Process::GetMemoryRegionInfo.
> 
> After that I can submit patches to fill in 
> lldb_private::Process::GetMemoryRegionInfoList (and GetMemoryRegionInfo 
> where's it's missing) on a per platform basis. (The alternative was to start 
> with a command that exploits the new Process API for listing regions and work 
> out from there, down into the process plug-ins and up into the SB API.)
> 
> Let me know if there's a better way to do this!

Either way, doesn't matter to me. 

I look forward to seeing your patch.

Greg Clayton

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] Memory corruption due to Symtab::AddSymbol growth

[Eugene Birukov via lldb-dev]

Hi,
I am running into memory corruption in LLDB 3.8 release candidate on Linux 
Ubuntu 15.10. I am trying to access stack frame and the symbol on this frame is 
corrupted. Here is what I figured out:
"StackFrame" has field "m_sc" of type "SymbolContext""SymbolContext" has field 
"symbol" which is "Symbol*" pointer 
Now, when AddSymbol needs to grow its storage, the std::vector allocates new 
memory and makes  these "symbol" pointers dangling.Here is the call stack:
#0  0x7274188c in lldb_private::SymbolContextScope::~SymbolContextScope 
(this=0x12b5a58, __in_chrg=)at 
/home/eugenebi/llvm/tools/lldb/include/lldb/Symbol/SymbolContextScope.h:75#1  
0x7289f78a in lldb_private::Symbol::~Symbol (this=0x12b5a58, 
__in_chrg=)at 
/home/eugenebi/llvm/tools/lldb/include/lldb/Symbol/Symbol.h:21#2  
0x728b72e8 in std::_Destroy (__pointer=0x12b5a58) 
at /usr/include/c++/5/bits/stl_construct.h:93#3  0x728b5a9d in 
std::_Destroy_aux::__destroy (__first=0x12b5a58, 
__last=0x12c1710)at /usr/include/c++/5/bits/stl_construct.h:103#4  
0x728b3e41 in std::_Destroy (__first=0x12af710, 
__last=0x12c1710)at /usr/include/c++/5/bits/stl_construct.h:126#5  
0x728b241b in std::_Destroy (__first=0x12af710, __last=0x12c1710)at 
/usr/include/c++/5/bits/stl_construct.h:151#6  0x728b2a2f in 
std::vector 
>::_M_emplace_back_aux 
(this=0x9f6688) at /usr/include/c++/5/bits/vector.tcc:436#7  0x728b143d 
in std::vector 
>::push_back (this=0x9f6688, __x=...)at 
/usr/include/c++/5/bits/stl_vector.h:923#8  0x728ab0c0 in 
lldb_private::Symtab::AddSymbol (this=0x9f6680, symbol=...)at 
/home/eugenebi/llvm/tools/lldb/source/Symbol/Symtab.cpp:70#9  
0x72acba21 in ObjectFileELF::ResolveSymbolForAddress (this=0x9f6310, 
so_addr=..., verify_unique=false)at 
/home/eugenebi/llvm/tools/lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp:2881#10
 0x7273cc50 in lldb_private::Module::ResolveSymbolContextForAddress 
(this=0x9f5cb0, so_addr=..., resolve_scope=72, sc=...,
resolve_tail_call_address=false) at 
/home/eugenebi/llvm/tools/lldb/source/Core/Module.cpp:568#11 0x72b31f04 
in lldb_private::RegisterContextLLDB::InitializeZerothFrame (this=0x98687c0)
at 
/home/eugenebi/llvm/tools/lldb/source/Plugins/Process/Utility/RegisterContextLLDB.cpp:180#12
 0x72b31a34 in lldb_private::RegisterContextLLDB::RegisterContextLLDB 
(this=0x98687c0, thread=...,next_frame=std::shared_ptr (empty) 0x0, 
sym_ctx=..., frame_number=0, unwind_lldb=...)at 
/home/eugenebi/llvm/tools/lldb/source/Plugins/Process/Utility/RegisterContextLLDB.cpp:82#13
 0x72b2bb7a in lldb_private::UnwindLLDB::AddFirstFrame (this=0x1ee82b0) 
   at 
/home/eugenebi/llvm/tools/lldb/source/Plugins/Process/Utility/UnwindLLDB.cpp:97#14
 0x72b2cd01 in lldb_private::UnwindLLDB::DoGetFrameInfoAtIndex 
(this=0x1ee82b0, idx=0, cfa=@0x7fffc270: 18446744073709551615,
pc=@0x7fffc268: 18446744073709551615) at 
/home/eugenebi/llvm/tools/lldb/source/Plugins/Process/Utility/UnwindLLDB.cpp:422#15
 0x729ac64b in lldb_private::Unwind::GetFrameInfoAtIndex 
(this=0x1ee82b0, frame_idx=0, cfa=@0x7fffc270: 18446744073709551615,
pc=@0x7fffc268: 18446744073709551615) at 
/home/eugenebi/llvm/tools/lldb/include/lldb/Target/Unwind.h:78#16 
0x729aa4a9 in lldb_private::StackFrameList::GetFramesUpTo 
(this=0x9868250, end_idx=0)at 
/home/eugenebi/llvm/tools/lldb/source/Target/StackFrameList.cpp:308#17 
0x729ab150 in lldb_private::StackFrameList::GetFrameAtIndex 
(this=0x9868250, idx=0)at 
/home/eugenebi/llvm/tools/lldb/source/Target/StackFrameList.cpp:546#18 
0x729775fa in lldb_private::Thread::GetStackFrameAtIndex 
(this=0x7ff6a805d4f0, idx=0)at 
/home/eugenebi/llvm/tools/lldb/include/lldb/Target/Thread.h:539#19 
0x71032f0e in lldb::SBThread::GetFrameAtIndex (this=0x7fffce30, 
idx=0)at /home/eugenebi/llvm/tools/lldb/source/API/SBThread.cpp:1347
Thanks,Eugene ___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Memory corruption due to Symtab::AddSymbol growth

[Eugene Birukov via lldb-dev]

Hi,
I am looking through LLDB code... Another dangerous operation is 
Symtab::Finalize() that just swaps the array. This is especially bad since it 
will defeat something like quick-and-dirty hack of preallocating a huge vector 
upfront.
My first impulse to fix that (maybe just temporary to get me unblocked) was 
neuter that Finalize() and replace vector with dequeue. But unfortunately there 
are places when we take address to the first element and assume the rest of 
memory is contiguous - say, we call ::bsearch() on it. 
Apparently, allocating each symbol separately and replacing the vector of 
elements with the vector of (smart) pointers would work, but it will hurt 
performance and probably cause the change touching lots of code...
So, any insights how to fix it? 
Thanks,Eugene

From: eugen...@hotmail.com
To: lldb-dev@lists.llvm.org
Subject: Memory corruption due to Symtab::AddSymbol growth
Date: Fri, 20 May 2016 12:37:15 -0700




Hi,
I am running into memory corruption in LLDB 3.8 release candidate on Linux 
Ubuntu 15.10. I am trying to access stack frame and the symbol on this frame is 
corrupted. Here is what I figured out:
"StackFrame" has field "m_sc" of type "SymbolContext""SymbolContext" has field 
"symbol" which is "Symbol*" pointer 
Now, when AddSymbol needs to grow its storage, the std::vector allocates new 
memory and makes  these "symbol" pointers dangling.Here is the call stack:
#0  0x7274188c in lldb_private::SymbolContextScope::~SymbolContextScope 
(this=0x12b5a58, __in_chrg=)at 
/home/eugenebi/llvm/tools/lldb/include/lldb/Symbol/SymbolContextScope.h:75#1  
0x7289f78a in lldb_private::Symbol::~Symbol (this=0x12b5a58, 
__in_chrg=)at 
/home/eugenebi/llvm/tools/lldb/include/lldb/Symbol/Symbol.h:21#2  
0x728b72e8 in std::_Destroy (__pointer=0x12b5a58) 
at /usr/include/c++/5/bits/stl_construct.h:93#3  0x728b5a9d in 
std::_Destroy_aux::__destroy (__first=0x12b5a58, 
__last=0x12c1710)at /usr/include/c++/5/bits/stl_construct.h:103#4  
0x728b3e41 in std::_Destroy (__first=0x12af710, 
__last=0x12c1710)at /usr/include/c++/5/bits/stl_construct.h:126#5  
0x728b241b in std::_Destroy (__first=0x12af710, __last=0x12c1710)at 
/usr/include/c++/5/bits/stl_construct.h:151#6  0x728b2a2f in 
std::vector 
>::_M_emplace_back_aux 
(this=0x9f6688) at /usr/include/c++/5/bits/vector.tcc:436#7  0x728b143d 
in std::vector 
>::push_back (this=0x9f6688, __x=...)at 
/usr/include/c++/5/bits/stl_vector.h:923#8  0x728ab0c0 in 
lldb_private::Symtab::AddSymbol (this=0x9f6680, symbol=...)at 
/home/eugenebi/llvm/tools/lldb/source/Symbol/Symtab.cpp:70#9  
0x72acba21 in ObjectFileELF::ResolveSymbolForAddress (this=0x9f6310, 
so_addr=..., verify_unique=false)at 
/home/eugenebi/llvm/tools/lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp:2881#10
 0x7273cc50 in lldb_private::Module::ResolveSymbolContextForAddress 
(this=0x9f5cb0, so_addr=..., resolve_scope=72, sc=...,
resolve_tail_call_address=false) at 
/home/eugenebi/llvm/tools/lldb/source/Core/Module.cpp:568#11 0x72b31f04 
in lldb_private::RegisterContextLLDB::InitializeZerothFrame (this=0x98687c0)
at 
/home/eugenebi/llvm/tools/lldb/source/Plugins/Process/Utility/RegisterContextLLDB.cpp:180#12
 0x72b31a34 in lldb_private::RegisterContextLLDB::RegisterContextLLDB 
(this=0x98687c0, thread=...,next_frame=std::shared_ptr (empty) 0x0, 
sym_ctx=..., frame_number=0, unwind_lldb=...)at 
/home/eugenebi/llvm/tools/lldb/source/Plugins/Process/Utility/RegisterContextLLDB.cpp:82#13
 0x72b2bb7a in lldb_private::UnwindLLDB::AddFirstFrame (this=0x1ee82b0) 
   at 
/home/eugenebi/llvm/tools/lldb/source/Plugins/Process/Utility/UnwindLLDB.cpp:97#14
 0x72b2cd01 in lldb_private::UnwindLLDB::DoGetFrameInfoAtIndex 
(this=0x1ee82b0, idx=0, cfa=@0x7fffc270: 18446744073709551615,
pc=@0x7fffc268: 18446744073709551615) at 
/home/eugenebi/llvm/tools/lldb/source/Plugins/Process/Utility/UnwindLLDB.cpp:422#15
 0x729ac64b in lldb_private::Unwind::GetFrameInfoAtIndex 
(this=0x1ee82b0, frame_idx=0, cfa=@0x7fffc270: 18446744073709551615,
pc=@0x7fffc268: 18446744073709551615) at 
/home/eugenebi/llvm/tools/lldb/include/lldb/Target/Unwind.h:78#16 
0x729aa4a9 in lldb_private::StackFrameList::GetFramesUpTo 
(this=0x9868250, end_idx=0)at 
/home/eugenebi/llvm/tools/lldb/source/Target/StackFrameList.cpp:308#17 
0x729ab150 in lldb_private::StackFrameList::GetFrameAtIndex 
(this=0x9868250, idx=0)at 
/home/eugenebi/llvm/tools/lldb/source/Target/StackFrameList.cpp:546#18 
0x729775fa in lldb_private::Thread::GetStackFrameAtIndex 
(this=0x7ff6a805d4f0, idx=0)at 
/home/eugenebi/llvm/tools/lldb/include/lldb/Target/Thread.h:539#19 
0x71032f0e in lldb::SBThread::GetFrameAtIndex (this=0x7fffce30, 
idx=0)at /home/eugenebi/llvm/tools/lldb/source/API/SBThread.cpp:1347
Thanks,Eugene

Re: [lldb-dev] Memory corruption due to Symtab::AddSymbol growth

[Greg Clayton via lldb-dev]

> On May 20, 2016, at 3:15 PM, Eugene Birukov via lldb-dev 
>  wrote:
> 
> Hi,
> 
> I am looking through LLDB code... Another dangerous operation is 
> Symtab::Finalize() that just swaps the array. This is especially bad since it 
> will defeat something like quick-and-dirty hack of preallocating a huge 
> vector upfront.
> 
> My first impulse to fix that (maybe just temporary to get me unblocked) was 
> neuter that Finalize() and replace vector with dequeue. But unfortunately 
> there are places when we take address to the first element and assume the 
> rest of memory is contiguous - say, we call ::bsearch() on it. 
> 
> Apparently, allocating each symbol separately and replacing the vector of 
> elements with the vector of (smart) pointers would work, but it will hurt 
> performance and probably cause the change touching lots of code...
> 
> So, any insights how to fix it? 

You can do anything you want when constructing the symbol table on the first 
call to ObjectFile::GetSymtab(), but once you return a "Symtab *" from your 
object file you can never add or change due to exactly this issue. So the bug 
is that ObjectFileELF::ResolveSymbolForAddress() is adding a symbol on the fly 
which must be fixed and can't happen. All symbols need to be added on the first 
call to "ObjectFile::GetSymtab()".

The ResolveSymbolForAddress doesn't seem to be in ObjectFileELF in top of tree. 
Maybe you can cherry pick the fix over to the LLDB 3.8 branch.
> 
> Thanks,
> Eugene
> 
> From: eugen...@hotmail.com
> To: lldb-dev@lists.llvm.org
> Subject: Memory corruption due to Symtab::AddSymbol growth
> Date: Fri, 20 May 2016 12:37:15 -0700
> 
> Hi,
> 
> I am running into memory corruption in LLDB 3.8 release candidate on Linux 
> Ubuntu 15.10. 
> I am trying to access stack frame and the symbol on this frame is corrupted. 
> Here is what I figured out:
> 
>   • "StackFrame" has field "m_sc" of type "SymbolContext"
>   • "SymbolContext" has field "symbol" which is "Symbol*" pointer 
> 
> Now, when AddSymbol needs to grow its storage, the std::vector allocates new 
> memory and makes  these "symbol" pointers dangling.
> Here is the call stack:
> 
> #0  0x7274188c in 
> lldb_private::SymbolContextScope::~SymbolContextScope (this=0x12b5a58, 
> __in_chrg=)
> at 
> /home/eugenebi/llvm/tools/lldb/include/lldb/Symbol/SymbolContextScope.h:75
> #1  0x7289f78a in lldb_private::Symbol::~Symbol (this=0x12b5a58, 
> __in_chrg=)
> at /home/eugenebi/llvm/tools/lldb/include/lldb/Symbol/Symbol.h:21
> #2  0x728b72e8 in std::_Destroy 
> (__pointer=0x12b5a58) at /usr/include/c++/5/bits/stl_construct.h:93
> #3  0x728b5a9d in 
> std::_Destroy_aux::__destroy 
> (__first=0x12b5a58, __last=0x12c1710)
> at /usr/include/c++/5/bits/stl_construct.h:103
> #4  0x728b3e41 in std::_Destroy 
> (__first=0x12af710, __last=0x12c1710)
> at /usr/include/c++/5/bits/stl_construct.h:126
> #5  0x728b241b in std::_Destroy lldb_private::Symbol> (__first=0x12af710, __last=0x12c1710)
> at /usr/include/c++/5/bits/stl_construct.h:151
> #6  0x728b2a2f in std::vector std::allocator 
> >::_M_emplace_back_aux onst&> (this=0x9f6688) at /usr/include/c++/5/bits/vector.tcc:436
> #7  0x728b143d in std::vector std::allocator >::push_back (this=0x9f6688, __x=...)
> at /usr/include/c++/5/bits/stl_vector.h:923
> #8  0x728ab0c0 in lldb_private::Symtab::AddSymbol (this=0x9f6680, 
> symbol=...)
> at /home/eugenebi/llvm/tools/lldb/source/Symbol/Symtab.cpp:70
> #9  0x72acba21 in ObjectFileELF::ResolveSymbolForAddress 
> (this=0x9f6310, so_addr=..., verify_unique=false)
> at 
> /home/eugenebi/llvm/tools/lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp:2881
> #10 0x7273cc50 in 
> lldb_private::Module::ResolveSymbolContextForAddress (this=0x9f5cb0, 
> so_addr=..., resolve_scope=72, sc=...,
> resolve_tail_call_address=false) at 
> /home/eugenebi/llvm/tools/lldb/source/Core/Module.cpp:568
> #11 0x72b31f04 in 
> lldb_private::RegisterContextLLDB::InitializeZerothFrame (this=0x98687c0)
> at 
> /home/eugenebi/llvm/tools/lldb/source/Plugins/Process/Utility/RegisterContextLLDB.cpp:180
> #12 0x72b31a34 in 
> lldb_private::RegisterContextLLDB::RegisterContextLLDB (this=0x98687c0, 
> thread=...,
> next_frame=std::shared_ptr (empty) 0x0, sym_ctx=..., frame_number=0, 
> unwind_lldb=...)
> at 
> /home/eugenebi/llvm/tools/lldb/source/Plugins/Process/Utility/RegisterContextLLDB.cpp:82
> #13 0x72b2bb7a in lldb_private::UnwindLLDB::AddFirstFrame 
> (this=0x1ee82b0)
> at 
> /home/eugenebi/llvm/tools/lldb/source/Plugins/Process/Utility/UnwindLLDB.cpp:97
> #14 0x72b2cd01 in lldb_private::UnwindLLDB::DoGetFrameInfoAtIndex 
> (this=0x1ee82b0, idx=0, cfa=@0x7fffc270: 18446744073709551615,
> pc=@0x7fffc268: 18446744073709551615) at 
> /home/eugenebi/llvm/tools/lldb/source/Plugins/Process/Utility/UnwindLLDB.cpp:422
> #15 0x0