Re: [lldb-dev] building only lldb with debug symbols
If you are on macOS, then the Xcode build has a "Debug" configuration which
builds clang/llvm Release+asserts with no debug info, and lldb at -O0 with
debug info.
Jim
> On Jun 28, 2018, at 2:58 AM, Pavel Labath via lldb-dev
> wrote:
>
> On Thu, 28 Jun 2018 at 04:34, Adrian Harris via lldb-dev
> wrote:
>>
>> Hi Everyone,
>>
>> I'm writing a gdb-server for a new architecture and need to be able to debug
>> lldb to track down issues. Unfortunately disk space is tight here and the
>> llvm debug build consumes north of 40Gb with debug symbols. Is there any way
>> to build *only* lldb with debug symbols (and no optimization)?
>
> Hi Adrian,
>
> This is a somewhat non-standard configuration, but there are a couple
> of ways you could achieve that. A couple which come to mind are:
> - If you're fine with hacking the cmake files then you could just
> insert something like
> set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -g0")
> into the root llvm CMakeLists.txt
> and then add
> set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -g")
> to lldb's CMakeLists.txt
>
> - If you want a solution which does not involve modifying the cmake
> files, you could build llvm and lldb separately. The llvm could be
> built with -g0 (or even in release mode if you really want) and then
> the stanalone lldb build would be -g.
>
> - You can also try building with -gsplit-dwarf
> (LLVM_USE_SPLIT_DWARF=On) to see if that saves enough space for things
> to work for you.
>
> pl
> ___
> 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] Linux: Failing lldb unit tests and TestLinuxCore.py
The core file tests should be fixed as of r335859. I tried reproing the python unit tests problem, but I couldn't get it to fail that way. I can help you get to the bottom of it if you're interested, but it's going to take some interactive debugging (for start I'd need to see the link command for the test binary in question). cheers, pl On Tue, 26 Jun 2018 at 16:33, Pavel Labath wrote: > > The BUILD_SHARED_LIBS part is likely to be the issue. LLDB libraries > have cyclic dependencies, which don't play well with shared libraries. > I think somebody "fixed" it some time ago (i.e., just made the flag be > ignored for lldb), but I'm not sure if he also checked the unit tests. > I'll see if I can reproduce that on my end. > On Tue, 26 Jun 2018 at 16:28, Gábor Márton wrote: > > > > Hi Pavel, > > > > I do an in-tree build, so lldb is next to clang. > > And I use ccache, could that be a problem? If yes then why just with the > > unit tests? > > Here is how I configured cmake: > > cmake ../../git/llvm -G Ninja -DCMAKE_EXPORT_COMPILE_COMMANDS=1 > > -DCMAKE_BUILD_TYPE=Release -DCMAKE_CXX_COMPILER=clang++ > > -DCMAKE_C_COMPILER=clang -DBUILD_SHARED_LIBS=1 -DLLVM_TARGETS_TO_BUILD=X86 > > -DLLVM_ENABLE_ASSERTIONS=1 > > > > Thanks, > > Gabor > > > > On Tue, Jun 26, 2018 at 5:05 PM Pavel Labath wrote: > >> > >> Hello Gabor, > >> > >> The error message (Option 'help-list' registered more than once) leads > >> me to believe that this is caused by an uncommon (for lldb, at least) > >> build configuration. Can you share your cmake configuration? > >> > >> I suspect TestLinuxCore is also failing due to unexpected build > >> configuration, specifically missing targets in llvm (mips?). I'll try > >> to fix that this week. > >> On Tue, 26 Jun 2018 at 14:44, Gábor Márton via lldb-dev > >> wrote: > >> > > >> > Hi > >> > > >> > By using "ninja check-lldb-unit" some of the unit tests fail with the > >> > tip of the master. (I am using Ubuntu Linux.) The error is always > >> > related to the CommandLine options: > >> > > >> > FAIL: lldb-Unit :: > >> > ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestBorrowedReferences > >> > (120 of 363) > >> > TEST 'lldb-Unit :: > >> > ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestBorrowedReferences' > >> > FAILED > >> > Note: Google Test filter = PythonDataObjectsTest.TestBorrowedReferences > >> > [==] Running 1 test from 1 test case. > >> > [--] Global test environment set-up. > >> > [--] 1 test from PythonDataObjectsTest > >> > [ RUN ] PythonDataObjectsTest.TestBorrowedReferences > >> > : CommandLine Error: Option 'help-list' registered more than once! > >> > LLVM ERROR: inconsistency in registered CommandLine options > >> > > >> > The other lit tests pass, except TestLinuxCore.py. > >> > > >> > I already set up LD_LIBRARY_PATH to point to $build/bin. > >> > Am I missing something else? > >> > > >> > Any help would be appreciated. > >> > > >> > Thanks, > >> > Gábor > >> > ___ > >> > 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] building only lldb with debug symbols
On Thu, 28 Jun 2018 at 04:34, Adrian Harris via lldb-dev
wrote:
>
> Hi Everyone,
>
> I'm writing a gdb-server for a new architecture and need to be able to debug
> lldb to track down issues. Unfortunately disk space is tight here and the
> llvm debug build consumes north of 40Gb with debug symbols. Is there any way
> to build *only* lldb with debug symbols (and no optimization)?
Hi Adrian,
This is a somewhat non-standard configuration, but there are a couple
of ways you could achieve that. A couple which come to mind are:
- If you're fine with hacking the cmake files then you could just
insert something like
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -g0")
into the root llvm CMakeLists.txt
and then add
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -g")
to lldb's CMakeLists.txt
- If you want a solution which does not involve modifying the cmake
files, you could build llvm and lldb separately. The llvm could be
built with -g0 (or even in release mode if you really want) and then
the stanalone lldb build would be -g.
- You can also try building with -gsplit-dwarf
(LLVM_USE_SPLIT_DWARF=On) to see if that saves enough space for things
to work for you.
pl
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Support of a lookup of variables values with PDB
Thank you for explanations! I'll create the converter to DWARF expressions. Regards, Aleksandr On Wed, Jun 27, 2018 at 5:38 PM Greg Clayton wrote: > > > On Jun 27, 2018, at 5:25 AM, Aleksandr Urakov via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > Hello! > > We want to add to LLDB a support of a lookup of variables values with PDB. > > Now SymbolFilePDB::ParseVariableForPDBData function uses an empty location > for variables, so e.g. `fr v` prints values as ''. Symbol > location information is available in a PDB (through > PDBSymbolData::getLocationType and so on), but not in the format of DWARF > expression. Do I understand correctly, that it is necessary to write some > converter of a PDB symbol location to a DWARF expression bytecode? Is this > the preferable way of solving the issue? What are pitfalls there? Please, > share your thoughts on this. > > > DWARF expressions are pretty powerful and provide all the opcode need to > describe variable locations. You will need to covert the PDB location to > the DWARF expression opcodes. > > Some examples: > variable is at SP + 4 = DW_OP_bregXXX(4) > > DW_OP_bregXXX where XXX is the register number for your stack pointer. > This opcode takes a single operand that is the offset from the register in > question. The variable value is expected to be at the load address in > memory. > > variable is in register 12 = DW_OP_reg12 > > There are 32 DW_OP_regXXX opcodes DW_OP_reg0 - DW_OP_reg31. If your > register value is higher than 32, then use DW_OP_regx which takes a ULEB128 > parameter which is the register number: > > variable is in register 46 = DW_OP_regx(46) > > Global variables: > > variable is at file address 0x1234 = DW_OP_addr(0x1234) > > The address here is a file address, or the file VM address of the global > as it is known in the object file. This address will be slid and covered to > a load address if needed at runtime. > > IF you have any other questions on converting your locations, let me know. > But the above examples should give you a good start. > > Greg > > > Regards, > Aleksandr > > -- > Aleksandr Urakov > Software Developer > JetBrains > http://www.jetbrains.com > The Drive to Develop > ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > > > -- Aleksandr Urakov Software Developer JetBrains http://www.jetbrains.com The Drive to Develop ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
