[Lldb-commits] [PATCH] D39283: [lldb-dev] Update LLDB test cases for 'inlineStepping'

CarlosAlbertoEnciso added a comment. I have some issues running the LLDB Test Suite in 32-bit and 64-bit mode. From the LLDB documentation: https://lldb.llvm.org/test.html It is possible to customize the architecture of the test binaries and compiler used by appending -A and -C options respe

[Lldb-commits] [PATCH] D41725: [lldb] [test] Fix missing HAVE_LIBZ for tests in stand-alone builds

mgorny created this revision. mgorny added reviewers: labath, zturner, beanz. The HAVE_LIBZ variable is not exported by LLVM, and therefore is not available for reuse in stand-alone builds of other tools. Redefine it based on the value of LLVM_ENABLE_ZLIB. The same change has been already implemen

[Lldb-commits] [PATCH] D41726: [test] Use full PATH lookup for tools

mgorny created this revision. mgorny added reviewers: labath, zturner. Use full PATH when looking up test tools rather than just llvm tools directory. r320813 has added a lookup for 'lldb-test' which is part of LLDB tools rather than LLVM, and therefore is not present in llvm_tools_dir before LLDB

[Lldb-commits] [lldb] r321802 - Look for external types in all clang modules imported by the current symbol file.

Author: adrian Date: Thu Jan 4 08:42:05 2018 New Revision: 321802 URL: http://llvm.org/viewvc/llvm-project?rev=321802&view=rev Log: Look for external types in all clang modules imported by the current symbol file. This fixes a bug in -gmodules DWARF handling when debugging without a .dSYM bund

Re: [Lldb-commits] [lldb] r321802 - Look for external types in all clang modules imported by the current symbol file.

thanks! On Thu, Jan 4, 2018 at 5:42 PM, Adrian Prantl via lldb-commits wrote: > Author: adrian > Date: Thu Jan 4 08:42:05 2018 > New Revision: 321802 > > URL: http://llvm.org/viewvc/llvm-project?rev=321802&view=rev > Log: > Look for external types in all clang modules imported by the current sym

[Lldb-commits] [PATCH] D41702: Add SysV Abi for PPC64le

alexandreyy added a comment. Thanks, @clayborg. @labath , Could you commit this patch? https://reviews.llvm.org/D41702 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] r321833 - [IRExecutionUnit] Remove broken/dead code.

Author: davide Date: Thu Jan 4 15:37:18 2018 New Revision: 321833 URL: http://llvm.org/viewvc/llvm-project?rev=321833&view=rev Log: [IRExecutionUnit] Remove broken/dead code. Modified: lldb/trunk/source/Expression/IRExecutionUnit.cpp Modified: lldb/trunk/source/Expression/IRExecutionUnit.cp

[Lldb-commits] [PATCH] D41745: Handle O reply packets during qRcmd

owenpshaw created this revision. owenpshaw added a reviewer: clayborg. Gdb servers like openocd may send many $O reply packets for the client to output during a qRcmd command sequence. Currently, lldb interprets the first O packet as an unexpected response. Besides generating no output, this c

[Lldb-commits] [lldb] r321856 - [ArchSpec] Don't consider Unknown MachO64 as invalid.

Author: davide Date: Thu Jan 4 18:50:24 2018 New Revision: 321856 URL: http://llvm.org/viewvc/llvm-project?rev=321856&view=rev Log: [ArchSpec] Don't consider Unknown MachO64 as invalid. Even without a proper arch we can access line tables, etc.. Modified: lldb/trunk/source/Utility/ArchSpe

Re: [Lldb-commits] [lldb] r321856 - [ArchSpec] Don't consider Unknown MachO64 as invalid.

@Pavel, is there an easy way of testing this? m_core is a protected member of ArchSpec so we can't set it willy-nilly, but still I'd like to have some regression testing for the change. I'll take a look early tomorrow, but throwing this here in case you have ideas. Thanks! -- Davide On Thu, Jan

Re: [Lldb-commits] [lldb] r321856 - [ArchSpec] Don't consider Unknown MachO64 as invalid.

Write a unit test and make a class that inherits from it so it can access the protected member On Thu, Jan 4, 2018 at 6:54 PM Davide Italiano via lldb-commits < lldb-commits@lists.llvm.org> wrote: > @Pavel, is there an easy way of testing this? m_core is a protected > member of ArchSpec so we can'