[Lldb-commits] [lldb] 9890cc2 - [lldb] Fix LLDB build after API change to printInst (D72172)

[Raphael Isemann via lldb-commits]

Author: Raphael Isemann
Date: 2020-01-07T08:33:35+01:00
New Revision: 9890cc2ef08576cc16e32aff4288e7a7821a25f7

URL: 
https://github.com/llvm/llvm-project/commit/9890cc2ef08576cc16e32aff4288e7a7821a25f7
DIFF: 
https://github.com/llvm/llvm-project/commit/9890cc2ef08576cc16e32aff4288e7a7821a25f7.diff

LOG: [lldb] Fix LLDB build after API change to printInst (D72172)

It seems in D72172 we always pass a 0 as the new default argument so let's
do the same in LLDB to get the build bot running.

Added: 


Modified: 
lldb/source/Plugins/Disassembler/llvm/DisassemblerLLVMC.cpp

Removed: 




diff  --git a/lldb/source/Plugins/Disassembler/llvm/DisassemblerLLVMC.cpp 
b/lldb/source/Plugins/Disassembler/llvm/DisassemblerLLVMC.cpp
index fa9dae0c816e..399f8031bfe9 100644
--- a/lldb/source/Plugins/Disassembler/llvm/DisassemblerLLVMC.cpp
+++ b/lldb/source/Plugins/Disassembler/llvm/DisassemblerLLVMC.cpp
@@ -1034,8 +1034,8 @@ void DisassemblerLLVMC::MCDisasmInstance::PrintMCInst(
   llvm::raw_string_ostream comments_stream(comments_string);
 
   m_instr_printer_up->setCommentStream(comments_stream);
-  m_instr_printer_up->printInst(_inst, inst_stream, llvm::StringRef(),
-*m_subtarget_info_up);
+  m_instr_printer_up->printInst(_inst, 0, llvm::StringRef(),
+*m_subtarget_info_up, inst_stream);
   m_instr_printer_up->setCommentStream(llvm::nulls());
   comments_stream.flush();
 



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

[Lldb-commits] [PATCH] D71801: [lldb/Lua] Make lldb.debugger et al available to Lua

[Jim Ingham via Phabricator via lldb-commits]

jingham added a comment.

In D71801#1794758 , @labath wrote:

> +Jim, for his thoughts on debugger+interpreter relationship
>
> I think this is the time to step back and discuss the relationship between 
> debugger and script interpreter contexts...


I actually have no strong opinion about HOW this should be implemented.  Before 
starting on lldb, I had mostly used Tcl when I was incorporating a scripting 
language into various tools.  In Tcl, it was natural to make separate 
independent interpreters.  For instance, the security model for Tcl involved 
making a secure interpreter that forwarded messages to a shadow - insecure - 
interpreter that would implement whatever sandboxing you wanted to do.  Tcl 
interpreters were independent entities with no shared state.  That was the 
model I was working on when we chose to use Python for lldb, but that's not 
really how Python thinks of interpreters, and as you note, that caused us a 
bunch of headaches.

I do feel pretty strongly that to the user, every SBDebugger should have a 
separate interpreter state.  That really has to be true.  In Xcode, each 
SBDebugger represents a separate project that the user is debugging, and these 
often have no relation to one another.  Doing something in one script 
interpreter and having that affect what should be an entirely independent 
debugging session would be bad.  Since it is not uncommon for data formatters 
and Python command modules to use some global state, this could lead to some 
really frustrating bugs.

It isn't surprising that we have to do different things for each interpreter.  
For instance, in Tcl you'd just create a new interpreter and you'd be done.

So my take is that being able to support multiple independent interpreters is a 
minimum requirement for supporting a scripting language in lldb.  If it can't 
do that, then we shouldn't try to support it.

I don't know enough about Lua to know whether it passes this (fairly low) bar...

> So, the way I understand the python code, our intention really was to have 
> each (SB)Debugger be independently scriptable, but achieving this with python 
> was hard, as the python state is very global. That's why the python script 
> interpreter needs to jump through a lot of hoops in order to make the 
> Debuggers *appear* to be independent. Here, you're setting yourself up to do 
> the same with lua. That is not completely unreasonable (it's consistent, at 
> the very least), but:
>  a) it may not be possible if lua is not sufficiently flexible to enable 
> faking independent global variables
> 
>(lldb) script
>Python Interactive Interpreter. To exit, type 'quit()', 'exit()' or Ctrl-D.
>   >>> foobar = 47
>   >>> foobar
>47
>   >>> d = lldb.SBDebugger.Create()
>   >>> d.HandleCommand("script foobar = 42")
>   >>> foobar
>47
>   >>> d.HandleCommand("script foobar"))
>42
>
> 
> In particular, a lua context (AFAIK) is completely single-threaded so two 
> debugger objects would never be able to run the lua interpreter concurrently.
> 
> b) It is unnecessary, because lua is perfectly capable of creating completely 
> independent contexts.
> 
> For these reasons, I'd like to explore the possibility of just creating 
> distinct lua contexts for each (SB)Debugger object. I think we could drop a 
> lot of complexity this way (the weird `session_is_active` "locking" is just 
> the tip of the iceberg). Doing that will probably require a bit of 
> refactoring, as right now the assumption is that each ScriptInterpreter 
> instance is global, but I don't think that should be too hard (for python we 
> could have a per-debugger shin, backed by a global object).
> 
> It may turn out that this is a dead-end, because the lua context will be "too 
> independent", but I'd be sad if we didn't even try that. In particular, if 
> this pans out and we think that's a good design, I think we could do some 
> work to cleanup/simplify python as a result (PyInterpreterState_New 
>  and 
> friends).




CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D71801/new/

https://reviews.llvm.org/D71801



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

[Lldb-commits] [lldb] 450073c - Change the patterns to include the prefix '= ' so we don't pass errantly.

[Jason Molenda via lldb-commits]

Author: Jason Molenda
Date: 2020-01-06T15:20:13-08:00
New Revision: 450073c639d7f182e48ec8b1b588212194089a52

URL: 
https://github.com/llvm/llvm-project/commit/450073c639d7f182e48ec8b1b588212194089a52
DIFF: 
https://github.com/llvm/llvm-project/commit/450073c639d7f182e48ec8b1b588212194089a52.diff

LOG: Change the patterns to include the prefix '= ' so we don't pass errantly.
Looking at a sometimes-passing test case on a platform
where random values were being returned - sometimes
the expected digit ('1' or '2') would be included in the
random returned value.  Add a prefix to reduce the likelihood of
this a bit.

Added: 


Modified: 

lldb/packages/Python/lldbsuite/test/commands/expression/call-overridden-method/TestCallOverriddenMethod.py

Removed: 




diff  --git 
a/lldb/packages/Python/lldbsuite/test/commands/expression/call-overridden-method/TestCallOverriddenMethod.py
 
b/lldb/packages/Python/lldbsuite/test/commands/expression/call-overridden-method/TestCallOverriddenMethod.py
index 2ad0c313d601..57987c8cb364 100644
--- 
a/lldb/packages/Python/lldbsuite/test/commands/expression/call-overridden-method/TestCallOverriddenMethod.py
+++ 
b/lldb/packages/Python/lldbsuite/test/commands/expression/call-overridden-method/TestCallOverriddenMethod.py
@@ -40,10 +40,10 @@ def test_call_on_base(self):
 
 # Test call to method in base class (this should always work as the 
base
 # class method is never an override).
-self.expect("expr b->foo()", substrs=["2"])
+self.expect("expr b->foo()", substrs=["= 2"])
 
 # Test calling the base class.
-self.expect("expr realbase.foo()", substrs=["1"])
+self.expect("expr realbase.foo()", substrs=["= 1"])
 
 @skipIfLinux # Returns wrong result code on some platforms.
 def test_call_on_derived(self):
@@ -61,7 +61,7 @@ def test_call_on_derived(self):
 # Test call to overridden method in derived class (this will fail if 
the
 # overrides table is not correctly set up, as Derived::foo will be 
assigned
 # a vtable entry that does not exist in the compiled program).
-self.expect("expr d.foo()", substrs=["2"])
+self.expect("expr d.foo()", substrs=["= 2"])
 
 @skipIf(oslist=["linux"], archs=["aarch64"])
 @expectedFailureAll(oslist=["windows"], bugnumber="llvm.org/pr43707")
@@ -78,5 +78,5 @@ def test_call_on_temporary(self):
 self.runCmd("run", RUN_SUCCEEDED)
 
 # Test with locally constructed instances.
-self.expect("expr Base().foo()", substrs=["1"])
-self.expect("expr Derived().foo()", substrs=["2"])
+self.expect("expr Base().foo()", substrs=["= 1"])
+self.expect("expr Derived().foo()", substrs=["= 2"])



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

[Lldb-commits] [lldb] 59fadc1 - [NSArray] Remove a very old and deprecated formatter.

[Davide Italiano via lldb-commits]

Author: Davide Italiano
Date: 2020-01-06T14:58:37-08:00
New Revision: 59fadc14eeb1d63177b76147b26348a106ac1f9b

URL: 
https://github.com/llvm/llvm-project/commit/59fadc14eeb1d63177b76147b26348a106ac1f9b
DIFF: 
https://github.com/llvm/llvm-project/commit/59fadc14eeb1d63177b76147b26348a106ac1f9b.diff

LOG: [NSArray] Remove a very old and deprecated formatter.

Checked with the Foundation folks.

Added: 


Modified: 
lldb/source/Plugins/Language/ObjC/NSArray.cpp

Removed: 




diff  --git a/lldb/source/Plugins/Language/ObjC/NSArray.cpp 
b/lldb/source/Plugins/Language/ObjC/NSArray.cpp
index 0ac7fb6d2330..73335aff2fd7 100644
--- a/lldb/source/Plugins/Language/ObjC/NSArray.cpp
+++ b/lldb/source/Plugins/Language/ObjC/NSArray.cpp
@@ -96,31 +96,6 @@ class GenericNSArrayMSyntheticFrontEnd : public 
NSArrayMSyntheticFrontEndBase {
   D64 *m_data_64;
 };
   
-namespace Foundation109 {
-  struct DataDescriptor_32 {
-uint32_t _used;
-uint32_t _priv1 : 2;
-uint32_t _size : 30;
-uint32_t _priv2 : 2;
-uint32_t _offset : 30;
-uint32_t _priv3;
-uint32_t _data;
-  };
-  
-  struct DataDescriptor_64 {
-uint64_t _used;
-uint64_t _priv1 : 2;
-uint64_t _size : 62;
-uint64_t _priv2 : 2;
-uint64_t _offset : 62;
-uint32_t _priv3;
-uint64_t _data;
-  };
-  
-  using NSArrayMSyntheticFrontEnd =
-  GenericNSArrayMSyntheticFrontEnd;
-}
-  
 namespace Foundation1010 {
   struct DataDescriptor_32 {
 uint32_t _used;
@@ -858,8 +833,6 @@ lldb_private::formatters::NSArraySyntheticFrontEndCreator(
   return (new Foundation1428::NSArrayMSyntheticFrontEnd(valobj_sp));
 if (runtime->GetFoundationVersion() >= 1100)
   return (new Foundation1010::NSArrayMSyntheticFrontEnd(valobj_sp));
-else
-  return (new Foundation109::NSArrayMSyntheticFrontEnd(valobj_sp));
   } else if (class_name == g_NSCallStackArray) {
 return (new CallStackArray::NSCallStackArraySyntheticFrontEnd(valobj_sp));
   } else {



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

Re: [Lldb-commits] [lldb] 8612e92 - [lldb][NFC] Remove GetASTContext call in ClangDeclVendor

[Greg Clayton via lldb-commits]

Raphael is correct that the idea behind all of the "Compiler" classes is to 
abstract us from the TypeSystem that is being used, so they should stay "void 
*". I would rather not have each Compiler class make a union of pointers. 
CompilerType looks like:

class CompilerType {
  ...
private:
  lldb::opaque_compiler_type_t m_type = nullptr;
  TypeSystem *m_type_system = nullptr;
};

If would rather not see:

class CompilerType {
  ...
private:
  union {
clang::Type*clang;
swift::Type *swift;
  };
  TypeSystem *m_type_system = nullptr;
};

Because then every type systems that gets installed has to modify this file and 
add forward declarations. It is very nice that if we don't compile in the Swift 
support that we don't need to change CompilerType and anyone that comes along 
(rust, go, etc) can have their own type systems that are completely abstracted 
without any need to modify CompilerType.h, CompilerDecl.h, etc...



> On Jan 3, 2020, at 12:50 AM, Raphael “Teemperor” Isemann via lldb-commits 
>  wrote:
> 
> We could use clang::Decl* etc. in these classes but that would defeat the 
> whole concept that they are supposed to implement. CompilerType, 
> CompilerDecl, etc.. are all classes that represent their respective 
> equivalent in a language plugin. For Clang that is indeed clang::Type* and 
> clang::Decl*, but Swift is storing swift::Type* and swift::Decl* in these 
> void* pointers (and passes a SwiftASTContext* instead of a ClangASTContext* 
> as a m_type_system). So if we change that to clang::Decl* then the all other 
> language plugins like Swift are effectively broken. It would also mean that 
> generic LLDB code using these classes would have a hard dependency on Clang.
> 
> And there shouldn’t be any place where we unconditionally cast this to 
> clang::Decl* as this would directly crash swift-lldb. The m_type_system 
> (which is either ClangASTContext or SwiftASTContext) can freely cast the 
> void* to clang::Decl/swift::Decl as the checking happens through the virtual 
> function call to the m_type_system interface (Swift types always have a 
> SwiftASTContext as m_type_system, Clang types have a ClangASTContext as 
> m_type_system).
> 
> Having said that, I’m not saying that the void* pointers in these classes are 
> the best solution we could have here (there is a reason why I keep removing 
> all these void* pointer conversions). If you see a way to get rid of them, 
> then be my guest.
> 
>> On 3. Jan 2020, at 01:52, Shafik Yaghmour  wrote:
>> 
>> To further clarify all the member functions of CompilerDecl e.g.:
>> 
>> GetMangledName(…)
>> GetDeclContext(…)
>> 
>> End up passing m_opaque_decl as an argument to a member function of 
>> m_type_system and in these member functions they unconditionally cast the 
>> argument to Decl* so why not make m_opaque_decl a Decl*
>> 
>>> On Jan 2, 2020, at 4:20 PM, Shafik Yaghmour via lldb-commits 
>>>  wrote:
>>> 
>>> Apologies, m_opaque_decl member of CompilerDecl and operator < in 
>>> CompilerDecl.h 
>>> 
 On Jan 2, 2020, at 3:54 PM, Raphael “Teemperor” Isemann 
  wrote:
 
 Not sure if I can follow. What variable should just be a Decl* and what 
 operator>>> 
 (Also yeah that reinterpret_cast could also be a static_cast)
 
> On Jan 3, 2020, at 12:38 AM, Shafik Yaghmour  wrote:
> 
> I am not crazy about the reinterpret_cast although if we look inside 
> CompilerDecl impl we can see that basically it is always assuming it is a 
> Decl* and just C-style casts it as such. So why not just make it a Decl*
> 
> Also operator<(…) is super sketchy doing a < on void* 
> 
>> On Dec 28, 2019, at 6:52 AM, Raphael Isemann via lldb-commits 
>>  wrote:
>> 
>> 
>> Author: Raphael Isemann
>> Date: 2019-12-28T15:20:19+01:00
>> New Revision: 8612e92ed590e615f9f56e4fb86a1fdaf3a39e15
>> 
>> URL: 
>> https://github.com/llvm/llvm-project/commit/8612e92ed590e615f9f56e4fb86a1fdaf3a39e15
>> DIFF: 
>> https://github.com/llvm/llvm-project/commit/8612e92ed590e615f9f56e4fb86a1fdaf3a39e15.diff
>> 
>> LOG: [lldb][NFC] Remove GetASTContext call in ClangDeclVendor
>> 
>> Instead of returning NamedDecls and then calling GetASTContext
>> to find back the ClangASTContext we used can just implement the
>> FindDecl variant that returns CompilerDecls (and implement the
>> other function by throwing away the ClangASTContext part of the
>> compiler decl).
>> 
>> Added: 
>> 
>> 
>> Modified: 
>> lldb/source/Plugins/ExpressionParser/Clang/ClangDeclVendor.cpp
>> lldb/source/Plugins/ExpressionParser/Clang/ClangDeclVendor.h
>> lldb/source/Plugins/ExpressionParser/Clang/ClangModulesDeclVendor.cpp
>> lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCDeclVendor.cpp
>> lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCDeclVendor.h
>> 
>> Removed: 
>> 
>> 

[Lldb-commits] [PATCH] D72133: Data formatters: Look through array element typedefs

[Greg Clayton via Phabricator via lldb-commits]

clayborg added a comment.

So as long as the following are true from this patch I am ok:

- if I ask for the array element type of "str" in the test that was added, it 
should return "MCHAR". We shouldn't be removing any typedefs from the type. The 
user can call SBType::GetCanonicalType() if they need to (or equivalent with 
internal APIs)
- If there are no formatters for "MCHAR[]" we can fall back to "char[]".
- If there are no formatters for "MMCHAR[]" from my example we fall back to the 
_first_ array formatter that supports the array of typedefs, or back to the the 
array of canonical types. Only the first array based formatter should be 
returned as the desired formatter

This patch seems to redefine what getting the element type of an array is which 
seems wrong to me. We just need to make the code that uses these APIs smarter.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D72133/new/

https://reviews.llvm.org/D72133



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

[Lldb-commits] [lldb] 317cbda - [lldb/Docs] Describe optional dependencies on build page.

[Jonas Devlieghere via lldb-commits]

Author: Jonas Devlieghere
Date: 2020-01-06T13:59:24-08:00
New Revision: 317cbdad4d1b9ea7ec703072aba34eeb62c9d3af

URL: 
https://github.com/llvm/llvm-project/commit/317cbdad4d1b9ea7ec703072aba34eeb62c9d3af
DIFF: 
https://github.com/llvm/llvm-project/commit/317cbdad4d1b9ea7ec703072aba34eeb62c9d3af.diff

LOG: [lldb/Docs] Describe optional dependencies on build page.

List the different CMake flags controlling the optional dependencies as
per the discussion on the mailing list:

http://lists.llvm.org/pipermail/lldb-dev/2020-January/015867.html

Added: 


Modified: 
lldb/docs/resources/build.rst

Removed: 




diff  --git a/lldb/docs/resources/build.rst b/lldb/docs/resources/build.rst
index f97b39564e91..ef290892b4fe 100644
--- a/lldb/docs/resources/build.rst
+++ b/lldb/docs/resources/build.rst
@@ -29,9 +29,40 @@ The following requirements are shared on all platforms.
 
 * `CMake `_
 * `Ninja `_ (strongly recommended)
+
+If you want to run the test suite, you'll need to build LLDB with Python
+scripting support.
+
 * `Python `_
 * `SWIG `_
 
+Optional Dependencies
+*
+
+Although the following dependencies are optional, they have a big impact on
+LLDB's functionality. It is strongly encouraged to build LLDB with these
+dependencies enabled.
+
+By default they are auto-detected: if CMake can find the dependency it will be
+used. It is possible to override this behavior by setting the corresponding
+CMake flag to ``On`` or ``Off`` to force the dependency to be enabled or
+disabled. When a dependency is set to ``On`` and can't be found it will cause a
+CMake configuration error.
+
++---+--+--+
+| Feature   | Description  | 
CMake Flag   |
++===+==+==+
+| Editline  | Generic line editing, history, Emacs and Vi bindings | 
``LLDB_ENABLE_LIBEDIT``  |
++---+--+--+
+| Curses| Text user interface  | 
``LLDB_ENABLE_CURSES``   |
++---+--+--+
+| LZMA  | Lossless data compression| 
``LLDB_ENABLE_LZMA`` |
++---+--+--+
+| Python| Python scripting | 
``LLDB_ENABLE_PYTHON``   |
++---+--+--+
+| Lua   | Lua scripting| 
``LLDB_ENABLE_LUA``  |
++---+--+--+
+
 Depending on your platform and package manager, one might run any of the
 commands below.
 
@@ -75,11 +106,6 @@ environment setup. This means you should run 
``vcvarsall.bat`` or open an
 appropriate Visual Studio Command Prompt corresponding to the version you wish
 to use.
 
-Linux
-*
-
-* `libedit `_
-
 macOS
 *
 



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

[Lldb-commits] [PATCH] D72133: Data formatters: Look through array element typedefs

[Greg Clayton via Phabricator via lldb-commits]

clayborg requested changes to this revision.
clayborg added inline comments.
This revision now requires changes to proceed.



Comment at: lldb/source/API/SBType.cpp:215-218
+  CompilerType canonical_type =
+  m_opaque_sp->GetCompilerType(true).GetCanonicalType();
+  return LLDB_RECORD_RESULT(
+  SBType(TypeImplSP(new TypeImpl(canonical_type.GetArrayElementType();

Why does getting the canonical type of an array type change the array element 
type? I would think it wouldn't matter but it obviously must?



Comment at: lldb/source/DataFormatters/FormatManager.cpp:245-261
+  uint64_t array_size;
+  if (compiler_type.IsArrayType(nullptr, _size, nullptr)) {
+CompilerType element_type = compiler_type.GetArrayElementType();
+if (element_type.IsTypedefType()) {
+  // Get the stripped element type and compute the stripped array type
+  // from it.
+  CompilerType deffed_array_type =

Wouldn't we want to add one for each typedef that has a formatter? Lets say we 
had:

```
typedef char MCHAR;
typedef MCHAR MMCHAR;

int main() {
  MMCHAR str[5] = "abcd";
  return 0;
}
```

if we had a special formatter for MCHAR that would maybe display MCHAR somehow 
special, would we be ok with always getting the standard C string formatter in 
this case? Seems like we should add one for each typedef that has a formatter 
and possibly also the base type?



Comment at: lldb/source/Symbol/ClangASTContext.cpp:3946
 
-CompilerType element_type =
-GetType(array_eletype->getCanonicalTypeUnqualified());
+CompilerType element_type = GetType(clang::QualType(array_eletype, 0));
 

If I ask an array type for its element type, I wouldn't expect all typedefs to 
be removed. This seems wrong, or it can become an option to this function as an 
extra param:

```
CompilerType
ClangASTContext::GetArrayElementType(lldb::opaque_compiler_type_t type, 
uint64_t *stride, bool get_canonical_element_type);
```


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D72133/new/

https://reviews.llvm.org/D72133



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

[Lldb-commits] [PATCH] D71575: [LLDB] Add ObjectFileWasm plugin for WebAssembly debugging

[Greg Clayton via Phabricator via lldb-commits]

clayborg added inline comments.



Comment at: lldb/source/Plugins/ObjectFile/wasm/ObjectFileWasm.cpp:34
+/// Checks whether the data buffer starts with a valid Wasm module header.
+static bool ValidateModuleHeader(const DataBufferSP _sp) {
+  if (!data_sp || data_sp->GetByteSize() < kWasmHeaderSize)

I typically would put "data_sp" into a DataExtractor and extract a uint32_t and 
then check the decoded value with something like:

```
static bool ValidateModuleHeader(DataExtractor , uint64_t *offset_ptr) {
  auto magic = data.GetU32(offset_ptr);
  if (magic == WASM_MAGIC)
return true;
  if (magic == WASM_CIGAM) {
// Set byte order in DataExtractor
data.SetByteOrder(data.GetByteOrder() == eByteOrderBig ? eByteOrderLittle : 
eByteOrderBig);
return true;
  }
  return false;
}
```

This function expects a DataExtractor to be passed in that has "data_sp" inside 
of it with the host endian set as the byte order. It will set the byte order 
correctly. It also expects to have two uint32_t macros defined: WASM_MAGIC and 
WASM_CIGAM. These contain the non byte swapped and the byte swapped magic 
values. Easy to replace those with real definitions from else where 
(llvm::file_magic::wasm_object? Not sure of the type of this though, seemed 
like a StringRef).



Comment at: lldb/source/Plugins/ObjectFile/wasm/ObjectFileWasm.cpp:44
+
+  uint32_t version = llvm::support::endian::read32le(Ptr);
+  return version == llvm::wasm::WasmVersion;

use DataExtractor::GetU32()? Or is the byte order always little endian for wasm 
object files?



Comment at: lldb/source/Plugins/ObjectFile/wasm/ObjectFileWasm.cpp:187-195
+const uint8_t *name_bytes = section_header_data.PeekData(offset, 
*name_len);
+// If a custom section has a name longer than the allocated buffer or 
longer
+// than the data left in the image, ignore this section.
+if (!name_bytes)
+  return false;
+
+llvm::StringRef sect_name(reinterpret_cast(name_bytes),

All these lines can use the GetCStr with a length:
```
ConstString sect_name(data.GetCStr(, *name_len));
if (!sect_name)
  return false;
```



Comment at: lldb/source/Plugins/ObjectFile/wasm/ObjectFileWasm.cpp:199
+m_sect_infos.push_back(section_info{*offset_ptr + offset, section_length,
+*section_id, ConstString(sect_name)});
+offset += section_length;

remove ConstString constructor here if we switch code above as suggested.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D71575/new/

https://reviews.llvm.org/D71575



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

[Lldb-commits] [PATCH] D68679: [CMake] Add a cache for iOS.

[Davide Italiano via Phabricator via lldb-commits]

davide abandoned this revision.
davide added a comment.

We don't need this.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D68679/new/

https://reviews.llvm.org/D68679



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

[Lldb-commits] [PATCH] D71575: [LLDB] Add ObjectFileWasm plugin for WebAssembly debugging

[Greg Clayton via Phabricator via lldb-commits]

clayborg added a comment.

I would suggest removing GetVaruint7 and GetVaruint32 and adding 
"llvm::Optional DataExtractor::GetULEB128(uint64_t *offset_ptr, 
uint64_t max_value);" as mentioned in inlined comments.




Comment at: lldb/source/Plugins/ObjectFile/wasm/ObjectFileWasm.cpp:49
+  lldb::offset_t initial_offset = *offset_ptr;
+  uint64_t value = section_header_data.GetULEB128(offset_ptr);
+  if (*offset_ptr == initial_offset || value > 127)

Is it ok if we consume more than 1 byte here?  What is the offset points to a 
larger ULEB, are we ok with advancing the offset by multiple bytes or should we 
back it up and return llvm::None?

This might be a good candidate to add to DataExtractor directly as:

```
/// Extract a ULEB128 number with a specified max value. If the extracted value 
exceeds 
/// "max_value" the offset will be left unchanged and llvm::None will be 
returned.
llvm::Optional DataExtractor::GetULEB128(uint64_t *offset_ptr, 
uint64_t max_value);
```

There are many places where we extract a uint64_t, but only need a uint16_t 
(like in the DWARF parser where all DW_TAG_, DW_AT_XXX and DW_FORM_XXX 
values must only be uint16_t values but are encoded as ULEB128 values. So this 
could be used elsewhere if we do put it into DataExtractor.



Comment at: lldb/source/Plugins/ObjectFile/wasm/ObjectFileWasm.cpp:162-163
+  // - the actual contents.
+  llvm::Optional section_id =
+  GetVaruint7(section_header_data, );
+  if (!section_id)

Is this a one byte section ID or is it a ULEB? Not sure why it would be encoded 
as a ULEB if it is always one byte? IF this really is just a one byte value, 
then replace with:

```
uint8_t section_id = data.GetU8();
```



Comment at: lldb/source/Plugins/ObjectFile/wasm/ObjectFileWasm.cpp:59
+/// Reads a LEB128 variable-length unsigned integer, limited to 32 bits.
+static llvm::Optional GetVaruint32(DataExtractor 
_header_data,
+ lldb::offset_t *offset_ptr) {

remove if we add:
```
llvm::Optional DataExtractor::GetULEB128(uint64_t *offset_ptr, 
uint64_t max_value);
```


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D71575/new/

https://reviews.llvm.org/D71575



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

[Lldb-commits] [PATCH] D71825: [lldb/Lua] Support loading Lua modules.

[Greg Clayton via Phabricator via lldb-commits]

clayborg added a comment.

lgtm. Pavel?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D71825/new/

https://reviews.llvm.org/D71825



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

[Lldb-commits] [PATCH] D72286: installation: Accept separate install prefix for LLDB.framework

[Vedant Kumar via Phabricator via lldb-commits]

vsk abandoned this revision.
vsk added a comment.

This is still not right. build-script does not include the arch-specific 
destdir in the install prefix to begin with.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D72286/new/

https://reviews.llvm.org/D72286



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

[Lldb-commits] [PATCH] D71379: lldbutil: Forward ASan launch info to test inferiors

[Davide Italiano via Phabricator via lldb-commits]

davide accepted this revision.
davide added a comment.

This looks good to me.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D71379/new/

https://reviews.llvm.org/D71379



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

Re: [Lldb-commits] Optional Dependencies in LLDB

[Jonas Devlieghere via lldb-commits]

(This was meant for lldb-dev)

On Mon, Jan 6, 2020 at 11:15 AM Jonas Devlieghere  wrote:
>
> Hey everyone,
>
> I just wanted to let you know that most of the work is complete for
> auto-detecting optional dependencies in LLDB. Unless explicitly
> specified, optional dependencies like editline will be enabled when
> available and disabled otherwise. This is different from  the old
> behavior, where optional dependencies were that were enabled by
> default would cause an error at configuration time. The motivation is
> to make it easier to build LLDB by making things "just work" out of
> the box.
>
> All optional dependencies are now controlled by an LLDB_ENABLE_* CMake
> flag. The default value for these variables is "Auto", which causes
> the dependency to be enabled based on whether it was found. It's still
> possible to obtain the old behavior by setting the corresponding CMake
> variable to "On" or "Off" respectively.
>
> If you have a configuration where you were depending on the old
> behavior where the dependency being enabled or disabled by default,
> you might want to consider passing LLDB_ENABLE_*=On/Off to CMake to
> ensure the dependency is required or ignored respectively.
>
> TL;DR Optional dependencies in LLDB are controlled by LLDB_ENABLE_*
> CMake flags and are auto-detected by default. You can return to the
> old behavior by setting the variables to "On" or "Off" respectively.
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] Optional Dependencies in LLDB

[Jonas Devlieghere via lldb-commits]

Hey everyone,

I just wanted to let you know that most of the work is complete for
auto-detecting optional dependencies in LLDB. Unless explicitly
specified, optional dependencies like editline will be enabled when
available and disabled otherwise. This is different from  the old
behavior, where optional dependencies were that were enabled by
default would cause an error at configuration time. The motivation is
to make it easier to build LLDB by making things "just work" out of
the box.

All optional dependencies are now controlled by an LLDB_ENABLE_* CMake
flag. The default value for these variables is "Auto", which causes
the dependency to be enabled based on whether it was found. It's still
possible to obtain the old behavior by setting the corresponding CMake
variable to "On" or "Off" respectively.

If you have a configuration where you were depending on the old
behavior where the dependency being enabled or disabled by default,
you might want to consider passing LLDB_ENABLE_*=On/Off to CMake to
ensure the dependency is required or ignored respectively.

TL;DR Optional dependencies in LLDB are controlled by LLDB_ENABLE_*
CMake flags and are auto-detected by default. You can return to the
old behavior by setting the variables to "On" or "Off" respectively.
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D71825: [lldb/Lua] Support loading Lua modules.

[Jonas Devlieghere via Phabricator via lldb-commits]

JDevlieghere added a comment.

friendly ping


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D71825/new/

https://reviews.llvm.org/D71825



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

[Lldb-commits] [PATCH] D71905: [lldb][tests] Take into account all parent's categories when traverse folders upwards

[Jonas Devlieghere via Phabricator via lldb-commits]

JDevlieghere added inline comments.



Comment at: packages/Python/lldbsuite/test/test_result.py:119
+categories = set()
 while folder != '/':
 categories_file_name = os.path.join(folder, ".categories")

labath wrote:
> I don't think this will work on windows. I think we should stop iterating 
> here as soon we reach the top level test folder (I don't know how to check 
> that off-hand, but we should have that piece of information available 
> somewhere.) That will also ensure we don't get confused by some spurious 
> .categories file outside of the test tree.
We could use the LLDB source root for this, which is already available from 
dotest through `lldbsuite.lldb_root`.


Repository:
  rLLDB LLDB

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D71905/new/

https://reviews.llvm.org/D71905



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

Re: [Lldb-commits] [lldb] b3757f3 - [lldb/CMake] Autodetect Python dependency

[Jonas Devlieghere via lldb-commits]

Should be fixed by 8c8ffd461d16681cb1fc764bedfa8b09fde260aa

On Mon, Jan 6, 2020 at 10:17 AM Davidino Italiano  wrote:
>
>
>
> > On Jan 6, 2020, at 9:07 AM, Jonas Devlieghere via lldb-commits 
> >  wrote:
> >
> >
> > Author: Jonas Devlieghere
> > Date: 2020-01-06T09:05:05-08:00
> > New Revision: b3757f3091d1c718a91f5b06b7364b2af28339fa
> >
> > URL: 
> > https://github.com/llvm/llvm-project/commit/b3757f3091d1c718a91f5b06b7364b2af28339fa
> > DIFF: 
> > https://github.com/llvm/llvm-project/commit/b3757f3091d1c718a91f5b06b7364b2af28339fa.diff
> >
> > LOG: [lldb/CMake] Autodetect Python dependency
> >
> > Python was the last remaining "optional" dependency for LLDB. This moves
> > the code to find Python into FindPythonInterpAndLibs using the same
> > principles as FindCursesAndPanel.
> >
> > Differential revision: https://reviews.llvm.org/D72107
> >
> > Added:
> >lldb/cmake/modules/FindPythonInterpAndLibs.cmake
> >lldb/lldb/cmake/modules/FindPythonInterpAndLibs.cmake
> >
> > Modified:
> >lldb/cmake/modules/LLDBConfig.cmake
> >
> > Removed:
> >
> >
> >
> > 
> > diff  --git a/lldb/cmake/modules/FindPythonInterpAndLibs.cmake 
> > b/lldb/cmake/modules/FindPythonInterpAndLibs.cmake
> > new file mode 100644
> > index ..fcbf0212d72b
> > --- /dev/null
> > +++ b/lldb/cmake/modules/FindPythonInterpAndLibs.cmake
> > @@ -0,0 +1,51 @@
> > +#.rst:
> > +# FindPythonInterpAndLibs
> > +# ---
> > +#
> > +# Find the python interpreter and libraries as a whole.
> > +
> > +if(PYTHON_LIBRARIES AND PYTHON_INCLUDE_DIRS AND PYTHON_EXECUTABLE)
> > +  set(PYTHONINTERPANDLIBS_FOUND TRUE)
> > +else()
> > +  if ("${CMAKE_SYSTEM_NAME}" STREQUAL "Windows")
> > +find_package(Python3 COMPONENTS Interpreter Development QUIET)
> > +if (Python3_FOUND AND Python3_Interpreter_FOUND)
> > +  set(PYTHON_LIBRARIES ${Python3_LIBRARIES})
> > +  set(PYTHON_INCLUDE_DIRS ${Python3_INCLUDE_DIRS})
> > +  set(PYTHON_EXECUTABLE ${Python3_EXECUTABLE})
> > +  mark_as_advanced(
> > +PYTHON_LIBRARIES
> > +PYTHON_INCLUDE_DIRS
> > +PYTHON_EXECUTABLE)
> > +endif()
> > +  else()
> > +find_package(PythonInterp QUIET)
> > +find_package(PythonLibs QUIET)
> > +if(PYTHONINTERP_FOUND AND PYTHONLIBS_FOUND)
> > +  if (NOT CMAKE_CROSSCOMPILING)
> > +string(REPLACE "." ";" pythonlibs_version_list 
> > ${PYTHONLIBS_VERSION_STRING})
> > +list(GET pythonlibs_version_list 0 pythonlibs_major)
> > +list(GET pythonlibs_version_list 1 pythonlibs_minor)
> > +
> > +# Ignore the patch version. Some versions of macOS report a
> > diff erent
> > +# patch version for the system provided interpreter and libraries.
> > +if (CMAKE_CROSSCOMPILING OR (PYTHON_VERSION_MAJOR VERSION_EQUAL 
> > pythonlibs_major AND
> > +PYTHON_VERSION_MINOR VERSION_EQUAL pythonlibs_minor))
> > +  mark_as_advanced(
> > +PYTHON_LIBRARIES
> > +PYTHON_INCLUDE_DIRS
> > +PYTHON_EXECUTABLE)
> > +endif()
> > +  endif()
> > +endif()
> > +  endif()
> > +
> > +  include(FindPackageHandleStandardArgs)
> > +  find_package_handle_standard_args(PythonInterpAndLibs
> > +FOUND_VAR
> > +  PYTHONINTERPANDLIBS_FOUND
> > +REQUIRED_VARS
> > +  PYTHON_LIBRARIES
> > +  PYTHON_INCLUDE_DIRS
> > +  PYTHON_EXECUTABLE)
> > +endif()
> >
> > diff  --git a/lldb/cmake/modules/LLDBConfig.cmake 
> > b/lldb/cmake/modules/LLDBConfig.cmake
> > index 52b8257951be..12fb97fc9d7d 100644
> > --- a/lldb/cmake/modules/LLDBConfig.cmake
> > +++ b/lldb/cmake/modules/LLDBConfig.cmake
> > @@ -51,16 +51,8 @@ add_optional_dependency(LLDB_ENABLE_LIBEDIT "Enable 
> > editline support in LLDB" Li
> > add_optional_dependency(LLDB_ENABLE_CURSES "Enable curses support in LLDB" 
> > CursesAndPanel CURSESANDPANEL_FOUND)
> > add_optional_dependency(LLDB_ENABLE_LZMA "Enable LZMA compression support 
> > in LLDB" LibLZMA LIBLZMA_FOUND)
> > add_optional_dependency(LLDB_ENABLE_LUA "Enable Lua scripting support in 
> > LLDB" Lua LUA_FOUND)
> > +add_optional_dependency(LLDB_ENABLE_PYTHON "Enable Python scripting 
> > support in LLDB" PythonInterpAndLibs PYTHONINTERPANDLIBS_FOUND)
> >
> > -set(default_enable_python ON)
> > -
> > -if(CMAKE_SYSTEM_NAME MATCHES "Android")
> > -  set(default_enable_python OFF)
> > -elseif(IOS)
> > -  set(default_enable_python OFF)
> > -endif()
> > -
> > -option(LLDB_ENABLE_PYTHON "Enable Python scripting integration." 
> > ${default_enable_python})
> > option(LLDB_RELOCATABLE_PYTHON "Use the PYTHONHOME environment variable to 
> > locate Python." OFF)
> > option(LLDB_USE_SYSTEM_SIX "Use six.py shipped with system and do not 
> > install a copy of 

Re: [Lldb-commits] [lldb] b3757f3 - [lldb/CMake] Autodetect Python dependency

[Davidino Italiano via lldb-commits]

> On Jan 6, 2020, at 9:07 AM, Jonas Devlieghere via lldb-commits 
>  wrote:
> 
> 
> Author: Jonas Devlieghere
> Date: 2020-01-06T09:05:05-08:00
> New Revision: b3757f3091d1c718a91f5b06b7364b2af28339fa
> 
> URL: 
> https://github.com/llvm/llvm-project/commit/b3757f3091d1c718a91f5b06b7364b2af28339fa
> DIFF: 
> https://github.com/llvm/llvm-project/commit/b3757f3091d1c718a91f5b06b7364b2af28339fa.diff
> 
> LOG: [lldb/CMake] Autodetect Python dependency
> 
> Python was the last remaining "optional" dependency for LLDB. This moves
> the code to find Python into FindPythonInterpAndLibs using the same
> principles as FindCursesAndPanel.
> 
> Differential revision: https://reviews.llvm.org/D72107
> 
> Added: 
>lldb/cmake/modules/FindPythonInterpAndLibs.cmake
>lldb/lldb/cmake/modules/FindPythonInterpAndLibs.cmake
> 
> Modified: 
>lldb/cmake/modules/LLDBConfig.cmake
> 
> Removed: 
> 
> 
> 
> 
> diff  --git a/lldb/cmake/modules/FindPythonInterpAndLibs.cmake 
> b/lldb/cmake/modules/FindPythonInterpAndLibs.cmake
> new file mode 100644
> index ..fcbf0212d72b
> --- /dev/null
> +++ b/lldb/cmake/modules/FindPythonInterpAndLibs.cmake
> @@ -0,0 +1,51 @@
> +#.rst:
> +# FindPythonInterpAndLibs
> +# ---
> +#
> +# Find the python interpreter and libraries as a whole.
> +
> +if(PYTHON_LIBRARIES AND PYTHON_INCLUDE_DIRS AND PYTHON_EXECUTABLE)
> +  set(PYTHONINTERPANDLIBS_FOUND TRUE)
> +else()
> +  if ("${CMAKE_SYSTEM_NAME}" STREQUAL "Windows")
> +find_package(Python3 COMPONENTS Interpreter Development QUIET)
> +if (Python3_FOUND AND Python3_Interpreter_FOUND)
> +  set(PYTHON_LIBRARIES ${Python3_LIBRARIES})
> +  set(PYTHON_INCLUDE_DIRS ${Python3_INCLUDE_DIRS})
> +  set(PYTHON_EXECUTABLE ${Python3_EXECUTABLE})
> +  mark_as_advanced(
> +PYTHON_LIBRARIES
> +PYTHON_INCLUDE_DIRS
> +PYTHON_EXECUTABLE)
> +endif()
> +  else()
> +find_package(PythonInterp QUIET)
> +find_package(PythonLibs QUIET)
> +if(PYTHONINTERP_FOUND AND PYTHONLIBS_FOUND)
> +  if (NOT CMAKE_CROSSCOMPILING)
> +string(REPLACE "." ";" pythonlibs_version_list 
> ${PYTHONLIBS_VERSION_STRING})
> +list(GET pythonlibs_version_list 0 pythonlibs_major)
> +list(GET pythonlibs_version_list 1 pythonlibs_minor)
> +
> +# Ignore the patch version. Some versions of macOS report a 
> diff erent
> +# patch version for the system provided interpreter and libraries.
> +if (CMAKE_CROSSCOMPILING OR (PYTHON_VERSION_MAJOR VERSION_EQUAL 
> pythonlibs_major AND
> +PYTHON_VERSION_MINOR VERSION_EQUAL pythonlibs_minor))
> +  mark_as_advanced(
> +PYTHON_LIBRARIES
> +PYTHON_INCLUDE_DIRS
> +PYTHON_EXECUTABLE)
> +endif()
> +  endif()
> +endif()
> +  endif()
> +
> +  include(FindPackageHandleStandardArgs)
> +  find_package_handle_standard_args(PythonInterpAndLibs
> +FOUND_VAR
> +  PYTHONINTERPANDLIBS_FOUND
> +REQUIRED_VARS
> +  PYTHON_LIBRARIES
> +  PYTHON_INCLUDE_DIRS
> +  PYTHON_EXECUTABLE)
> +endif()
> 
> diff  --git a/lldb/cmake/modules/LLDBConfig.cmake 
> b/lldb/cmake/modules/LLDBConfig.cmake
> index 52b8257951be..12fb97fc9d7d 100644
> --- a/lldb/cmake/modules/LLDBConfig.cmake
> +++ b/lldb/cmake/modules/LLDBConfig.cmake
> @@ -51,16 +51,8 @@ add_optional_dependency(LLDB_ENABLE_LIBEDIT "Enable 
> editline support in LLDB" Li
> add_optional_dependency(LLDB_ENABLE_CURSES "Enable curses support in LLDB" 
> CursesAndPanel CURSESANDPANEL_FOUND)
> add_optional_dependency(LLDB_ENABLE_LZMA "Enable LZMA compression support in 
> LLDB" LibLZMA LIBLZMA_FOUND)
> add_optional_dependency(LLDB_ENABLE_LUA "Enable Lua scripting support in 
> LLDB" Lua LUA_FOUND)
> +add_optional_dependency(LLDB_ENABLE_PYTHON "Enable Python scripting support 
> in LLDB" PythonInterpAndLibs PYTHONINTERPANDLIBS_FOUND)
> 
> -set(default_enable_python ON)
> -
> -if(CMAKE_SYSTEM_NAME MATCHES "Android")
> -  set(default_enable_python OFF)
> -elseif(IOS)
> -  set(default_enable_python OFF)
> -endif()
> -
> -option(LLDB_ENABLE_PYTHON "Enable Python scripting integration." 
> ${default_enable_python})
> option(LLDB_RELOCATABLE_PYTHON "Use the PYTHONHOME environment variable to 
> locate Python." OFF)
> option(LLDB_USE_SYSTEM_SIX "Use six.py shipped with system and do not install 
> a copy of it" OFF)
> option(LLDB_USE_ENTITLEMENTS "When codesigning, use entitlements if 
> available" ON)
> @@ -142,48 +134,13 @@ if (LLDB_ENABLE_LIBEDIT)
> endif()
> 
> if (LLDB_ENABLE_PYTHON)
> -  if ("${CMAKE_SYSTEM_NAME}" STREQUAL "Windows")
> -find_package(Python3 COMPONENTS Interpreter Development REQUIRED)
> -if(Python3_VERSION VERSION_LESS 3.5)
> 

[Lldb-commits] [PATCH] D71906: [lldb][tests] Make it possible to expect failure for a whole category

[Jonas Devlieghere via Phabricator via lldb-commits]

JDevlieghere accepted this revision.
JDevlieghere added a comment.
This revision is now accepted and ready to land.

Thanks!


Repository:
  rLLDB LLDB

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D71906/new/

https://reviews.llvm.org/D71906



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

[Lldb-commits] [PATCH] D72290: [lldb/CMake] Use LLDB's autodetection logic for libxml2

[Jonas Devlieghere via Phabricator via lldb-commits]

JDevlieghere created this revision.
JDevlieghere added reviewers: LLDB, labath, compnerd.
Herald added a subscriber: mgorny.
Herald added a project: LLDB.

Libxml2 is already an optional dependency. It should use the same 
infrastructure as the other dependencies.


Repository:
  rLLDB LLDB

https://reviews.llvm.org/D72290

Files:
  lldb/cmake/modules/FindLibXml28.cmake
  lldb/cmake/modules/LLDBConfig.cmake


Index: lldb/cmake/modules/LLDBConfig.cmake
===
--- lldb/cmake/modules/LLDBConfig.cmake
+++ lldb/cmake/modules/LLDBConfig.cmake
@@ -52,6 +52,7 @@
 add_optional_dependency(LLDB_ENABLE_LZMA "Enable LZMA compression support in 
LLDB" LibLZMA LIBLZMA_FOUND)
 add_optional_dependency(LLDB_ENABLE_LUA "Enable Lua scripting support in LLDB" 
Lua LUA_FOUND)
 add_optional_dependency(LLDB_ENABLE_PYTHON "Enable Python scripting support in 
LLDB" PythonInterpAndLibs PYTHONINTERPANDLIBS_FOUND)
+add_optional_dependency(LLDB_ENABLE_LIBXML2 "Enable Libxml 2 support in LLDB" 
LibXml28 LIBXML28_FOUND)
 
 option(LLDB_RELOCATABLE_PYTHON "Use the PYTHONHOME environment variable to 
locate Python." OFF)
 option(LLDB_USE_SYSTEM_SIX "Use six.py shipped with system and do not install 
a copy of it" OFF)
@@ -218,6 +219,11 @@
   include_directories(${LIBLZMA_INCLUDE_DIRS})
 endif()
 
+if (LLDB_ENABLE_LIBXML2)
+  list(APPEND system_libs ${LIBXML2_LIBRARIES})
+  include_directories(${LIBXML2_INCLUDE_DIR})
+endif()
+
 include_directories(BEFORE
   ${CMAKE_CURRENT_BINARY_DIR}/include
   ${CMAKE_CURRENT_SOURCE_DIR}/include
@@ -251,11 +257,7 @@
   endif()
 endif()
 
-if (NOT LIBXML2_FOUND)
-  find_package(LibXml2)
-endif()
-
-# Find libraries or frameworks that may be needed
+# Find Apple-specific libraries or frameworks that may be needed.
 if (APPLE)
   if(NOT IOS)
 find_library(CARBON_LIBRARY Carbon)
@@ -264,18 +266,13 @@
   find_library(FOUNDATION_LIBRARY Foundation)
   find_library(CORE_FOUNDATION_LIBRARY CoreFoundation)
   find_library(SECURITY_LIBRARY Security)
-  set(LLDB_ENABLE_LIBXML2 ON)
-  list(APPEND system_libs xml2
+  list(APPEND system_libs
${FOUNDATION_LIBRARY}
${CORE_FOUNDATION_LIBRARY}
${CORE_SERVICES_LIBRARY}
${SECURITY_LIBRARY}
${DEBUG_SYMBOLS_LIBRARY})
   include_directories(${LIBXML2_INCLUDE_DIR})
-elseif(LIBXML2_FOUND AND LIBXML2_VERSION_STRING VERSION_GREATER 2.8)
-  set(LLDB_ENABLE_LIBXML2 ON)
-  list(APPEND system_libs ${LIBXML2_LIBRARIES})
-  include_directories(${LIBXML2_INCLUDE_DIR})
 endif()
 
 if( WIN32 AND NOT CYGWIN )
Index: lldb/cmake/modules/FindLibXml28.cmake
===
--- /dev/null
+++ lldb/cmake/modules/FindLibXml28.cmake
@@ -0,0 +1,27 @@
+#.rst:
+# FindLibXml28
+# ---
+#
+# Find a recent version (>2.8) of Libxml2.
+
+if(LIBXML2_LIBRARIES AND LIBXML2_INCLUDE_DIR)
+  set(LIBXML28_FOUND TRUE)
+else()
+  find_package(LibXml2 QUIET)
+
+  if(LIBXML2_FOUND AND LIBXML2_VERSION_STRING VERSION_GREATER 2.8)
+if (APPLE)
+  set(LIBXML2_LIBRARIES xml2)
+endif()
+mark_as_advanced(LIBXML2_LIBRARIES LIBXML2_INCLUDE_DIR)
+  endif()
+
+  include(FindPackageHandleStandardArgs)
+  find_package_handle_standard_args(LibXml28
+FOUND_VAR
+  LIBXML28_FOUND
+REQUIRED_VARS
+  LIBXML2_LIBRARIES
+  LIBXML2_INCLUDE_DIR)
+endif()
+


Index: lldb/cmake/modules/LLDBConfig.cmake
===
--- lldb/cmake/modules/LLDBConfig.cmake
+++ lldb/cmake/modules/LLDBConfig.cmake
@@ -52,6 +52,7 @@
 add_optional_dependency(LLDB_ENABLE_LZMA "Enable LZMA compression support in LLDB" LibLZMA LIBLZMA_FOUND)
 add_optional_dependency(LLDB_ENABLE_LUA "Enable Lua scripting support in LLDB" Lua LUA_FOUND)
 add_optional_dependency(LLDB_ENABLE_PYTHON "Enable Python scripting support in LLDB" PythonInterpAndLibs PYTHONINTERPANDLIBS_FOUND)
+add_optional_dependency(LLDB_ENABLE_LIBXML2 "Enable Libxml 2 support in LLDB" LibXml28 LIBXML28_FOUND)
 
 option(LLDB_RELOCATABLE_PYTHON "Use the PYTHONHOME environment variable to locate Python." OFF)
 option(LLDB_USE_SYSTEM_SIX "Use six.py shipped with system and do not install a copy of it" OFF)
@@ -218,6 +219,11 @@
   include_directories(${LIBLZMA_INCLUDE_DIRS})
 endif()
 
+if (LLDB_ENABLE_LIBXML2)
+  list(APPEND system_libs ${LIBXML2_LIBRARIES})
+  include_directories(${LIBXML2_INCLUDE_DIR})
+endif()
+
 include_directories(BEFORE
   ${CMAKE_CURRENT_BINARY_DIR}/include
   ${CMAKE_CURRENT_SOURCE_DIR}/include
@@ -251,11 +257,7 @@
   endif()
 endif()
 
-if (NOT LIBXML2_FOUND)
-  find_package(LibXml2)
-endif()
-
-# Find libraries or frameworks that may be needed
+# Find Apple-specific libraries or frameworks that may be needed.
 if (APPLE)
   if(NOT IOS)
 find_library(CARBON_LIBRARY Carbon)
@@ 

[Lldb-commits] [lldb] 0239526 - [lldb/Docs] Fix capitalization typo.

[Jonas Devlieghere via lldb-commits]

Author: Jonas Devlieghere
Date: 2020-01-06T10:08:05-08:00
New Revision: 0239526cccf8aa708e29eeb7e49de8f6dc6c1a5f

URL: 
https://github.com/llvm/llvm-project/commit/0239526cccf8aa708e29eeb7e49de8f6dc6c1a5f
DIFF: 
https://github.com/llvm/llvm-project/commit/0239526cccf8aa708e29eeb7e49de8f6dc6c1a5f.diff

LOG: [lldb/Docs] Fix capitalization typo.

This has been bothering me for way too long.

Added: 


Modified: 
lldb/docs/resources/build.rst

Removed: 




diff  --git a/lldb/docs/resources/build.rst b/lldb/docs/resources/build.rst
index efa94de42a9d..f97b39564e91 100644
--- a/lldb/docs/resources/build.rst
+++ b/lldb/docs/resources/build.rst
@@ -341,7 +341,7 @@ Build LLDB standalone for development with Xcode:
`_
 
 
-Building The Documentation
+Building the Documentation
 --
 
 If you wish to build the optional (reference) documentation, additional



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

[Lldb-commits] [PATCH] D72286: installation: Accept separate install prefix for LLDB.framework

[Vedant Kumar via Phabricator via lldb-commits]

vsk updated this revision to Diff 236402.
vsk added a comment.

It looks like a framework-specific install prefix is required, as the install 
prefix for the framework is not always the same as the install prefix for the 
rest of the project.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D72286/new/

https://reviews.llvm.org/D72286

Files:
  lldb/CMakeLists.txt
  lldb/cmake/modules/AddLLDB.cmake
  lldb/cmake/modules/LLDBConfig.cmake
  lldb/cmake/modules/LLDBFramework.cmake
  lldb/source/API/CMakeLists.txt


Index: lldb/source/API/CMakeLists.txt
===
--- lldb/source/API/CMakeLists.txt
+++ lldb/source/API/CMakeLists.txt
@@ -15,7 +15,7 @@
 endif()
 
 if(LLDB_BUILD_FRAMEWORK)
-  set(option_install_prefix INSTALL_PREFIX ${LLDB_FRAMEWORK_INSTALL_DIR})
+  set(option_install_prefix INSTALL_PREFIX ${LLDB_FRAMEWORK_INSTALL_PATH})
   set(option_framework FRAMEWORK)
 endif()
 
Index: lldb/cmake/modules/LLDBFramework.cmake
===
--- lldb/cmake/modules/LLDBFramework.cmake
+++ lldb/cmake/modules/LLDBFramework.cmake
@@ -1,5 +1,5 @@
 message(STATUS "LLDB.framework: build path is 
'${LLDB_FRAMEWORK_ABSOLUTE_BUILD_DIR}'")
-message(STATUS "LLDB.framework: install path is 
'${LLDB_FRAMEWORK_INSTALL_DIR}'")
+message(STATUS "LLDB.framework: install path is 
'${LLDB_FRAMEWORK_INSTALL_PATH}'")
 message(STATUS "LLDB.framework: resources subdirectory is 
'Versions/${LLDB_FRAMEWORK_VERSION}/Resources'")
 
 # Configure liblldb as a framework bundle
@@ -27,7 +27,7 @@
   LIBRARY_DIR ${LLDB_FRAMEWORK_ABSOLUTE_BUILD_DIR}
 )
 
-lldb_add_post_install_steps_darwin(liblldb ${LLDB_FRAMEWORK_INSTALL_DIR})
+lldb_add_post_install_steps_darwin(liblldb ${LLDB_FRAMEWORK_INSTALL_PATH})
 
 # Affects the layout of the framework bundle (default is macOS layout).
 if(IOS)
Index: lldb/cmake/modules/LLDBConfig.cmake
===
--- lldb/cmake/modules/LLDBConfig.cmake
+++ lldb/cmake/modules/LLDBConfig.cmake
@@ -90,7 +90,9 @@
 
   set(LLDB_FRAMEWORK_VERSION A CACHE STRING "LLDB.framework version (default 
is A)")
   set(LLDB_FRAMEWORK_BUILD_DIR bin CACHE STRING "Output directory for 
LLDB.framework")
+  set(LLDB_FRAMEWORK_INSTALL_PREFIX "" CACHE STRING "Prefix for the 
LLDB.framework install directory")
   set(LLDB_FRAMEWORK_INSTALL_DIR Library/Frameworks CACHE STRING "Install 
directory for LLDB.framework")
+  set(LLDB_FRAMEWORK_INSTALL_PATH 
"${LLDB_FRAMEWORK_INSTALL_PREFIX}${LLDB_FRAMEWORK_INSTALL_DIR}")
 
   get_filename_component(LLDB_FRAMEWORK_ABSOLUTE_BUILD_DIR 
${LLDB_FRAMEWORK_BUILD_DIR} ABSOLUTE
 BASE_DIR ${CMAKE_BINARY_DIR}/${CMAKE_CFG_INTDIR})
Index: lldb/cmake/modules/AddLLDB.cmake
===
--- lldb/cmake/modules/AddLLDB.cmake
+++ lldb/cmake/modules/AddLLDB.cmake
@@ -218,7 +218,7 @@
 set(subdir LLDB.framework/Versions/${LLDB_FRAMEWORK_VERSION}/Resources)
 add_lldb_executable(${name}
   GENERATE_INSTALL
-  INSTALL_PREFIX ${LLDB_FRAMEWORK_INSTALL_DIR}/${subdir}
+  INSTALL_PREFIX ${LLDB_FRAMEWORK_INSTALL_PATH}/${subdir}
   ${ARG_UNPARSED_ARGUMENTS}
 )
 lldb_add_to_buildtree_lldb_framework(${name} ${subdir})
Index: lldb/CMakeLists.txt
===
--- lldb/CMakeLists.txt
+++ lldb/CMakeLists.txt
@@ -221,7 +221,7 @@
 
   # Install the LLDB python module
   if(LLDB_BUILD_FRAMEWORK)
-set(LLDB_PYTHON_INSTALL_PATH 
${LLDB_FRAMEWORK_INSTALL_DIR}/LLDB.framework/Resources/Python)
+set(LLDB_PYTHON_INSTALL_PATH 
${LLDB_FRAMEWORK_INSTALL_PATH}/LLDB.framework/Resources/Python)
   else()
 set(LLDB_PYTHON_INSTALL_PATH ${LLDB_PYTHON_RELATIVE_PATH})
   endif()


Index: lldb/source/API/CMakeLists.txt
===
--- lldb/source/API/CMakeLists.txt
+++ lldb/source/API/CMakeLists.txt
@@ -15,7 +15,7 @@
 endif()
 
 if(LLDB_BUILD_FRAMEWORK)
-  set(option_install_prefix INSTALL_PREFIX ${LLDB_FRAMEWORK_INSTALL_DIR})
+  set(option_install_prefix INSTALL_PREFIX ${LLDB_FRAMEWORK_INSTALL_PATH})
   set(option_framework FRAMEWORK)
 endif()
 
Index: lldb/cmake/modules/LLDBFramework.cmake
===
--- lldb/cmake/modules/LLDBFramework.cmake
+++ lldb/cmake/modules/LLDBFramework.cmake
@@ -1,5 +1,5 @@
 message(STATUS "LLDB.framework: build path is '${LLDB_FRAMEWORK_ABSOLUTE_BUILD_DIR}'")
-message(STATUS "LLDB.framework: install path is '${LLDB_FRAMEWORK_INSTALL_DIR}'")
+message(STATUS "LLDB.framework: install path is '${LLDB_FRAMEWORK_INSTALL_PATH}'")
 message(STATUS "LLDB.framework: resources subdirectory is 'Versions/${LLDB_FRAMEWORK_VERSION}/Resources'")
 
 # Configure liblldb as a framework bundle
@@ -27,7 +27,7 @@
   LIBRARY_DIR ${LLDB_FRAMEWORK_ABSOLUTE_BUILD_DIR}
 )
 
-lldb_add_post_install_steps_darwin(liblldb 

[Lldb-commits] [lldb] 8c8ffd4 - [lldb/CMake] Only set PYTHON_HOME on Windows

[Jonas Devlieghere via lldb-commits]

Author: Jonas Devlieghere
Date: 2020-01-06T10:07:46-08:00
New Revision: 8c8ffd461d16681cb1fc764bedfa8b09fde260aa

URL: 
https://github.com/llvm/llvm-project/commit/8c8ffd461d16681cb1fc764bedfa8b09fde260aa
DIFF: 
https://github.com/llvm/llvm-project/commit/8c8ffd461d16681cb1fc764bedfa8b09fde260aa.diff

LOG: [lldb/CMake] Only set PYTHON_HOME on Windows

My earlier change for Python auto-detection caused PYTHON_HOME to be set
unconditionally, while before the change this only happened for Windows.
This caused the PythonDataObjectsTest to fail with an import error.

Added: 


Modified: 
lldb/cmake/modules/LLDBConfig.cmake

Removed: 




diff  --git a/lldb/cmake/modules/LLDBConfig.cmake 
b/lldb/cmake/modules/LLDBConfig.cmake
index 12fb97fc9d7d..f318b5c8bd2a 100644
--- a/lldb/cmake/modules/LLDBConfig.cmake
+++ b/lldb/cmake/modules/LLDBConfig.cmake
@@ -135,7 +135,7 @@ endif()
 
 if (LLDB_ENABLE_PYTHON)
   include_directories(${PYTHON_INCLUDE_DIRS})
-  if (NOT LLDB_RELOCATABLE_PYTHON)
+  if ("${CMAKE_SYSTEM_NAME}" STREQUAL "Windows" AND NOT 
LLDB_RELOCATABLE_PYTHON)
 get_filename_component(PYTHON_HOME "${PYTHON_EXECUTABLE}" DIRECTORY)
 file(TO_CMAKE_PATH "${PYTHON_HOME}" LLDB_PYTHON_HOME)
   endif()



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

[Lldb-commits] [PATCH] D71379: lldbutil: Forward ASan launch info to test inferiors

[Jonas Devlieghere via Phabricator via lldb-commits]

JDevlieghere accepted this revision.
JDevlieghere added a comment.
This revision is now accepted and ready to land.

We already have something like this for the sanitized bot. I think this will 
cause the variable to bet set twice in the launch info twice? If not this LGTM.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D71379/new/

https://reviews.llvm.org/D71379



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

[Lldb-commits] [PATCH] D72190: Removing C-style casts in favor of explict C++ style casts

[Jonas Devlieghere via Phabricator via lldb-commits]

JDevlieghere added a comment.

In D72190#1805861 , @labath wrote:

> This is fine, though, since you're already touching these lines, I'd consider 
> converting them from LLDB_LOGF to LLDB_LOG at the same time (getting rid of 
> most of the static_casts...).


+1 :-)


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D72190/new/

https://reviews.llvm.org/D72190



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

[Lldb-commits] [PATCH] D71800: [CMake] Add $ORIGIN/../../../../lib to rpath if BUILD_SHARED_LIBS or LLVM_LINK_LLVM_DYLIB on *nix

[Fangrui Song via Phabricator via lldb-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGbbfebd7b8a67: [CMake] Add $ORIGIN/../../../../lib to rpath 
if BUILD_SHARED_LIBS or… (authored by MaskRay).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D71800/new/

https://reviews.llvm.org/D71800

Files:
  lldb/source/API/CMakeLists.txt


Index: lldb/source/API/CMakeLists.txt
===
--- lldb/source/API/CMakeLists.txt
+++ lldb/source/API/CMakeLists.txt
@@ -111,6 +111,14 @@
   ${option_install_prefix}
 )
 
+# lib/pythonX.Y/dist-packages/lldb/_lldb.so is a symlink to lib/liblldb.so,
+# which depends on lib/libLLVM*.so (BUILD_SHARED_LIBS) or lib/libLLVM-10git.so
+# (LLVM_LINK_LLVM_DYLIB). Add an additional rpath $ORIGIN/../../../../lib so
+# that _lldb.so can be loaded from Python.
+if(LLDB_ENABLE_PYTHON AND (BUILD_SHARED_LIBS OR LLVM_LINK_LLVM_DYLIB) AND UNIX 
AND NOT APPLE)
+  set_property(TARGET liblldb APPEND PROPERTY INSTALL_RPATH 
"\$ORIGIN/../../../../lib${LLVM_LIBDIR_SUFFIX}")
+endif()
+
 if (MSVC)
   set_source_files_properties(SBReproducer.cpp PROPERTIES COMPILE_FLAGS 
/bigobj)
 endif()


Index: lldb/source/API/CMakeLists.txt
===
--- lldb/source/API/CMakeLists.txt
+++ lldb/source/API/CMakeLists.txt
@@ -111,6 +111,14 @@
   ${option_install_prefix}
 )
 
+# lib/pythonX.Y/dist-packages/lldb/_lldb.so is a symlink to lib/liblldb.so,
+# which depends on lib/libLLVM*.so (BUILD_SHARED_LIBS) or lib/libLLVM-10git.so
+# (LLVM_LINK_LLVM_DYLIB). Add an additional rpath $ORIGIN/../../../../lib so
+# that _lldb.so can be loaded from Python.
+if(LLDB_ENABLE_PYTHON AND (BUILD_SHARED_LIBS OR LLVM_LINK_LLVM_DYLIB) AND UNIX AND NOT APPLE)
+  set_property(TARGET liblldb APPEND PROPERTY INSTALL_RPATH "\$ORIGIN/../../../../lib${LLVM_LIBDIR_SUFFIX}")
+endif()
+
 if (MSVC)
   set_source_files_properties(SBReproducer.cpp PROPERTIES COMPILE_FLAGS /bigobj)
 endif()
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] bbfebd7 - [CMake] Add $ORIGIN/../../../../lib to rpath if BUILD_SHARED_LIBS or LLVM_LINK_LLVM_DYLIB on *nix

[Fangrui Song via lldb-commits]

Author: Fangrui Song
Date: 2020-01-06T10:01:55-08:00
New Revision: bbfebd7b8a671c9649305b8a5f72e93dd1ef60e1

URL: 
https://github.com/llvm/llvm-project/commit/bbfebd7b8a671c9649305b8a5f72e93dd1ef60e1
DIFF: 
https://github.com/llvm/llvm-project/commit/bbfebd7b8a671c9649305b8a5f72e93dd1ef60e1.diff

LOG: [CMake] Add $ORIGIN/../../../../lib to rpath if BUILD_SHARED_LIBS or 
LLVM_LINK_LLVM_DYLIB on *nix

Summary:
lib/python2.7/dist-packages/lldb/_lldb.so is a symlink to lib/liblldb.so,
which depends on lib/libLLVM*.so (-DBUILD_SHARED_LIBS=ON) or 
lib/libLLVM-10git.so
(-DLLVM_LINK_LLVM_DYLIB=ON). Add an additional rpath `$ORIGIN/../../../../lib` 
so
that _lldb.so can be loaded from Python.

This fixes an import error from lib/python2.7/dist-packages/lldb/__init__.py

  from . import _lldb
  ImportError: libLLVMAArch64CodeGen.so.10git: cannot open shared object file: 
No such file or directory

 The following configurations will work:

* -DBUILD_SHARED_LIBS=ON
* -DBUILD_SHARED_LIBS=OFF -DLLVM_LINK_LLVM_DYLIB=ON
* -DBUILD_SHARED_LIBS=OFF -DLLVM_LINK_LLVM_DYLIB=ON -DCLANG_LINK_CLANG_DYLIB=ON
  (-DCLANG_LINK_CLANG_DYLIB=ON depends on -DLLVM_LINK_LLVM_DYLIB=ON)

Reviewed By: labath

Differential Revision: https://reviews.llvm.org/D71800

Added: 


Modified: 
lldb/source/API/CMakeLists.txt

Removed: 




diff  --git a/lldb/source/API/CMakeLists.txt b/lldb/source/API/CMakeLists.txt
index d036caf2f434..eea409bed185 100644
--- a/lldb/source/API/CMakeLists.txt
+++ b/lldb/source/API/CMakeLists.txt
@@ -111,6 +111,14 @@ add_lldb_library(liblldb SHARED ${option_framework}
   ${option_install_prefix}
 )
 
+# lib/pythonX.Y/dist-packages/lldb/_lldb.so is a symlink to lib/liblldb.so,
+# which depends on lib/libLLVM*.so (BUILD_SHARED_LIBS) or lib/libLLVM-10git.so
+# (LLVM_LINK_LLVM_DYLIB). Add an additional rpath $ORIGIN/../../../../lib so
+# that _lldb.so can be loaded from Python.
+if(LLDB_ENABLE_PYTHON AND (BUILD_SHARED_LIBS OR LLVM_LINK_LLVM_DYLIB) AND UNIX 
AND NOT APPLE)
+  set_property(TARGET liblldb APPEND PROPERTY INSTALL_RPATH 
"\$ORIGIN/../../../../lib${LLVM_LIBDIR_SUFFIX}")
+endif()
+
 if (MSVC)
   set_source_files_properties(SBReproducer.cpp PROPERTIES COMPILE_FLAGS 
/bigobj)
 endif()



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

[Lldb-commits] [PATCH] D72286: installation: Accept separate install prefix for LLDB.framework

[Vedant Kumar via Phabricator via lldb-commits]

vsk planned changes to this revision.
vsk added a comment.

Hm, the new framework install prefix seems redundant with CMAKE_INSTALL_PREFIX. 
Let me see if they can be shared.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D72286/new/

https://reviews.llvm.org/D72286



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

[Lldb-commits] [lldb] 3abc292 - [lldb/Test] Move @skipIfAsan from test class to test methods.

[Jonas Devlieghere via lldb-commits]

Author: Jonas Devlieghere
Date: 2020-01-06T09:53:06-08:00
New Revision: 3abc2927cb2372349fbbc0b62382c85d7d000f2c

URL: 
https://github.com/llvm/llvm-project/commit/3abc2927cb2372349fbbc0b62382c85d7d000f2c
DIFF: 
https://github.com/llvm/llvm-project/commit/3abc2927cb2372349fbbc0b62382c85d7d000f2c.diff

LOG: [lldb/Test] Move @skipIfAsan from test class to test methods.

skipTestIfFn can only be used to decorate a test method.

Added: 


Modified: 

lldb/packages/Python/lldbsuite/test/lang/objc/foundation/TestFoundationDisassembly.py

Removed: 




diff  --git 
a/lldb/packages/Python/lldbsuite/test/lang/objc/foundation/TestFoundationDisassembly.py
 
b/lldb/packages/Python/lldbsuite/test/lang/objc/foundation/TestFoundationDisassembly.py
index d297349509d2..9e39a735f8bd 100644
--- 
a/lldb/packages/Python/lldbsuite/test/lang/objc/foundation/TestFoundationDisassembly.py
+++ 
b/lldb/packages/Python/lldbsuite/test/lang/objc/foundation/TestFoundationDisassembly.py
@@ -11,13 +11,13 @@
 
 
 @skipUnlessDarwin
-@skipIfAsan
 class FoundationDisassembleTestCase(TestBase):
 
 mydir = TestBase.compute_mydir(__file__)
 
 NO_DEBUG_INFO_TESTCASE = True
 
+@skipIfAsan
 def test_foundation_disasm(self):
 """Do 'disassemble -n func' on each and every 'Code' symbol entry from 
the Foundation.framework."""
 self.build()
@@ -63,6 +63,7 @@ def test_foundation_disasm(self):
 self.runCmd('image lookup -s "%s"' % func)
 self.runCmd('disassemble -n "%s"' % func)
 
+@skipIfAsan
 def test_simple_disasm(self):
 """Test the lldb 'disassemble' command"""
 self.build()



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

[Lldb-commits] [PATCH] D71379: lldbutil: Forward ASan launch info to test inferiors

[Vedant Kumar via Phabricator via lldb-commits]

vsk added a comment.

Ping.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D71379/new/

https://reviews.llvm.org/D71379



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

[Lldb-commits] [PATCH] D72286: installation: Accept separate install prefix for LLDB.framework

[Vedant Kumar via Phabricator via lldb-commits]

vsk created this revision.
vsk added reviewers: davide, teemperor, friss.
Herald added a subscriber: mgorny.

To support multi-arch (fat) builds of swift-lldb, the build script sets
up separate per-arch install directories, runs each arch-specific build,
and then lipo's together the contents.

Split up LLDB_FRAMEWORK_INSTALL_DIR into a prefix (this can be supplied
by the build script) and the final install location. The concatenated
path is called LLDB_FRAMEWORK_INSTALL_PATH.

The idea is to have the build script supply the prefix used for the lipo step,
and for lldb's cmake caches to specify the right install dir for a given target.


https://reviews.llvm.org/D72286

Files:
  lldb/CMakeLists.txt
  lldb/cmake/modules/AddLLDB.cmake
  lldb/cmake/modules/LLDBConfig.cmake
  lldb/cmake/modules/LLDBFramework.cmake
  lldb/source/API/CMakeLists.txt


Index: lldb/source/API/CMakeLists.txt
===
--- lldb/source/API/CMakeLists.txt
+++ lldb/source/API/CMakeLists.txt
@@ -15,7 +15,7 @@
 endif()
 
 if(LLDB_BUILD_FRAMEWORK)
-  set(option_install_prefix INSTALL_PREFIX ${LLDB_FRAMEWORK_INSTALL_DIR})
+  set(option_install_prefix INSTALL_PREFIX ${LLDB_FRAMEWORK_INSTALL_PATH})
   set(option_framework FRAMEWORK)
 endif()
 
Index: lldb/cmake/modules/LLDBFramework.cmake
===
--- lldb/cmake/modules/LLDBFramework.cmake
+++ lldb/cmake/modules/LLDBFramework.cmake
@@ -1,5 +1,5 @@
 message(STATUS "LLDB.framework: build path is 
'${LLDB_FRAMEWORK_ABSOLUTE_BUILD_DIR}'")
-message(STATUS "LLDB.framework: install path is 
'${LLDB_FRAMEWORK_INSTALL_DIR}'")
+message(STATUS "LLDB.framework: install path is 
'${LLDB_FRAMEWORK_INSTALL_PATH}'")
 message(STATUS "LLDB.framework: resources subdirectory is 
'Versions/${LLDB_FRAMEWORK_VERSION}/Resources'")
 
 # Configure liblldb as a framework bundle
@@ -27,7 +27,7 @@
   LIBRARY_DIR ${LLDB_FRAMEWORK_ABSOLUTE_BUILD_DIR}
 )
 
-lldb_add_post_install_steps_darwin(liblldb ${LLDB_FRAMEWORK_INSTALL_DIR})
+lldb_add_post_install_steps_darwin(liblldb ${LLDB_FRAMEWORK_INSTALL_PATH})
 
 # Affects the layout of the framework bundle (default is macOS layout).
 if(IOS)
Index: lldb/cmake/modules/LLDBConfig.cmake
===
--- lldb/cmake/modules/LLDBConfig.cmake
+++ lldb/cmake/modules/LLDBConfig.cmake
@@ -90,7 +90,9 @@
 
   set(LLDB_FRAMEWORK_VERSION A CACHE STRING "LLDB.framework version (default 
is A)")
   set(LLDB_FRAMEWORK_BUILD_DIR bin CACHE STRING "Output directory for 
LLDB.framework")
+  set(LLDB_FRAMEWORK_INSTALL_PREFIX "" CACHE STRING "Prefix for the 
LLDB.framework install directory")
   set(LLDB_FRAMEWORK_INSTALL_DIR Library/Frameworks CACHE STRING "Install 
directory for LLDB.framework")
+  set(LLDB_FRAMEWORK_INSTALL_PATH 
"${LLDB_FRAMEWORK_INSTALL_PREFIX}${LLDB_FRAMEWORK_INSTALL_DIR}")
 
   get_filename_component(LLDB_FRAMEWORK_ABSOLUTE_BUILD_DIR 
${LLDB_FRAMEWORK_BUILD_DIR} ABSOLUTE
 BASE_DIR ${CMAKE_BINARY_DIR}/${CMAKE_CFG_INTDIR})
Index: lldb/cmake/modules/AddLLDB.cmake
===
--- lldb/cmake/modules/AddLLDB.cmake
+++ lldb/cmake/modules/AddLLDB.cmake
@@ -218,7 +218,7 @@
 set(subdir LLDB.framework/Versions/${LLDB_FRAMEWORK_VERSION}/Resources)
 add_lldb_executable(${name}
   GENERATE_INSTALL
-  INSTALL_PREFIX ${LLDB_FRAMEWORK_INSTALL_DIR}/${subdir}
+  INSTALL_PREFIX ${LLDB_FRAMEWORK_INSTALL_PATH}/${subdir}
   ${ARG_UNPARSED_ARGUMENTS}
 )
 lldb_add_to_buildtree_lldb_framework(${name} ${subdir})
Index: lldb/CMakeLists.txt
===
--- lldb/CMakeLists.txt
+++ lldb/CMakeLists.txt
@@ -221,7 +221,7 @@
 
   # Install the LLDB python module
   if(LLDB_BUILD_FRAMEWORK)
-set(LLDB_PYTHON_INSTALL_PATH 
${LLDB_FRAMEWORK_INSTALL_DIR}/LLDB.framework/Resources/Python)
+set(LLDB_PYTHON_INSTALL_PATH 
${LLDB_FRAMEWORK_INSTALL_PATH}/LLDB.framework/Resources/Python)
   else()
 set(LLDB_PYTHON_INSTALL_PATH ${LLDB_PYTHON_RELATIVE_PATH})
   endif()


Index: lldb/source/API/CMakeLists.txt
===
--- lldb/source/API/CMakeLists.txt
+++ lldb/source/API/CMakeLists.txt
@@ -15,7 +15,7 @@
 endif()
 
 if(LLDB_BUILD_FRAMEWORK)
-  set(option_install_prefix INSTALL_PREFIX ${LLDB_FRAMEWORK_INSTALL_DIR})
+  set(option_install_prefix INSTALL_PREFIX ${LLDB_FRAMEWORK_INSTALL_PATH})
   set(option_framework FRAMEWORK)
 endif()
 
Index: lldb/cmake/modules/LLDBFramework.cmake
===
--- lldb/cmake/modules/LLDBFramework.cmake
+++ lldb/cmake/modules/LLDBFramework.cmake
@@ -1,5 +1,5 @@
 message(STATUS "LLDB.framework: build path is '${LLDB_FRAMEWORK_ABSOLUTE_BUILD_DIR}'")
-message(STATUS "LLDB.framework: install path is '${LLDB_FRAMEWORK_INSTALL_DIR}'")
+message(STATUS "LLDB.framework: 

[Lldb-commits] [PATCH] D72107: [lldb/CMake] Autodetect Python dependency

[Jonas Devlieghere via Phabricator via lldb-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGb3757f3091d1: [lldb/CMake] Autodetect Python dependency 
(authored by JDevlieghere).

Changed prior to commit:
  https://reviews.llvm.org/D72107?vs=235942=236393#toc

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D72107/new/

https://reviews.llvm.org/D72107

Files:
  lldb/cmake/modules/FindPythonInterpAndLibs.cmake
  lldb/cmake/modules/LLDBConfig.cmake
  lldb/lldb/cmake/modules/FindPythonInterpAndLibs.cmake

Index: lldb/lldb/cmake/modules/FindPythonInterpAndLibs.cmake
===
--- /dev/null
+++ lldb/lldb/cmake/modules/FindPythonInterpAndLibs.cmake
@@ -0,0 +1,51 @@
+#.rst:
+# FindPythonInterpndLibs
+# ---
+#
+# Find the python interpreter and libraries as a whole.
+
+if(PYTHON_LIBRARIES AND PYTHON_INCLUDE_DIRS AND PYTHON_EXECUTABLE)
+  set(PYTHONINTERPANDLIBS_FOUND TRUE)
+else()
+  if ("${CMAKE_SYSTEM_NAME}" STREQUAL "Windows")
+find_package(Python3 COMPONENTS Interpreter Development QUIET)
+if (Python3_FOUND AND Python3_Interpreter_FOUND)
+  set(PYTHON_LIBRARIES ${Python3_LIBRARIES})
+  set(PYTHON_INCLUDE_DIRS ${Python3_INCLUDE_DIRS})
+  set(PYTHON_EXECUTABLE ${Python3_EXECUTABLE})
+  mark_as_advanced(
+PYTHON_LIBRARIES
+PYTHON_INCLUDE_DIRS
+PYTHON_EXECUTABLE)
+endif()
+  else()
+find_package(PythonInterp QUIET)
+find_package(PythonLibs QUIET)
+if(PYTHONINTERP_FOUND AND PYTHONLIBS_FOUND)
+  if (NOT CMAKE_CROSSCOMPILING)
+string(REPLACE "." ";" pythonlibs_version_list ${PYTHONLIBS_VERSION_STRING})
+list(GET pythonlibs_version_list 0 pythonlibs_major)
+list(GET pythonlibs_version_list 1 pythonlibs_minor)
+
+# Ignore the patch version. Some versions of macOS report a different
+# patch version for the system provided interpreter and libraries.
+if (CMAKE_CROSSCOMPILING OR (PYTHON_VERSION_MAJOR VERSION_EQUAL pythonlibs_major AND
+PYTHON_VERSION_MINOR VERSION_EQUAL pythonlibs_minor))
+  mark_as_advanced(
+PYTHON_LIBRARIES
+PYTHON_INCLUDE_DIRS
+PYTHON_EXECUTABLE)
+endif()
+  endif()
+endif()
+  endif()
+
+  include(FindPackageHandleStandardArgs)
+  find_package_handle_standard_args(PythonInterpAndLibs
+FOUND_VAR
+  PYTHONINTERPANDLIBS_FOUND
+REQUIRED_VARS
+  PYTHON_LIBRARIES
+  PYTHON_INCLUDE_DIRS
+  PYTHON_EXECUTABLE)
+endif()
Index: lldb/cmake/modules/LLDBConfig.cmake
===
--- lldb/cmake/modules/LLDBConfig.cmake
+++ lldb/cmake/modules/LLDBConfig.cmake
@@ -51,16 +51,8 @@
 add_optional_dependency(LLDB_ENABLE_CURSES "Enable curses support in LLDB" CursesAndPanel CURSESANDPANEL_FOUND)
 add_optional_dependency(LLDB_ENABLE_LZMA "Enable LZMA compression support in LLDB" LibLZMA LIBLZMA_FOUND)
 add_optional_dependency(LLDB_ENABLE_LUA "Enable Lua scripting support in LLDB" Lua LUA_FOUND)
+add_optional_dependency(LLDB_ENABLE_PYTHON "Enable Python scripting support in LLDB" PythonInterpAndLibs PYTHONINTERPANDLIBS_FOUND)
 
-set(default_enable_python ON)
-
-if(CMAKE_SYSTEM_NAME MATCHES "Android")
-  set(default_enable_python OFF)
-elseif(IOS)
-  set(default_enable_python OFF)
-endif()
-
-option(LLDB_ENABLE_PYTHON "Enable Python scripting integration." ${default_enable_python})
 option(LLDB_RELOCATABLE_PYTHON "Use the PYTHONHOME environment variable to locate Python." OFF)
 option(LLDB_USE_SYSTEM_SIX "Use six.py shipped with system and do not install a copy of it" OFF)
 option(LLDB_USE_ENTITLEMENTS "When codesigning, use entitlements if available" ON)
@@ -142,48 +134,13 @@
 endif()
 
 if (LLDB_ENABLE_PYTHON)
-  if ("${CMAKE_SYSTEM_NAME}" STREQUAL "Windows")
-find_package(Python3 COMPONENTS Interpreter Development REQUIRED)
-if(Python3_VERSION VERSION_LESS 3.5)
-  message(SEND_ERROR "Python 3.5 or newer is required (found: ${Python3_VERSION}")
-endif()
-set(PYTHON_LIBRARIES ${Python3_LIBRARIES})
-include_directories(${Python3_INCLUDE_DIRS})
-
-if (NOT LLDB_RELOCATABLE_PYTHON)
-  get_filename_component(PYTHON_HOME "${Python3_EXECUTABLE}" DIRECTORY)
-  file(TO_CMAKE_PATH "${PYTHON_HOME}" LLDB_PYTHON_HOME)
-endif()
-  else()
-find_package(PythonInterp REQUIRED)
-find_package(PythonLibs REQUIRED)
-
-if (NOT CMAKE_CROSSCOMPILING)
-  string(REPLACE "." ";" pythonlibs_version_list ${PYTHONLIBS_VERSION_STRING})
-  list(GET pythonlibs_version_list 0 pythonlibs_major)
-  list(GET pythonlibs_version_list 1 pythonlibs_minor)
-
-  # Ignore the patch version. Some versions of macOS report a different patch
-

[Lldb-commits] [lldb] 8eba3fb - [lldb/Test] Temporarily skip TestFoundationDisassembly on the ASan bot.

[Jonas Devlieghere via lldb-commits]

Author: Jonas Devlieghere
Date: 2020-01-06T09:06:09-08:00
New Revision: 8eba3fbb12fc179959f709aa93f9af8d902fb6d7

URL: 
https://github.com/llvm/llvm-project/commit/8eba3fbb12fc179959f709aa93f9af8d902fb6d7
DIFF: 
https://github.com/llvm/llvm-project/commit/8eba3fbb12fc179959f709aa93f9af8d902fb6d7.diff

LOG: [lldb/Test] Temporarily skip TestFoundationDisassembly on the ASan bot.

This test is timing out on the sanitized bot on GreenDragon. Temporarily
disable it to increase the signal-to-noise ration.

Added: 


Modified: 

lldb/packages/Python/lldbsuite/test/lang/objc/foundation/TestFoundationDisassembly.py

Removed: 




diff  --git 
a/lldb/packages/Python/lldbsuite/test/lang/objc/foundation/TestFoundationDisassembly.py
 
b/lldb/packages/Python/lldbsuite/test/lang/objc/foundation/TestFoundationDisassembly.py
index b42aeb14226b..d297349509d2 100644
--- 
a/lldb/packages/Python/lldbsuite/test/lang/objc/foundation/TestFoundationDisassembly.py
+++ 
b/lldb/packages/Python/lldbsuite/test/lang/objc/foundation/TestFoundationDisassembly.py
@@ -11,6 +11,7 @@
 
 
 @skipUnlessDarwin
+@skipIfAsan
 class FoundationDisassembleTestCase(TestBase):
 
 mydir = TestBase.compute_mydir(__file__)



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

[Lldb-commits] [lldb] b3757f3 - [lldb/CMake] Autodetect Python dependency

[Jonas Devlieghere via lldb-commits]

Author: Jonas Devlieghere
Date: 2020-01-06T09:05:05-08:00
New Revision: b3757f3091d1c718a91f5b06b7364b2af28339fa

URL: 
https://github.com/llvm/llvm-project/commit/b3757f3091d1c718a91f5b06b7364b2af28339fa
DIFF: 
https://github.com/llvm/llvm-project/commit/b3757f3091d1c718a91f5b06b7364b2af28339fa.diff

LOG: [lldb/CMake] Autodetect Python dependency

Python was the last remaining "optional" dependency for LLDB. This moves
the code to find Python into FindPythonInterpAndLibs using the same
principles as FindCursesAndPanel.

Differential revision: https://reviews.llvm.org/D72107

Added: 
lldb/cmake/modules/FindPythonInterpAndLibs.cmake
lldb/lldb/cmake/modules/FindPythonInterpAndLibs.cmake

Modified: 
lldb/cmake/modules/LLDBConfig.cmake

Removed: 




diff  --git a/lldb/cmake/modules/FindPythonInterpAndLibs.cmake 
b/lldb/cmake/modules/FindPythonInterpAndLibs.cmake
new file mode 100644
index ..fcbf0212d72b
--- /dev/null
+++ b/lldb/cmake/modules/FindPythonInterpAndLibs.cmake
@@ -0,0 +1,51 @@
+#.rst:
+# FindPythonInterpAndLibs
+# ---
+#
+# Find the python interpreter and libraries as a whole.
+
+if(PYTHON_LIBRARIES AND PYTHON_INCLUDE_DIRS AND PYTHON_EXECUTABLE)
+  set(PYTHONINTERPANDLIBS_FOUND TRUE)
+else()
+  if ("${CMAKE_SYSTEM_NAME}" STREQUAL "Windows")
+find_package(Python3 COMPONENTS Interpreter Development QUIET)
+if (Python3_FOUND AND Python3_Interpreter_FOUND)
+  set(PYTHON_LIBRARIES ${Python3_LIBRARIES})
+  set(PYTHON_INCLUDE_DIRS ${Python3_INCLUDE_DIRS})
+  set(PYTHON_EXECUTABLE ${Python3_EXECUTABLE})
+  mark_as_advanced(
+PYTHON_LIBRARIES
+PYTHON_INCLUDE_DIRS
+PYTHON_EXECUTABLE)
+endif()
+  else()
+find_package(PythonInterp QUIET)
+find_package(PythonLibs QUIET)
+if(PYTHONINTERP_FOUND AND PYTHONLIBS_FOUND)
+  if (NOT CMAKE_CROSSCOMPILING)
+string(REPLACE "." ";" pythonlibs_version_list 
${PYTHONLIBS_VERSION_STRING})
+list(GET pythonlibs_version_list 0 pythonlibs_major)
+list(GET pythonlibs_version_list 1 pythonlibs_minor)
+
+# Ignore the patch version. Some versions of macOS report a 
diff erent
+# patch version for the system provided interpreter and libraries.
+if (CMAKE_CROSSCOMPILING OR (PYTHON_VERSION_MAJOR VERSION_EQUAL 
pythonlibs_major AND
+PYTHON_VERSION_MINOR VERSION_EQUAL pythonlibs_minor))
+  mark_as_advanced(
+PYTHON_LIBRARIES
+PYTHON_INCLUDE_DIRS
+PYTHON_EXECUTABLE)
+endif()
+  endif()
+endif()
+  endif()
+
+  include(FindPackageHandleStandardArgs)
+  find_package_handle_standard_args(PythonInterpAndLibs
+FOUND_VAR
+  PYTHONINTERPANDLIBS_FOUND
+REQUIRED_VARS
+  PYTHON_LIBRARIES
+  PYTHON_INCLUDE_DIRS
+  PYTHON_EXECUTABLE)
+endif()

diff  --git a/lldb/cmake/modules/LLDBConfig.cmake 
b/lldb/cmake/modules/LLDBConfig.cmake
index 52b8257951be..12fb97fc9d7d 100644
--- a/lldb/cmake/modules/LLDBConfig.cmake
+++ b/lldb/cmake/modules/LLDBConfig.cmake
@@ -51,16 +51,8 @@ add_optional_dependency(LLDB_ENABLE_LIBEDIT "Enable editline 
support in LLDB" Li
 add_optional_dependency(LLDB_ENABLE_CURSES "Enable curses support in LLDB" 
CursesAndPanel CURSESANDPANEL_FOUND)
 add_optional_dependency(LLDB_ENABLE_LZMA "Enable LZMA compression support in 
LLDB" LibLZMA LIBLZMA_FOUND)
 add_optional_dependency(LLDB_ENABLE_LUA "Enable Lua scripting support in LLDB" 
Lua LUA_FOUND)
+add_optional_dependency(LLDB_ENABLE_PYTHON "Enable Python scripting support in 
LLDB" PythonInterpAndLibs PYTHONINTERPANDLIBS_FOUND)
 
-set(default_enable_python ON)
-
-if(CMAKE_SYSTEM_NAME MATCHES "Android")
-  set(default_enable_python OFF)
-elseif(IOS)
-  set(default_enable_python OFF)
-endif()
-
-option(LLDB_ENABLE_PYTHON "Enable Python scripting integration." 
${default_enable_python})
 option(LLDB_RELOCATABLE_PYTHON "Use the PYTHONHOME environment variable to 
locate Python." OFF)
 option(LLDB_USE_SYSTEM_SIX "Use six.py shipped with system and do not install 
a copy of it" OFF)
 option(LLDB_USE_ENTITLEMENTS "When codesigning, use entitlements if available" 
ON)
@@ -142,48 +134,13 @@ if (LLDB_ENABLE_LIBEDIT)
 endif()
 
 if (LLDB_ENABLE_PYTHON)
-  if ("${CMAKE_SYSTEM_NAME}" STREQUAL "Windows")
-find_package(Python3 COMPONENTS Interpreter Development REQUIRED)
-if(Python3_VERSION VERSION_LESS 3.5)
-  message(SEND_ERROR "Python 3.5 or newer is required (found: 
${Python3_VERSION}")
-endif()
-set(PYTHON_LIBRARIES ${Python3_LIBRARIES})
-include_directories(${Python3_INCLUDE_DIRS})
-
-if (NOT LLDB_RELOCATABLE_PYTHON)
-  get_filename_component(PYTHON_HOME "${Python3_EXECUTABLE}" DIRECTORY)
-  

[Lldb-commits] [PATCH] D63540: Fix lookup of symbols with the same address range but different binding

[Jan Kratochvil via Phabricator via lldb-commits]

jankratochvil planned changes to this revision.
jankratochvil added a comment.

In D63540#1805967 , @labath wrote:

> Passing different sort objects to different sort invocations could cause 
> changes done by one Sort call to be undone by further Symtab additions 
> (and/or trigger assertions in the `IsSorted` function). It seems to me that 
> the sort order should be a property of the RangeMap object, set when the 
> object is created, similar to how std::map and friends do this thing...


I did not like it much myself but I did not realize when it could really cause 
a problem, thanks for the example. I will try to find some way.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D63540/new/

https://reviews.llvm.org/D63540



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

[Lldb-commits] [PATCH] D71906: [lldb][tests] Make it possible to expect failure for a whole category

[Tatyana Krasnukha via Phabricator via lldb-commits]

tatyana-krasnukha updated this revision to Diff 236374.
tatyana-krasnukha added a comment.

Increased number of lines of context.

Jonas, yes, it is.

Pavel, names are consistent (if I understand your comment correctly). The 
"--xfail-category" is singular like the "--skip-category".


Repository:
  rLLDB LLDB

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D71906/new/

https://reviews.llvm.org/D71906

Files:
  lldb/packages/Python/lldbsuite/test/configuration.py
  lldb/packages/Python/lldbsuite/test/dotest.py
  lldb/packages/Python/lldbsuite/test/dotest_args.py
  lldb/packages/Python/lldbsuite/test/test_result.py


Index: lldb/packages/Python/lldbsuite/test/test_result.py
===
--- lldb/packages/Python/lldbsuite/test/test_result.py
+++ lldb/packages/Python/lldbsuite/test/test_result.py
@@ -156,6 +156,10 @@
 return True
 return False
 
+def checkCategoryExclusion(self, exclusion_list, test):
+return not set(exclusion_list).isdisjoint(
+self.getCategoriesForTest(test))
+
 def startTest(self, test):
 if configuration.shouldSkipBecauseOfCategories(
 self.getCategoriesForTest(test)):
@@ -174,8 +178,10 @@
 EventBuilder.event_for_start(test))
 
 def addSuccess(self, test):
-if self.checkExclusion(
-configuration.xfail_tests, test.id()):
+if (self.checkExclusion(
+configuration.xfail_tests, test.id()) or
+self.checkCategoryExclusion(
+configuration.xfail_categories, test)):
 self.addUnexpectedSuccess(test, None)
 return
 
@@ -245,8 +251,10 @@
 test, err))
 
 def addFailure(self, test, err):
-if self.checkExclusion(
-configuration.xfail_tests, test.id()):
+if (self.checkExclusion(
+configuration.xfail_tests, test.id()) or
+self.checkCategoryExclusion(
+configuration.xfail_categories, test)):
 self.addExpectedFailure(test, err, None)
 return
 
Index: lldb/packages/Python/lldbsuite/test/dotest_args.py
===
--- lldb/packages/Python/lldbsuite/test/dotest_args.py
+++ lldb/packages/Python/lldbsuite/test/dotest_args.py
@@ -84,6 +84,12 @@
 action='append',
 dest='skip_categories',
 help=textwrap.dedent('''Specify categories of test cases to skip. 
Takes precedence over -G. Can be specified more than once.'''))
+group.add_argument(
+'--xfail-category',
+metavar='category',
+action='append',
+dest='xfail_categories',
+help=textwrap.dedent('''Specify categories of test cases that are 
expected to fail. Can be specified more than once.'''))
 
 # Configuration options
 group = parser.add_argument_group('Configuration options')
Index: lldb/packages/Python/lldbsuite/test/dotest.py
===
--- lldb/packages/Python/lldbsuite/test/dotest.py
+++ lldb/packages/Python/lldbsuite/test/dotest.py
@@ -329,6 +329,10 @@
 configuration.skip_categories += test_categories.validate(
 args.skip_categories, False)
 
+if args.xfail_categories:
+configuration.xfail_categories += test_categories.validate(
+args.xfail_categories, False)
+
 if args.E:
 os.environ['CFLAGS_EXTRAS'] = args.E
 
Index: lldb/packages/Python/lldbsuite/test/configuration.py
===
--- lldb/packages/Python/lldbsuite/test/configuration.py
+++ lldb/packages/Python/lldbsuite/test/configuration.py
@@ -30,6 +30,8 @@
 use_categories = False
 # Categories we want to skip
 skip_categories = ["darwin-log"]
+# Categories we expect to fail
+xfail_categories = []
 # use this to track per-category failures
 failures_per_category = {}
 


Index: lldb/packages/Python/lldbsuite/test/test_result.py
===
--- lldb/packages/Python/lldbsuite/test/test_result.py
+++ lldb/packages/Python/lldbsuite/test/test_result.py
@@ -156,6 +156,10 @@
 return True
 return False
 
+def checkCategoryExclusion(self, exclusion_list, test):
+return not set(exclusion_list).isdisjoint(
+self.getCategoriesForTest(test))
+
 def startTest(self, test):
 if configuration.shouldSkipBecauseOfCategories(
 self.getCategoriesForTest(test)):
@@ -174,8 +178,10 @@
 EventBuilder.event_for_start(test))
 
 def addSuccess(self, test):
-if self.checkExclusion(
-configuration.xfail_tests, test.id()):
+if (self.checkExclusion(
+configuration.xfail_tests, test.id()) or
+self.checkCategoryExclusion(
+

[Lldb-commits] [PATCH] D63540: Fix lookup of symbols with the same address range but different binding

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

Thanks Jan and Omair for the investigation. It does seem like there is some 
more work to be done on arm/thumb in elf code in lldb, as it seems to me that 
things are working now more-or-less accidentally.

The good news is that this should not require any fundamental changes since the 
address class determination happens in ObjectFile::GetAddressClass, we'd 
probably just need to tweak it's ELF implementation somehow (not fully clear 
how yet).

But anyway, I do agree that this can be done seperately from the binding 
prioritization change. As for the change itself, I think we're getting closer, 
but I am still not convinced by the extra RangeMap::Sort overload. Passing 
different sort objects to different sort invocations could cause changes done 
by one Sort call to be undone by further Symtab additions (and/or trigger 
assertions in the `IsSorted` function). It seems to me that the sort order 
should be a property of the RangeMap object, set when the object is created, 
similar to how std::map and friends do this thing...


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D63540/new/

https://reviews.llvm.org/D63540



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

[Lldb-commits] [PATCH] D72195: [lldb] [Process/NetBSD] Remove unused orig_*ax use

[Michał Górny via Phabricator via lldb-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGbc763c42bbcf: [lldb] [Process/NetBSD] Remove unused orig_*ax 
use (authored by mgorny).
Herald added a project: LLDB.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D72195/new/

https://reviews.llvm.org/D72195

Files:
  lldb/source/Plugins/Process/NetBSD/NativeRegisterContextNetBSD_x86_64.cpp


Index: lldb/source/Plugins/Process/NetBSD/NativeRegisterContextNetBSD_x86_64.cpp
===
--- lldb/source/Plugins/Process/NetBSD/NativeRegisterContextNetBSD_x86_64.cpp
+++ lldb/source/Plugins/Process/NetBSD/NativeRegisterContextNetBSD_x86_64.cpp
@@ -725,11 +725,6 @@
   ::memcpy(dst, _gpr_x86_64, GetRegisterInfoInterface().GetGPRSize());
   dst += GetRegisterInfoInterface().GetGPRSize();
 
-  RegisterValue value((uint64_t)-1);
-  const RegisterInfo *reg_info =
-  GetRegisterInfoInterface().GetDynamicRegisterInfo("orig_eax");
-  if (reg_info == nullptr)
-reg_info = GetRegisterInfoInterface().GetDynamicRegisterInfo("orig_rax");
   return error;
 }
 


Index: lldb/source/Plugins/Process/NetBSD/NativeRegisterContextNetBSD_x86_64.cpp
===
--- lldb/source/Plugins/Process/NetBSD/NativeRegisterContextNetBSD_x86_64.cpp
+++ lldb/source/Plugins/Process/NetBSD/NativeRegisterContextNetBSD_x86_64.cpp
@@ -725,11 +725,6 @@
   ::memcpy(dst, _gpr_x86_64, GetRegisterInfoInterface().GetGPRSize());
   dst += GetRegisterInfoInterface().GetGPRSize();
 
-  RegisterValue value((uint64_t)-1);
-  const RegisterInfo *reg_info =
-  GetRegisterInfoInterface().GetDynamicRegisterInfo("orig_eax");
-  if (reg_info == nullptr)
-reg_info = GetRegisterInfoInterface().GetDynamicRegisterInfo("orig_rax");
   return error;
 }
 
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D72195: [lldb] [Process/NetBSD] Remove unused orig_*ax use

[Pavel Labath via Phabricator via lldb-commits]

labath accepted this revision.
labath added a comment.
This revision is now accepted and ready to land.

This seems fine, though it may be worth checking what happens when running 
expressions while the process is stopped in a syscall (does the expression run 
correctly, does the syscall resume correctly, etc.)...


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D72195/new/

https://reviews.llvm.org/D72195



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

[Lldb-commits] [PATCH] D72190: Removing C-style casts in favor of explict C++ style casts

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

This is fine, though, since you're already touching these lines, I'd consider 
converting them from LLDB_LOGF to LLDB_LOG at the same time (getting rid of 
most of the static_casts...).

However, I don't think we should be changing `(void)` to `static_cast`.

There is also ample precedent in llvm for using -1 (or sometimes `~0`) to mean 
UINTxx_MAX, so I'm not sure we should change that too. Though it is somewhat 
confusing, in a way, it is actually safer, as `-1` will always convert to the 
right `MAX` value. (e.g., in `foo = -1`, the value will remain fff...ff even if 
we change the type of foo from `uint32_t` to `uint64_t`, but that won't happen 
with UINT32_MAX)...




Comment at: lldb/source/Expression/IRExecutionUnit.cpp:306-307
   "jit-object-" + module->getModuleIdentifier() + "-%%%.o";
-  (void)llvm::sys::fs::createUniqueFile(object_name_model, fd, 
result_path);
+  static_cast(
+  llvm::sys::fs::createUniqueFile(object_name_model, fd, result_path));
   llvm::raw_fd_ostream fds(fd, true);

I think this is overkill. `(void)` is used throughout llvm as a way to 
explicitly ignore a value (usually done to supress some kind of a warning).


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D72190/new/

https://reviews.llvm.org/D72190



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

[Lldb-commits] [PATCH] D72161: [lldb][NFC] Use static_cast instead of reinterpret_cast where possible

[Pavel Labath via Phabricator via lldb-commits]

labath accepted this revision.
labath added a comment.
This revision is now accepted and ready to land.

cool


Repository:
  rLLDB LLDB

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D72161/new/

https://reviews.llvm.org/D72161



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

[Lldb-commits] [PATCH] D71800: [CMake] Add $ORIGIN/../../../../lib to rpath if BUILD_SHARED_LIBS or LLVM_LINK_LLVM_DYLIB on *nix

[Pavel Labath via Phabricator via lldb-commits]

labath accepted this revision.
labath added a comment.
This revision is now accepted and ready to land.

Thanks. I think this is fine now.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D71800/new/

https://reviews.llvm.org/D71800



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

[Lldb-commits] [PATCH] D72107: [lldb/CMake] Autodetect Python dependency

[Pavel Labath via Phabricator via lldb-commits]

labath accepted this revision.
labath added a comment.
This revision is now accepted and ready to land.

Looks fine to me. Thanks for tackling this.


Repository:
  rLLDB LLDB

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D72107/new/

https://reviews.llvm.org/D72107



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

[Lldb-commits] [PATCH] D72086: [lldb] Fix that SBThread.GetStopDescription is returning strings with uninitialized memory at the end.

[Pavel Labath via Phabricator via lldb-commits]

labath added a reviewer: jingham.
labath added a comment.

Would it be possible to fix this problem in the swig bindings instead? (i.e. 
move the `std::min` stuff into the swig code). That way, the behavior of this 
function will at least match that of snprintf, which will hopefully be less 
surprising that what you've done here. (And it will also fix the inconsistency 
noticed by @shafik).




Comment at: lldb/source/API/SBThread.cpp:337
+  }
   else {
 // NULL dst passed in, return the length needed to contain the

shafik wrote:
> The `else` branch feels inconsistent with the change above. Especially the `+ 
> 1`.
yep


Repository:
  rLLDB LLDB

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D72086/new/

https://reviews.llvm.org/D72086



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

[Lldb-commits] [PATCH] D71906: [lldb][tests] Make it possible to expect failure for a whole category

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

Seems reasonable, just make the option name consistent.




Comment at: packages/Python/lldbsuite/test/dotest_args.py:85-88
 dest='skip_categories',
 help=textwrap.dedent('''Specify categories of test cases to skip. 
Takes precedence over -G. Can be specified more than once.'''))
+group.add_argument(
+'--xfail-category',

Please use a consistent name for the two options.


Repository:
  rLLDB LLDB

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D71906/new/

https://reviews.llvm.org/D71906



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

[Lldb-commits] [PATCH] D71905: [lldb][tests] Take into account all parent's categories when traverse folders upwards

[Pavel Labath via Phabricator via lldb-commits]

labath requested changes to this revision.
labath added a comment.
This revision now requires changes to proceed.

The idea seems fine, but I think that the implementation needs more refinement, 
per the inline comments...




Comment at: packages/Python/lldbsuite/test/test_result.py:111-112
+collecting values of ".categories" files. We start at the folder the 
test is in
+and traverse the hierarchy upwards - we guarantee a .categories to 
exist
 at the top level directory so we do not end up looping endlessly.
 """

This part is no longer true, as we continue searching after finding the first 
file.



Comment at: packages/Python/lldbsuite/test/test_result.py:119
+categories = set()
 while folder != '/':
 categories_file_name = os.path.join(folder, ".categories")

I don't think this will work on windows. I think we should stop iterating here 
as soon we reach the top level test folder (I don't know how to check that 
off-hand, but we should have that piece of information available somewhere.) 
That will also ensure we don't get confused by some spurious .categories file 
outside of the test tree.


Repository:
  rLLDB LLDB

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D71905/new/

https://reviews.llvm.org/D71905



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

[Lldb-commits] [PATCH] D72251: [RFC] Support SVE registers access on AArch64 Linux

[Muhammad Omair Javaid via Phabricator via lldb-commits]

omjavaid created this revision.
omjavaid added reviewers: labath, clayborg, jankratochvil, jasonmolenda.
omjavaid added a project: LLDB.
Herald added subscribers: kristof.beyls, tschuett.
Herald added a reviewer: rengolin.

This is an RFC patch for the on going effort to support SVE registers access on 
AArch64 Linux. This patch lays down the structure and major parts of the 
implementation and seeks community feedback on overall design approach more 
specifically to the generic areas of gdb-remote process, register infos and 
register context classes.

The Scalable Vector Extension (SVE)  is an optional extension introduced by the 
ARMv8.2 architecture and can be implemented by underlying hardware AArch64 
execution state. SVE has introduced  32 Z registers (Z0..Z31), 16 P register 
(P0..P15 ) and an FFR register.  All these 
registers can change their size dynamically during execution. SVE register 
sizes is governed by currently set vector length in multiples of 16 bytes. Z 
register has a 16 byte default size and its size can increase in multiples of 
16 bytes upto 128 bytes. While size of P and FFR registers is equal to size of 
Z register divided by 8. Linux tracks SVE register per thread and each thread 
can have its own setting of vector length upon which its size is decided.

First part of this implementation deals with adding capability for dynamic 
size/offset update in register info description hosted by gdb-remote process 
and also on native Linux side. Also we have to make these register description 
per_thread so that they can have their own size and offset.

Also there has to be a way to exchange update size information between remote 
target and host. This is where VG (Vector Granule) pseudo register comes in, VG 
is the size of a Z register in 8 bytes (64bits) multiples. This information is 
read from PTRACE and sent back via expedited registers list. We have altered 
expedited register list to send a custom register set other than the register 
set at index 0 which is choosen by default. Once read by the host VG will help 
updated register sizes and offsets in DynamicRegisterInfos hosted by each 
gdb-remote thread.

Similarly on native size there is ConfigureRegisterContext function which will 
update register infos accordingly. Rest of code is implementation of register 
infos for SVE, some modifications to register infos to support SVE and register 
context linux ptrace access routines.

I am still working on some areas like offset sync and register data resizing. 
Looking forward to hear your feedback.


https://reviews.llvm.org/D72251

Files:
  lldb/include/lldb/Host/common/NativeRegisterContext.h
  lldb/include/lldb/Utility/RegisterValue.h
  lldb/source/Plugins/Process/Linux/LinuxPTraceDefines_arm64sve.h
  lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux.h
  lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp
  lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.h
  lldb/source/Plugins/Process/Linux/NativeThreadLinux.h
  lldb/source/Plugins/Process/Utility/DynamicRegisterInfo.cpp
  lldb/source/Plugins/Process/Utility/DynamicRegisterInfo.h
  lldb/source/Plugins/Process/Utility/NativeRegisterContextRegisterInfo.h
  lldb/source/Plugins/Process/Utility/RegisterInfoInterface.h
  lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm64.cpp
  lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm64.h
  lldb/source/Plugins/Process/Utility/RegisterInfos_arm64.h
  lldb/source/Plugins/Process/Utility/RegisterInfos_arm64_sve.h
  lldb/source/Plugins/Process/Utility/lldb-arm64-register-enums.h
  lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
  lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp
  lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.h
  lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
  lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.h
  lldb/source/Plugins/Process/gdb-remote/ThreadGDBRemote.cpp
  lldb/source/Utility/ARM64_DWARF_Registers.h
  lldb/source/Utility/ARM64_ehframe_Registers.h
  lldb/source/Utility/RegisterValue.cpp

Index: lldb/source/Utility/RegisterValue.cpp
===
--- lldb/source/Utility/RegisterValue.cpp
+++ lldb/source/Utility/RegisterValue.cpp
@@ -810,7 +810,7 @@
   if (buffer.length != rhs.buffer.length)
 return false;
   else {
-uint8_t length = buffer.length;
+uint32_t length = buffer.length;
 if (length > kMaxRegisterByteSize)
   length = kMaxRegisterByteSize;
 return memcmp(buffer.bytes, rhs.buffer.bytes, length) == 0;
Index: lldb/source/Utility/ARM64_ehframe_Registers.h
===
--- lldb/source/Utility/ARM64_ehframe_Registers.h
+++ lldb/source/Utility/ARM64_ehframe_Registers.h
@@ -49,10 +49,34 @@
   lr, // aka x30
   sp, // aka 

[Lldb-commits] [PATCH] D71857: [NFC] Fixes -Wrange-loop-analysis warnings

[Fangrui Song via Phabricator via lldb-commits]

MaskRay added a comment.

In D71857#1804307 , @Mordante wrote:

> In D71857#1800663 , @MaskRay wrote:
>
> > I think there is a false positive.
> >
> > https://github.com/llvm/llvm-project/tree/master/lld/ELF/Relocations.cpp#L1622
> >
> >   for (const std::pair ts : isd->thunkSections)
> >   
>
>
> Removing the `const` like L1648 will also solve the issue.


Yes, both `std::pair` and `auto` work, but `const std::pair` doesn't. std::pair 
has an unfortunate user-defined copy assignment operator 
(https://eel.is/c++draft/pairs#pair-16 "Assigns p.first to first and p.second 
to second." Does this wording mandate a user-defined function?) I will drop 
`const` for this lld file.

For other user-defined types. I think loosening the diagnostic to allow 
trivially copyable types will be nice. Types that take only a few words (say. 
1~3) are likely faster with a copy.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D71857/new/

https://reviews.llvm.org/D71857



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

[Lldb-commits] [PATCH] D71857: [NFC] Fixes -Wrange-loop-analysis warnings

[Mark de Wever via Phabricator via lldb-commits]

Mordante added a comment.

In D71857#1800663 , @MaskRay wrote:

> I think there is a false positive.
>
> https://github.com/llvm/llvm-project/tree/master/lld/ELF/Relocations.cpp#L1622
>
>   for (const std::pair ts : isd->thunkSections)
>   


Removing the `const` like L1648 will also solve the issue.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D71857/new/

https://reviews.llvm.org/D71857



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

[Lldb-commits] [PATCH] D70764: build: reduce CMake handling for zlib

[Khem Raj via Phabricator via lldb-commits]

raj.khem added a comment.

this is now in master, and I am seeing build failures in cross-building clang, 
e.g. when building clang for arm on a x86_64 host. its resorting to finding, 
libz from buildhost instead of target sysroot ( using --sysroot) and failing in 
link step. e.g.

FAILED: bin/llvm-config
...
 -o bin/llvm-config  -Wl,-rpath,"\$ORIGIN/../lib"  lib/libLLVMSupport.a  
/usr/lib/libz.so  -lrt  -ldl  -ltinfo  -lm  lib/libLLVMDemangle.a
...

aarch64-yoe-linux-musl/aarch64-yoe-linux-musl-ld: /usr/lib/libz.so: error 
adding symbols: file in wrong format
clang-10: error: linker command failed with exit code 1 (use -v to see 
invocation)

you can see that its adding /usr/lib/libz.so to linker cmdline while cross 
linking.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D70764/new/

https://reviews.llvm.org/D70764



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