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

2018-01-06 Thread Pavel Labath via Phabricator via lldb-commits
labath added a comment. Maybe we could just change the lit script to use the value of `LLVM_ENABLE_ZLIB` as the trigger? That should work in both standalone and non-standalone builds (and it seems more clean -- I'm not sure why llvm does not do the same)? https://reviews.llvm.org/D41725 __

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

2018-01-06 Thread Pavel Labath via Phabricator via lldb-commits
labath accepted this revision. labath added a comment. This revision is now accepted and ready to land. lgtm, thanks. https://reviews.llvm.org/D41726 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/lis

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

2018-01-06 Thread Pavel Labath via Phabricator via lldb-commits
labath added a comment. Is the only difference between ppc64 and ppc64le ABIs in the endianness of the values? If so, could we make one unified ABI which takes the endianness as an argument (in the constructor, or as a template argument, or deduces it from target endiannes, ...) ? https://rev

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

2018-01-06 Thread Michał Górny via Phabricator via lldb-commits
mgorny added a comment. Maybe we could. I presumed people are using the separate variables for some reason. We'd have to check that it's properly sanitized when building in-tree and given to cmake though. https://reviews.llvm.org/D41725 ___ lldb-c

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

2018-01-06 Thread Pavel Labath via Phabricator via lldb-commits
labath added a comment. The ProcessGdbRemote part is not really testable in it's current form, but for the rest, you should be able to write a gdbremoteclient unittest (see unittests/Process/gdb-remote/GDBRemoteCommunicationClientTest.cpp). Comment at: source/Plugins/Process/

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

2018-01-06 Thread Pavel Labath via Phabricator via lldb-commits
labath added a comment. In https://reviews.llvm.org/D41725#969183, @mgorny wrote: > Maybe we could. I presumed people are using the separate variables for some > reason. We'd have to check that it's properly sanitized when building in-tree > and given to cmake though. I would expect that reas

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

2018-01-06 Thread Michał Górny via Phabricator via lldb-commits
mgorny added a comment. Well, it's actually more complex. In Gentoo we want to let the user choose whether he wants to build against zlib or without zlib support. So in the end there are two uses to be considered: 1. When the value is merely passed down from LLVM to indicate state of compressi

[Lldb-commits] [lldb] r321932 - [test] Use full PATH lookup for tools

2018-01-06 Thread Michal Gorny via lldb-commits
Author: mgorny Date: Sat Jan 6 02:20:25 2018 New Revision: 321932 URL: http://llvm.org/viewvc/llvm-project?rev=321932&view=rev Log: [test] Use full PATH lookup for tools Use full PATH when looking up test tools rather than just llvm tools directory. r320813 has added a lookup for 'lldb-test' whi

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

2018-01-06 Thread Michał Górny via Phabricator via lldb-commits
This revision was automatically updated to reflect the committed changes. Closed by commit rL321932: [test] Use full PATH lookup for tools (authored by mgorny, committed by ). Changed prior to commit: https://reviews.llvm.org/D41726?vs=128609&id=128843#toc Repository: rL LLVM https://review

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

2018-01-06 Thread Hal Finkel via Phabricator via lldb-commits
hfinkel added a comment. In https://reviews.llvm.org/D41702#969179, @labath wrote: > Is the only difference between ppc64 and ppc64le ABIs in the endianness of > the values? > If so, could we make one unified ABI which takes the endianness as an > argument (in the constructor, or as a template