[Lldb-commits] [lldb] r371172 - [lldb] Remove xcode bot from website listing and fix link to sanitized

2019-09-06 Thread Raphael Isemann via lldb-commits
Author: teemperor
Date: Fri Sep  6 00:11:14 2019
New Revision: 371172

URL: http://llvm.org/viewvc/llvm-project?rev=371172&view=rev
Log:
[lldb] Remove xcode bot from website listing and fix link to sanitized

Modified:
lldb/trunk/docs/resources/bots.rst

Modified: lldb/trunk/docs/resources/bots.rst
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/docs/resources/bots.rst?rev=371172&r1=371171&r2=371172&view=diff
==
--- lldb/trunk/docs/resources/bots.rst (original)
+++ lldb/trunk/docs/resources/bots.rst Fri Sep  6 00:11:14 2019
@@ -31,6 +31,5 @@ GreenDragon builds and tests LLDB on mac
 * `lldb-cmake-matrix 
`_
 * `lldb-cmake-python3 
`_
 * `lldb-cmake-standalone 
`_
-* `lldb-sanitized 
`_
-* `lldb-xcode `_
+* `lldb-cmake-sanitized 
`_
 


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


[Lldb-commits] [lldb] r371176 - [lldb][NFC] Remove unused Args::GetArgumentQuoteCharAtIndex

2019-09-06 Thread Raphael Isemann via lldb-commits
Author: teemperor
Date: Fri Sep  6 00:54:47 2019
New Revision: 371176

URL: http://llvm.org/viewvc/llvm-project?rev=371176&view=rev
Log:
[lldb][NFC] Remove unused Args::GetArgumentQuoteCharAtIndex

Modified:
lldb/trunk/include/lldb/Utility/Args.h
lldb/trunk/source/Utility/Args.cpp

Modified: lldb/trunk/include/lldb/Utility/Args.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Utility/Args.h?rev=371176&r1=371175&r2=371176&view=diff
==
--- lldb/trunk/include/lldb/Utility/Args.h (original)
+++ lldb/trunk/include/lldb/Utility/Args.h Fri Sep  6 00:54:47 2019
@@ -121,7 +121,6 @@ public:
   const char *GetArgumentAtIndex(size_t idx) const;
 
   llvm::ArrayRef entries() const { return m_entries; }
-  char GetArgumentQuoteCharAtIndex(size_t idx) const;
 
   using const_iterator = std::vector::const_iterator;
 

Modified: lldb/trunk/source/Utility/Args.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Utility/Args.cpp?rev=371176&r1=371175&r2=371176&view=diff
==
--- lldb/trunk/source/Utility/Args.cpp (original)
+++ lldb/trunk/source/Utility/Args.cpp Fri Sep  6 00:54:47 2019
@@ -260,12 +260,6 @@ const char *Args::GetArgumentAtIndex(siz
   return nullptr;
 }
 
-char Args::GetArgumentQuoteCharAtIndex(size_t idx) const {
-  if (idx < m_entries.size())
-return m_entries[idx].quote;
-  return '\0';
-}
-
 char **Args::GetArgumentVector() {
   assert(!m_argv.empty());
   // TODO: functions like execve and posix_spawnp exhibit undefined behavior


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


[Lldb-commits] [lldb] r371180 - [lldb][NFC] Extend ArgsTest

2019-09-06 Thread Raphael Isemann via lldb-commits
Author: teemperor
Date: Fri Sep  6 01:39:53 2019
New Revision: 371180

URL: http://llvm.org/viewvc/llvm-project?rev=371180&view=rev
Log:
[lldb][NFC] Extend ArgsTest

Modified:
lldb/trunk/unittests/Utility/ArgsTest.cpp

Modified: lldb/trunk/unittests/Utility/ArgsTest.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/unittests/Utility/ArgsTest.cpp?rev=371180&r1=371179&r2=371180&view=diff
==
--- lldb/trunk/unittests/Utility/ArgsTest.cpp (original)
+++ lldb/trunk/unittests/Utility/ArgsTest.cpp Fri Sep  6 01:39:53 2019
@@ -37,6 +37,34 @@ TEST(ArgsTest, TestSingleArgWithQuotedSp
   EXPECT_STREQ(args.GetArgumentAtIndex(0), "arg with space");
 }
 
+TEST(ArgsTest, TestTrailingBackslash) {
+  Args args;
+  args.SetCommandString("arg\\");
+  EXPECT_EQ(1u, args.GetArgumentCount());
+  EXPECT_STREQ(args.GetArgumentAtIndex(0), "arg\\");
+}
+
+TEST(ArgsTest, TestQuotedTrailingBackslash) {
+  Args args;
+  args.SetCommandString("\"arg\\");
+  EXPECT_EQ(1u, args.GetArgumentCount());
+  EXPECT_STREQ(args.GetArgumentAtIndex(0), "arg\\");
+}
+
+TEST(ArgsTest, TestUnknownEscape) {
+  Args args;
+  args.SetCommandString("arg\\y");
+  EXPECT_EQ(1u, args.GetArgumentCount());
+  EXPECT_STREQ(args.GetArgumentAtIndex(0), "arg\\y");
+}
+
+TEST(ArgsTest, TestQuotedUnknownEscape) {
+  Args args;
+  args.SetCommandString("\"arg\\y");
+  EXPECT_EQ(1u, args.GetArgumentCount());
+  EXPECT_STREQ(args.GetArgumentAtIndex(0), "arg\\y");
+}
+
 TEST(ArgsTest, TestMultipleArgs) {
   Args args;
   args.SetCommandString("this has multiple args");
@@ -214,3 +242,43 @@ TEST(ArgsTest, EscapeLLDBCommandArgument
   EXPECT_EQ("quux\t", Args::EscapeLLDBCommandArgument(quux, '`'));
   EXPECT_EQ("quux\t", Args::EscapeLLDBCommandArgument(quux, '"'));
 }
+
+TEST(ArgsTest, ReplaceArgumentAtIndexShort) {
+  Args args;
+  args.SetCommandString("foo ba b");
+  args.ReplaceArgumentAtIndex(0, "f");
+  EXPECT_EQ(3u, args.GetArgumentCount());
+  EXPECT_STREQ(args.GetArgumentAtIndex(0), "f");
+}
+
+TEST(ArgsTest, ReplaceArgumentAtIndexEqual) {
+  Args args;
+  args.SetCommandString("foo ba b");
+  args.ReplaceArgumentAtIndex(0, "bar");
+  EXPECT_EQ(3u, args.GetArgumentCount());
+  EXPECT_STREQ(args.GetArgumentAtIndex(0), "bar");
+}
+
+TEST(ArgsTest, ReplaceArgumentAtIndexLonger) {
+  Args args;
+  args.SetCommandString("foo ba b");
+  args.ReplaceArgumentAtIndex(0, "baar");
+  EXPECT_EQ(3u, args.GetArgumentCount());
+  EXPECT_STREQ(args.GetArgumentAtIndex(0), "baar");
+}
+
+TEST(ArgsTest, ReplaceArgumentAtIndexOutOfRange) {
+  Args args;
+  args.SetCommandString("foo ba b");
+  args.ReplaceArgumentAtIndex(3, "baar");
+  EXPECT_EQ(3u, args.GetArgumentCount());
+  EXPECT_STREQ(args.GetArgumentAtIndex(2), "b");
+}
+
+TEST(ArgsTest, ReplaceArgumentAtIndexFarOutOfRange) {
+  Args args;
+  args.SetCommandString("foo ba b");
+  args.ReplaceArgumentAtIndex(4, "baar");
+  EXPECT_EQ(3u, args.GetArgumentCount());
+  EXPECT_STREQ(args.GetArgumentAtIndex(2), "b");
+}


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


[Lldb-commits] [lldb] r371181 - [lldb][NFC] Remove Args::StripSpaces

2019-09-06 Thread Raphael Isemann via lldb-commits
Author: teemperor
Date: Fri Sep  6 01:40:31 2019
New Revision: 371181

URL: http://llvm.org/viewvc/llvm-project?rev=371181&view=rev
Log:
[lldb][NFC] Remove Args::StripSpaces

This just reimplemented llvm::StringRef::[r/l]trim().

Modified:
lldb/trunk/include/lldb/Utility/Args.h
lldb/trunk/source/Commands/CommandObjectSettings.cpp
lldb/trunk/source/Expression/REPL.cpp
lldb/trunk/source/Utility/Args.cpp

Modified: lldb/trunk/include/lldb/Utility/Args.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Utility/Args.h?rev=371181&r1=371180&r2=371181&view=diff
==
--- lldb/trunk/include/lldb/Utility/Args.h (original)
+++ lldb/trunk/include/lldb/Utility/Args.h Fri Sep  6 01:40:31 2019
@@ -251,10 +251,6 @@ public:
   // For re-setting or blanking out the list of arguments.
   void Clear();
 
-  static const char *StripSpaces(std::string &s, bool leading = true,
- bool trailing = true,
- bool return_null_if_empty = true);
-
   static bool UInt64ValueIsValidForByteSize(uint64_t uval64,
 size_t total_byte_size) {
 if (total_byte_size > 8)

Modified: lldb/trunk/source/Commands/CommandObjectSettings.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Commands/CommandObjectSettings.cpp?rev=371181&r1=371180&r2=371181&view=diff
==
--- lldb/trunk/source/Commands/CommandObjectSettings.cpp (original)
+++ lldb/trunk/source/Commands/CommandObjectSettings.cpp Fri Sep  6 01:40:31 
2019
@@ -205,16 +205,13 @@ protected:
 }
 
 // Split the raw command into var_name and value pair.
-llvm::StringRef raw_str(command);
-std::string var_value_string = raw_str.split(var_name).second.str();
-const char *var_value_cstr =
-Args::StripSpaces(var_value_string, true, false, false);
+llvm::StringRef var_value(command);
+var_value = var_value.split(var_name).second.ltrim();
 
 Status error;
-if (m_options.m_global) {
+if (m_options.m_global)
   error = GetDebugger().SetPropertyValue(nullptr, eVarSetOperationAssign,
- var_name, var_value_cstr);
-}
+ var_name, var_value);
 
 if (error.Success()) {
   // FIXME this is the same issue as the one in commands script import
@@ -225,7 +222,7 @@ protected:
   ExecutionContext exe_ctx(m_exe_ctx);
   m_exe_ctx.Clear();
   error = GetDebugger().SetPropertyValue(&exe_ctx, eVarSetOperationAssign,
- var_name, var_value_cstr);
+ var_name, var_value);
 }
 
 if (error.Fail()) {
@@ -646,13 +643,11 @@ protected:
 }
 
 // Split the raw command into var_name and value pair.
-llvm::StringRef raw_str(command);
-std::string var_value_string = raw_str.split(var_name).second.str();
-const char *var_value_cstr =
-Args::StripSpaces(var_value_string, true, true, false);
+llvm::StringRef var_value(command);
+var_value = var_value.split(var_name).second.trim();
 
 Status error(GetDebugger().SetPropertyValue(
-&m_exe_ctx, eVarSetOperationRemove, var_name, var_value_cstr));
+&m_exe_ctx, eVarSetOperationRemove, var_name, var_value));
 if (error.Fail()) {
   result.AppendError(error.AsCString());
   result.SetStatus(eReturnStatusFailed);
@@ -744,13 +739,11 @@ protected:
 }
 
 // Split the raw command into var_name, index_value, and value triple.
-llvm::StringRef raw_str(command);
-std::string var_value_string = raw_str.split(var_name).second.str();
-const char *var_value_cstr =
-Args::StripSpaces(var_value_string, true, true, false);
+llvm::StringRef var_value(command);
+var_value = var_value.split(var_name).second.trim();
 
 Status error(GetDebugger().SetPropertyValue(
-&m_exe_ctx, eVarSetOperationReplace, var_name, var_value_cstr));
+&m_exe_ctx, eVarSetOperationReplace, var_name, var_value));
 if (error.Fail()) {
   result.AppendError(error.AsCString());
   result.SetStatus(eReturnStatusFailed);
@@ -848,13 +841,11 @@ protected:
 }
 
 // Split the raw command into var_name, index_value, and value triple.
-llvm::StringRef raw_str(command);
-std::string var_value_string = raw_str.split(var_name).second.str();
-const char *var_value_cstr =
-Args::StripSpaces(var_value_string, true, true, false);
+llvm::StringRef var_value(command);
+var_value = var_value.split(var_name).second.trim();
 
 Status error(GetDebugger().SetPropertyValue(
-&m_exe_ctx, eVarSetOperationInsertBefore, var_name, var_value_cstr));
+&m_exe_ctx, eVarSetOperationInsertBefore, var_name, var_value));
 if (error.Fail()) 

[Lldb-commits] [PATCH] D67230: Remove call to obsolete gethostbyname, using getaddrinfo

2019-09-06 Thread Pavel Labath via Phabricator via lldb-commits
labath accepted this revision.
labath added a comment.
This revision is now accepted and ready to land.

Sounds like a good idea, particularly as gethostbyname is not thread safe. It 
seems getaddrinfo is already used in lldb, so it should be supported by all OSs 
that we care about.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67230



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


[Lldb-commits] [PATCH] D66791: [lldb][ELF] Read symbols from .gnu_debugdata sect.

2019-09-06 Thread Pavel Labath via Phabricator via lldb-commits
labath added a comment.

Thank you for adding the tests, and for adding the `xz` detection to lit in 
particular. We're getting _reaally_ close now. I have a bunch more comments, 
including highlighting some you seems to have missed from earlier, but they are 
all just about polishing. The only somewhat larger comment is about the 
`minidebuginfo-set-and-hit-breakpoint.test` test. I'd like to understand what 
exactly is the scenario you are intending to test there, because I have a 
feeling it's not testing what you want it to test...




Comment at: lldb/CMakeLists.txt:101
 
-  set(LLDB_TEST_DEPS lldb)
+  set(LLDB_TEST_DEPS lldb llvm-nm llvm-strip)
 

labath wrote:
> It looks like you're already adding these in `lldb/lit/CMakeLists.txt`. Does 
> it need to be in both?
What about this?



Comment at: lldb/include/lldb/Host/LZMA.h:24-25
+
+llvm::Error getUncompressedSize(llvm::ArrayRef InputBuffer,
+uint64_t &uncompressedSize);
+

labath wrote:
> Now that the vector is auto-resized, do you think it's still useful to expose 
> the `getUncompressedSize` function as public api? If yes, then please change 
> it to return Expected. (returning Expected would be nice even for a 
> private api, but there it's less important...)
What about this?



Comment at: lldb/lit/Breakpoint/minidebuginfo-corrupt-xz.yaml:1
+# REQUIRES: system-linux, lzma
+

These tests should go to `lit/Modules/ELF`, as they have nothing to do with 
breakpoints, and everything to do with ELF files. The 
`minidebuginfo-set-and-hit-breakpoint.test` might stay here as it actually does 
deal with breakpoints, but it would also make sense to put it next to the ELF 
tests. I'll leave it up to you to decide where to place that one.



Comment at: lldb/lit/Breakpoint/minidebuginfo-corrupt-xz.yaml:13
+
+# RUN: %lldb -x -b -o 'image dump symtab' %t.obj 2>&1 | FileCheck %s
+

You shouldn't need an explicit `-x` in these tests as %lldb adds 
`--no-use-colors` already.



Comment at: lldb/lit/Breakpoint/minidebuginfo-find-symbols.yaml:15
+  Entry:   0x004004C0
+Sections:
+  - Name:.gnu_debugdata

Could you add a symbol or two to the dynsym section of the outer file? I'd like 
to test that we get symbols from .dynsym *and* .symtab sections.



Comment at: lldb/lit/Breakpoint/minidebuginfo-no-lzma.yaml:22
+AddressAlign:0x0001
+Content: 
FD377A585A04E6D6B446020021011600742FE5A3E0180F05BA5D003F914584683D89A6DA8ACC93E24ED90802EC1FE2A7102958F4A42B6A7134F23922F6F35F529E133A8B5588025CFAC876C68510A157DBBCF8CA75E9854DED10FDD5CE0CDC136F6459B13B9847AEF79E9B1C7CD70EF4F3AF709F5DA0C1F40780154D72120A6A62A3F1A216E20DC597CE55BB23B48785957321A15FEE48808C1428B925DBC8022541CC594BD0AF2B51C6BE2854C81611017704DF6E509D21013B80BEC27D8919ACD3157E89353A08F4C86781ED708E89AB322D010F0F1605DAD9B9CE2B13C387769C83F5F85C647FD9C551E0E9C7D4A5CBE297970E486CB94AC283F98A7C6412A57F9C37952327549EEC4634D2CFA55B0F99923A14992D4293E0D87CEEF7FB6160C45928DE25074EEBF5329B5579AF01DB23DF22CBD48C8037B68FFFBE5CEA6CD26A936DD07D9B2E6006B7C6E5CC751072185EFE995D3F3C8DACF9039D4BEFB1F376B491568F6F00DB50FF477F36B90413E4FA30AE7C561A1249FD45FDFF884F70247FC21E57195A764151D8E341267E724D856C512BD243CDB33AB313758443877B2CB58F7F8F0461DE9766647F333A3531BDC4A26E9537EB314708D31212FCF4C21E9CB139F4DBFD21BB16A126C35E2BB3F7E30BF5A54961CECD4DD4D91A3757356F618754B21533C34F2BD97D70A02B1F338588BDBA9CDF5FC9FBE973E550194F07EC7A1E8E3C005FD60F8853223427628987E82E701CA7E2FDFA1B0ED564C37D115A72C3EC01E29C85C3630D8A385C4AE12F4F75F9F0BC12F2698345DD62A1F546A5953AF5CF3C0F22C7DA510F6739EB8CDB0E8A5A3BC13CFC31C1875C313908EFF23678869B76A6E1C10FE699E43BFFDE8F0752ED994A4A84BC0AD9D7381131D457C4917C4F6656F5C95D3221A79166C802D5F5A7C68554E54C42CA535465D224C7B641CF3417C3EAFD03CE5709BEA33DC7C9155CAC9D3C8033AF7CDA622020606A7C139D77FF85BC19323BF956C9C4662F60079BC7FE5F67B46211716A1A6CE4AB8AAB307D6444310CBC101071703EECC0B4622D91D705F5DA2932DA8BCEDA8E1CB0CDB20AAD652B8F86A521D3421287F1C175AE3BE6458AE6F8F3FB6FB7ED97B616B580D791E5FE0B74973F8604F419039B5B9D9A14397EE509F2B33AE404FF96DD0551472C5302E67910F0794B15CFE837351C6AF89B2FE88488B557BE8ACFFA331FB7AD553D35CAEB7D8BCEFB6CFF4A58E91355FE931408CF4CAFA9B97518B9E5C02078F64CE81279801B090348213DCAA7D12DC098BFF58C5A3202EFC38F64AD894379747B54AB5A9843F82E5FF1F394C8B783C3A8F1655DDEF8D5FE09EBB3E703853ABD716743507000696FB6B35216B088E499F53880375521442ED45DCDD1B31AAEBDAD3C7DA958593425206C4B2A0BC6CADE3B0B1598499E08016E84F33E3EB9D7B03B9C9DFA91B8CE5C74DEF2BC97FEE9982B0AEC16C75EEB7AE9A858A9C37F6C12B040C68A49111DCF0F3A4780F3879E93D904676BE908FDC66373D34AA715A39EFBC2795C6C8F058CA24392FB2591AD06ACD6AED8746F926886180C2B007ED58C9884A8BEF6CCA1F549F5C4FB411A3FF78770D1147363AC80B98B5A8FDB3DEC4E61709F66A622BDA835B1FD67B7C7CB166ABB163FB7C5204AE200C71C6A18B532C407647323B8

[Lldb-commits] [PATCH] D67227: [lldb] Extend and document TestIRInterpreter.py

2019-09-06 Thread Raphael Isemann via Phabricator via lldb-commits
teemperor updated this revision to Diff 219059.
teemperor added a comment.

- Relaxed can_handle_operands that it allows shifting unsigned large values 
(produced by initialising them with negative signed values).
- Now checking for 32bit instead of 7 (thanks Shafik!)


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

https://reviews.llvm.org/D67227

Files:
  
lldb/packages/Python/lldbsuite/test/commands/expression/ir-interpreter/TestIRInterpreter.py

Index: lldb/packages/Python/lldbsuite/test/commands/expression/ir-interpreter/TestIRInterpreter.py
===
--- lldb/packages/Python/lldbsuite/test/commands/expression/ir-interpreter/TestIRInterpreter.py
+++ lldb/packages/Python/lldbsuite/test/commands/expression/ir-interpreter/TestIRInterpreter.py
@@ -40,6 +40,29 @@
 
 self.runCmd("run", RUN_SUCCEEDED)
 
+class Variable:
+def __init__(self, uid, type, value):
+self.name = "$i_" + str(uid) + "_" + type.replace(" ", "_")
+self.value = value
+self.type = type
+self.decl_expr = type + " " + self.name + " = " + str(self.value)
+self.unsigned_type = "unsigned" in type
+
+class Operator:
+def __init__(self, name):
+   self.name = name
+
+def can_handle_operands(self, lhs, rhs):
+"""True iff this operator can handle the variables as operands."""
+if self.name in ['<<', '>>']:
+# Shifting negative values, shifting by negative values and
+# shifting by too large values will make this test fail.
+if lhs.value <= 0 and not lhs.unsigned_type:
+return False
+if rhs.value <= 0 or rhs.value >= 32:
+return False
+return True
+
 @add_test_categories(['pyapi'])
 # getpid() is POSIX, among other problems, see bug
 @expectedFailureAll(
@@ -50,35 +73,73 @@
 oslist=['linux'],
 archs=['arm'],
 bugnumber="llvm.org/pr27868")
-def test_ir_interpreter(self):
+def test_ir_interpreter_int_ops(self):
 self.build_and_run()
 
+# Normal expression options we use for JITed expressions.
 options = lldb.SBExpressionOptions()
 options.SetLanguage(lldb.eLanguageTypeC_plus_plus)
 
-set_up_expressions = ["int $i = 9", "int $j = 3", "int $k = 5"]
-
-expressions = ["$i + $j",
-   "$i - $j",
-   "$i * $j",
-   "$i / $j",
-   "$i % $k",
-   "$i << $j",
-   "$i & $j",
-   "$i | $j",
-   "$i ^ $j"]
-
-for expression in set_up_expressions:
-self.frame().EvaluateExpression(expression, options)
-
-for expression in expressions:
+# Expression options that prevent that we use the JIT.
+nojit_options = lldb.SBExpressionOptions()
+nojit_options.SetLanguage(lldb.eLanguageTypeC_plus_plus)
+nojit_options.SetAllowJIT(False)
+
+# List of operators the interpreter supports and we want to test.
+operators = ['+', '-', '*', '%', '/',
+ '<<', '>>', '&', '|', '^',
+ '>', '<', '>=', '<=', '!=', '==']
+operator_list = []
+for opname in operators:
+operator_list.append(self.Operator(opname))
+
+# Variable types that should be tested with the operators.
+types_to_test = ['int', 'unsigned int']
+
+# Values these variables can have.
+values_to_test = [255, 256, -1, 0, 1, 255, 256]
+
+# Id for every variable to give them unique names.
+uid = 0
+# Define a variable for every type and for every value in LLDB.
+variable_list = []
+for t in types_to_test:
+for value in values_to_test:
+v = self.Variable(uid, t, value)
+variable_list.append(v)
+interp_result = self.frame().EvaluateExpression(
+v.decl_expr, nojit_options).GetValueAsUnsigned()
+uid += 1
+
+# Create a list of expressions that use every operator.
+exprs_to_run = []
+for op in operator_list:
+# Try all combinations of variables with the operator.
+for var1 in variable_list:
+for var2 in variable_list:
+if not op.can_handle_operands(var1, var2):
+continue
+# Create an expression using the operator.
+expr = var1.name + " " + op.name + " " + var2.name
+# Resolve the variable values and add that as a comment
+# to the expression. This will be shown when the test fails.
+expr += " // " + str(var1.value) + " " + op.name + " " + str(var2.value)
+   

[Lldb-commits] [PATCH] D67230: Remove call to obsolete gethostbyname, using getaddrinfo

2019-09-06 Thread Phabricator via Phabricator via lldb-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL371195: Remove call to obsolete gethostbyname, using 
getaddrinfo (authored by serge_sans_paille, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D67230?vs=218940&id=219060#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D67230

Files:
  lldb/trunk/source/Host/posix/HostInfoPosix.cpp


Index: lldb/trunk/source/Host/posix/HostInfoPosix.cpp
===
--- lldb/trunk/source/Host/posix/HostInfoPosix.cpp
+++ lldb/trunk/source/Host/posix/HostInfoPosix.cpp
@@ -32,10 +32,16 @@
   char hostname[PATH_MAX];
   hostname[sizeof(hostname) - 1] = '\0';
   if (::gethostname(hostname, sizeof(hostname) - 1) == 0) {
-struct hostent *h = ::gethostbyname(hostname);
-if (h)
-  s.assign(h->h_name);
-else
+struct addrinfo hints;
+struct addrinfo *res = nullptr;
+std::memset(&hints, 0, sizeof(hints));
+hints.ai_flags = AI_CANONNAME;
+int err = ::getaddrinfo(hostname, nullptr, &hints, &res);
+if (err == 0) {
+  assert(res->ai_canonname && "getaddrinfo found a canonical name");
+  s.assign(res->ai_canonname);
+  freeaddrinfo(res);
+} else
   s.assign(hostname);
 return true;
   }


Index: lldb/trunk/source/Host/posix/HostInfoPosix.cpp
===
--- lldb/trunk/source/Host/posix/HostInfoPosix.cpp
+++ lldb/trunk/source/Host/posix/HostInfoPosix.cpp
@@ -32,10 +32,16 @@
   char hostname[PATH_MAX];
   hostname[sizeof(hostname) - 1] = '\0';
   if (::gethostname(hostname, sizeof(hostname) - 1) == 0) {
-struct hostent *h = ::gethostbyname(hostname);
-if (h)
-  s.assign(h->h_name);
-else
+struct addrinfo hints;
+struct addrinfo *res = nullptr;
+std::memset(&hints, 0, sizeof(hints));
+hints.ai_flags = AI_CANONNAME;
+int err = ::getaddrinfo(hostname, nullptr, &hints, &res);
+if (err == 0) {
+  assert(res->ai_canonname && "getaddrinfo found a canonical name");
+  s.assign(res->ai_canonname);
+  freeaddrinfo(res);
+} else
   s.assign(hostname);
 return true;
   }
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [PATCH] D66638: Unwind: Add a stack scanning mechanism to support win32 unwinding

2019-09-06 Thread Pavel Labath via Phabricator via lldb-commits
labath added a comment.

Thanks for the quick reply. My responses are inline:

In D66638#1659866 , @amccarth wrote:

> I don't have any specific code comments, but I do have a couple general 
> questions and points to consider.
>
> 1. `isFoundHeuristically` is very generic.  It's true that it's a heuristic 
> approach, but it's a very specific heuristic.  Might there be other heuristic 
> approaches in the future?  Should we name it something more specific like 
> `isRaSearch`?


I wanted to avoid a specific name, because I though this approach might be 
useful elsewhere too. For instance, I can imagine doing the same kind of search 
as some sort of a last ditch attempt when we lack *any* kind of unwind 
information. However, thinking about it now, when I ignore the fact that the 
pdb construct is called rasearch, the name still pretty well describes what 
this "heuristic" does, so it is probably better to name it that way.

> 
> 
> 2. `max_iterations` means how many stack positions the heuristic will scan 
> before giving up, right?  Are there any alignment issues here?  Should we 
> assert that the return address hint is a multiple of the stack alignment?

I don't believe we're doing anything like that elsewhere in the unwinder, and 
x86 is pretty forgiving about memory access alignment, so if through some 
mishap, the function does end up with a misaligned stack, there is actually a 
good chance it would still work, and so we should be able to unwind from it.

> 
> 
> 3. The 100 for `max_iterations` is probably fine, but I wonder if there's a 
> way to determine a more specific limit without just guessing.  What things 
> could be on the stack between the hint and the actual return address?  It 
> seems like only arguments for a call that the current function is preparing 
> to make.  The standard says that the actual number of parameters is 
> implementation-defined, but that it suggests a minimum of 256.  Should 
> `max_iterations` be 256?  Is there much risk in making it bigger than it 
> needs to be?

I don't think there's much risk in making this bigger. If everything goes 
according to plan, then we should get the return address only after a couple of 
iterations (most likely 1). Even if something goes wrong, then we will probably 
still return before completing all iterations, except that will find the return 
address a couple of frames higher (which is probably still better than giving 
no return address at all). So yeah, if the standard (which standard is that? 
C?) says 256, then that's probably the best number we can go with.

It's hard to say what can be on the stack except the function arguments. In 
theory it can be anything. The compiler could push any number of intermediate 
values to stash some temporary values. However, current compilers tend to avoid 
that, and instead prefer to allocate the maximum number of stack slots in the 
prologue.

That said, this made me realize that the win32 unwind format does allow one to 
express that the amount of stack taken up by the temporaries will be different 
at different points within the function. However, the API I am introducing here 
do not. It would probably be better to pass in an address in this case, so that 
one can return different values for different points within the function.

> 4. Is checking for executable permission slow?  Would it be worth doing some 
> culling or caching?  I imagine a lot of non-return address values on the 
> stack will be simple small numbers, like 0 or 1, which, for Windows, would 
> never be a valid executable address.

The check should be pretty fast. The way it's implemented now, it only consults 
lldb's view of the process, which is all readily available (the loaded sections 
are in the target's section load list, and the executable bit is in the section 
object). I have considered going through the "memory region info" 
infrastructure, which consults the OS to get a list of mapped pages. That would 
be a bit slower (though this information is also cached), but it would have the 
advantage of detecting executable code which does not belong to any (known) 
module. It wasn't clear to me whether that is worth the trouble though..


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D66638



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


[Lldb-commits] [PATCH] D66791: [lldb][ELF] Read symbols from .gnu_debugdata sect.

2019-09-06 Thread Pavel Labath via Phabricator via lldb-commits
labath marked an inline comment as done.
labath added inline comments.



Comment at: lldb/lit/Breakpoint/minidebuginfo-corrupt-xz.yaml:13
+
+# RUN: %lldb -x -b -o 'image dump symtab' %t.obj 2>&1 | FileCheck %s
+

labath wrote:
> You shouldn't need an explicit `-x` in these tests as %lldb adds 
> `--no-use-colors` already.
Actually, I take this back. It seems %lldb does not pass this automatically. I 
am not sure why, but since colors aren't a problem you here, you probably don't 
have to explicitly disable them anyway...


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D66791



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


[Lldb-commits] [PATCH] D66791: [lldb][ELF] Read symbols from .gnu_debugdata sect.

2019-09-06 Thread Konrad Wilhelm Kleine via Phabricator via lldb-commits
kwk added a comment.

I've tackled the easy comments now and will come back to the more detailed ones 
as well.  I'm not ignoring them.




Comment at: lldb/CMakeLists.txt:101
 
-  set(LLDB_TEST_DEPS lldb)
+  set(LLDB_TEST_DEPS lldb llvm-nm llvm-strip)
 

labath wrote:
> labath wrote:
> > It looks like you're already adding these in `lldb/lit/CMakeLists.txt`. 
> > Does it need to be in both?
> What about this?
You're right. one place is enough. 



Comment at: lldb/include/lldb/Host/LZMA.h:24-25
+
+llvm::Error getUncompressedSize(llvm::ArrayRef InputBuffer,
+uint64_t &uncompressedSize);
+

labath wrote:
> labath wrote:
> > Now that the vector is auto-resized, do you think it's still useful to 
> > expose the `getUncompressedSize` function as public api? If yes, then 
> > please change it to return Expected. (returning Expected would be 
> > nice even for a private api, but there it's less important...)
> What about this?
I've changed the syntax as you suggested. I kept the function there because I 
find it easier to maintain this way.



Comment at: lldb/lit/Breakpoint/minidebuginfo-corrupt-xz.yaml:1
+# REQUIRES: system-linux, lzma
+

labath wrote:
> These tests should go to `lit/Modules/ELF`, as they have nothing to do with 
> breakpoints, and everything to do with ELF files. The 
> `minidebuginfo-set-and-hit-breakpoint.test` might stay here as it actually 
> does deal with breakpoints, but it would also make sense to put it next to 
> the ELF tests. I'll leave it up to you to decide where to place that one.
I've move all to `lit/Modules/ELF`.



Comment at: lldb/lit/Breakpoint/minidebuginfo-corrupt-xz.yaml:13
+
+# RUN: %lldb -x -b -o 'image dump symtab' %t.obj 2>&1 | FileCheck %s
+

labath wrote:
> You shouldn't need an explicit `-x` in these tests as %lldb adds 
> `--no-use-colors` already.
I use `-x` and not `-X`. See `lldb --help`:

`-x   Alias for --no-lldbinit`
`-XAlias for --no-use-color`



Comment at: lldb/lit/Breakpoint/minidebuginfo-no-lzma.yaml:22
+AddressAlign:0x0001
+Content: 
FD377A585A04E6D6B446020021011600742FE5A3E0180F05BA5D003F914584683D89A6DA8ACC93E24ED90802EC1FE2A7102958F4A42B6A7134F23922F6F35F529E133A8B5588025CFAC876C68510A157DBBCF8CA75E9854DED10FDD5CE0CDC136F6459B13B9847AEF79E9B1C7CD70EF4F3AF709F5DA0C1F40780154D72120A6A62A3F1A216E20DC597CE55BB23B48785957321A15FEE48808C1428B925DBC8022541CC594BD0AF2B51C6BE2854C81611017704DF6E509D21013B80BEC27D8919ACD3157E89353A08F4C86781ED708E89AB322D010F0F1605DAD9B9CE2B13C387769C83F5F85C647FD9C551E0E9C7D4A5CBE297970E486CB94AC283F98A7C6412A57F9C37952327549EEC4634D2CFA55B0F99923A14992D4293E0D87CEEF7FB6160C45928DE25074EEBF5329B5579AF01DB23DF22CBD48C8037B68FFFBE5CEA6CD26A936DD07D9B2E6006B7C6E5CC751072185EFE995D3F3C8DACF9039D4BEFB1F376B491568F6F00DB50FF477F36B90413E4FA30AE7C561A1249FD45FDFF884F70247FC21E57195A764151D8E341267E724D856C512BD243CDB33AB313758443877B2CB58F7F8F0461DE9766647F333A3531BDC4A26E9537EB314708D31212FCF4C21E9CB139F4DBFD21BB16A126C35E2BB3F7E30BF5A54961CECD4DD4D91A3757356F618754B21533C34F2BD97D70A02B1F338588BDBA9CDF5FC9FBE973E550194F07EC7A1E8E3C005FD60F8853223427628987E82E701CA7E2FDFA1B0ED564C37D115A72C3EC01E29C85C3630D8A385C4AE12F4F75F9F0BC12F2698345DD62A1F546A5953AF5CF3C0F22C7DA510F6739EB8CDB0E8A5A3BC13CFC31C1875C313908EFF23678869B76A6E1C10FE699E43BFFDE8F0752ED994A4A84BC0AD9D7381131D457C4917C4F6656F5C95D3221A79166C802D5F5A7C68554E54C42CA535465D224C7B641CF3417C3EAFD03CE5709BEA33DC7C9155CAC9D3C8033AF7CDA622020606A7C139D77FF85BC19323BF956C9C4662F60079BC7FE5F67B46211716A1A6CE4AB8AAB307D6444310CBC101071703EECC0B4622D91D705F5DA2932DA8BCEDA8E1CB0CDB20AAD652B8F86A521D3421287F1C175AE3BE6458AE6F8F3FB6FB7ED97B616B580D791E5FE0B74973F8604F419039B5B9D9A14397EE509F2B33AE404FF96DD0551472C5302E67910F0794B15CFE837351C6AF89B2FE88488B557BE8ACFFA331FB7AD553D35CAEB7D8BCEFB6CFF4A58E91355FE931408CF4CAFA9B97518B9E5C02078F64CE81279801B090348213DCAA7D12DC098BFF58C5A3202EFC38F64AD894379747B54AB5A9843F82E5FF1F394C8B783C3A8F1655DDEF8D5FE09EBB3E703853ABD716743507000696FB6B35216B088E499F53880375521442ED45DCDD1B31AAEBDAD3C7DA958593425206C4B2A0BC6CADE3B0B1598499E08016E84F33E3EB9D7B03B9C9DFA91B8CE5C74DEF2BC97FEE9982B0AEC16C75EEB7AE9A858A9C37F6C12B040C68A49111DCF0F3A4780F3879E93D904676BE908FDC66373D34AA715A39EFBC2795C6C8F058CA24392FB2591AD06ACD6AED8746F926886180C2B007ED58C9884A8BEF6CCA1F549F5C4FB411A3FF78770D1147363AC80B98B5A8FDB3DEC4E61709F66A622BDA835B1FD67B7C7CB166ABB163FB7C5204AE200C71C6A18B532C407647323B8F2FAC7ECB68C250877FC8DD5FE05B2B39E66F687EBB6EEFB7D5209E22F451B76F57D90BB6641DFFDE1A1821C4D783E4756F3CEE7F63B9BA284F8E114B0D9A086D83233BED4A8F5B60933DC16AF4DDE19C9FC59BCC1646343ECE7007B1C4DC65C4A939CDD47F6ED8855913183149BECE66D8FE7793AE607EB8E28513749B9548252764110D3B58D1D8B348DB18F7F24F8CA0C7D9CB515D90F7F1848FF58472B2EF5

[Lldb-commits] [PATCH] D66791: [lldb][ELF] Read symbols from .gnu_debugdata sect.

2019-09-06 Thread Konrad Wilhelm Kleine via Phabricator via lldb-commits
kwk updated this revision to Diff 219064.
kwk marked 16 inline comments as done.
kwk added a comment.

- Removed not needed test dependencies
- Changed return type of lzma::getUncompressedSize
- Moved minidebuginfo to subtree that deals with ELF
- Apply review comments


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D66791

Files:
  lldb/cmake/modules/LLDBConfig.cmake
  lldb/include/lldb/Host/Config.h.cmake
  lldb/include/lldb/Host/LZMA.h
  lldb/lit/CMakeLists.txt
  lldb/lit/Modules/ELF/Inputs/minidebuginfo-lib.c
  lldb/lit/Modules/ELF/Inputs/minidebuginfo-lib.h
  lldb/lit/Modules/ELF/Inputs/minidebuginfo-main.c
  lldb/lit/Modules/ELF/Inputs/minidebuginfo.keep_symbols
  lldb/lit/Modules/ELF/minidebuginfo-corrupt-xz.yaml
  lldb/lit/Modules/ELF/minidebuginfo-find-symbols.yaml
  lldb/lit/Modules/ELF/minidebuginfo-no-lzma.yaml
  lldb/lit/Modules/ELF/minidebuginfo-set-and-hit-breakpoint.test
  lldb/lit/lit.cfg.py
  lldb/lit/lit.site.cfg.py.in
  lldb/source/Host/CMakeLists.txt
  lldb/source/Host/common/LZMA.cpp
  lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
  lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.h

Index: lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.h
===
--- lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.h
+++ lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.h
@@ -208,6 +208,10 @@
   /// Collection of symbols from the dynamic table.
   DynamicSymbolColl m_dynamic_symbols;
 
+  /// Object file parsed from .gnu_debugdata section (\sa
+  /// GetGnuDebugDataObjectFile())
+  std::shared_ptr m_gnu_debug_data_object_file;
+
   /// List of file specifications corresponding to the modules (shared
   /// libraries) on which this object file depends.
   mutable std::unique_ptr m_filespec_up;
@@ -383,6 +387,14 @@
   lldb_private::UUID &uuid);
 
   bool AnySegmentHasPhysicalAddress();
+  
+  /// Takes the .gnu_debugdata and returns the decompressed object file that is
+  /// stored within that section.
+  ///
+  /// \returns either the decompressed object file stored within the
+  /// .gnu_debugdata section or \c nullptr if an error occured or if there's no
+  /// section with that name.
+  std::shared_ptr GetGnuDebugDataObjectFile();
 };
 
 #endif // liblldb_ObjectFileELF_h_
Index: lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
===
--- lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
+++ lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
@@ -18,6 +18,7 @@
 #include "lldb/Core/PluginManager.h"
 #include "lldb/Core/Section.h"
 #include "lldb/Host/FileSystem.h"
+#include "lldb/Host/LZMA.h"
 #include "lldb/Symbol/DWARFCallFrameInfo.h"
 #include "lldb/Symbol/SymbolContext.h"
 #include "lldb/Target/SectionLoadList.h"
@@ -1842,6 +1843,70 @@
   // unified section list.
   if (GetType() != eTypeDebugInfo)
 unified_section_list = *m_sections_up;
+  
+  // If there's a .gnu_debugdata section, we'll try to read the .symtab that's
+  // embedded in there and replace the one in the original object file (if any).
+  // If there's none in the orignal object file, we add it to it.
+  if (auto gdd_obj_file = GetGnuDebugDataObjectFile()) {
+if (auto gdd_objfile_section_list = gdd_obj_file->GetSectionList()) {
+  if (SectionSP symtab_section_sp =
+  gdd_objfile_section_list->FindSectionByType(
+  eSectionTypeELFSymbolTable, true)) {
+SectionSP module_section_sp = unified_section_list.FindSectionByType(
+eSectionTypeELFSymbolTable, true);
+if (module_section_sp)
+  unified_section_list.ReplaceSection(module_section_sp->GetID(),
+  symtab_section_sp);
+else
+  unified_section_list.AddSection(symtab_section_sp);
+  }
+}
+  }  
+}
+
+std::shared_ptr ObjectFileELF::GetGnuDebugDataObjectFile() {
+  if (m_gnu_debug_data_object_file != nullptr)
+return m_gnu_debug_data_object_file;
+
+  SectionSP section =
+  GetSectionList()->FindSectionByName(ConstString(".gnu_debugdata"));
+  if (!section)
+return nullptr;
+
+  if (!lldb_private::lzma::isAvailable()) {
+GetModule()->ReportWarning(
+"No LZMA support found for reading .gnu_debugdata section");
+return nullptr;
+  }
+
+  // Uncompress the data
+  DataExtractor data;
+  section->GetSectionData(data);
+  llvm::SmallVector uncompressedData;
+  auto err = lldb_private::lzma::uncompress(data.GetData(), uncompressedData);
+  if (err) {
+GetModule()->ReportWarning(
+"An error occurred while decompression the section %s: %s",
+section->GetName().AsCString(), llvm::toString(std::move(err)).c_str());
+return nullptr;
+  }
+
+  // Construct ObjectFileELF object from decompressed buffer
+  DataBufferSP gdd_data_buf(
+  new DataBufferHeap(uncom

[Lldb-commits] [PATCH] D66791: [lldb][ELF] Read symbols from .gnu_debugdata sect.

2019-09-06 Thread Pavel Labath via Phabricator via lldb-commits
labath marked an inline comment as done.
labath added inline comments.



Comment at: lldb/include/lldb/Host/LZMA.h:24-25
+
+llvm::Error getUncompressedSize(llvm::ArrayRef InputBuffer,
+uint64_t &uncompressedSize);
+

kwk wrote:
> labath wrote:
> > labath wrote:
> > > Now that the vector is auto-resized, do you think it's still useful to 
> > > expose the `getUncompressedSize` function as public api? If yes, then 
> > > please change it to return Expected. (returning Expected would 
> > > be nice even for a private api, but there it's less important...)
> > What about this?
> I've changed the syntax as you suggested. I kept the function there because I 
> find it easier to maintain this way.
Ok. I am fine with that.



Comment at: lldb/lit/Breakpoint/minidebuginfo-corrupt-xz.yaml:13
+
+# RUN: %lldb -x -b -o 'image dump symtab' %t.obj 2>&1 | FileCheck %s
+

labath wrote:
> kwk wrote:
> > labath wrote:
> > > You shouldn't need an explicit `-x` in these tests as %lldb adds 
> > > `--no-use-colors` already.
> > I use `-x` and not `-X`. See `lldb --help`:
> > 
> > `-x   Alias for --no-lldbinit`
> > `-XAlias for --no-use-color`
> Actually, I take this back. It seems %lldb does not pass this automatically. 
> I am not sure why, but since colors aren't a problem you here, you probably 
> don't have to explicitly disable them anyway...
Ah, my bad. In that case you definitely *can* remove it because %lldb does add 
`--no-lldbinit`.



Comment at: lldb/lit/Breakpoint/minidebuginfo-no-lzma.yaml:22
+AddressAlign:0x0001
+Content: 
FD377A585A04E6D6B446020021011600742FE5A3E0180F05BA5D003F914584683D89A6DA8ACC93E24ED90802EC1FE2A7102958F4A42B6A7134F23922F6F35F529E133A8B5588025CFAC876C68510A157DBBCF8CA75E9854DED10FDD5CE0CDC136F6459B13B9847AEF79E9B1C7CD70EF4F3AF709F5DA0C1F40780154D72120A6A62A3F1A216E20DC597CE55BB23B48785957321A15FEE48808C1428B925DBC8022541CC594BD0AF2B51C6BE2854C81611017704DF6E509D21013B80BEC27D8919ACD3157E89353A08F4C86781ED708E89AB322D010F0F1605DAD9B9CE2B13C387769C83F5F85C647FD9C551E0E9C7D4A5CBE297970E486CB94AC283F98A7C6412A57F9C37952327549EEC4634D2CFA55B0F99923A14992D4293E0D87CEEF7FB6160C45928DE25074EEBF5329B5579AF01DB23DF22CBD48C8037B68FFFBE5CEA6CD26A936DD07D9B2E6006B7C6E5CC751072185EFE995D3F3C8DACF9039D4BEFB1F376B491568F6F00DB50FF477F36B90413E4FA30AE7C561A1249FD45FDFF884F70247FC21E57195A764151D8E341267E724D856C512BD243CDB33AB313758443877B2CB58F7F8F0461DE9766647F333A3531BDC4A26E9537EB314708D31212FCF4C21E9CB139F4DBFD21BB16A126C35E2BB3F7E30BF5A54961CECD4DD4D91A3757356F618754B21533C34F2BD97D70A02B1F338588BDBA9CDF5FC9FBE973E550194F07EC7A1E8E3C005FD60F8853223427628987E82E701CA7E2FDFA1B0ED564C37D115A72C3EC01E29C85C3630D8A385C4AE12F4F75F9F0BC12F2698345DD62A1F546A5953AF5CF3C0F22C7DA510F6739EB8CDB0E8A5A3BC13CFC31C1875C313908EFF23678869B76A6E1C10FE699E43BFFDE8F0752ED994A4A84BC0AD9D7381131D457C4917C4F6656F5C95D3221A79166C802D5F5A7C68554E54C42CA535465D224C7B641CF3417C3EAFD03CE5709BEA33DC7C9155CAC9D3C8033AF7CDA622020606A7C139D77FF85BC19323BF956C9C4662F60079BC7FE5F67B46211716A1A6CE4AB8AAB307D6444310CBC101071703EECC0B4622D91D705F5DA2932DA8BCEDA8E1CB0CDB20AAD652B8F86A521D3421287F1C175AE3BE6458AE6F8F3FB6FB7ED97B616B580D791E5FE0B74973F8604F419039B5B9D9A14397EE509F2B33AE404FF96DD0551472C5302E67910F0794B15CFE837351C6AF89B2FE88488B557BE8ACFFA331FB7AD553D35CAEB7D8BCEFB6CFF4A58E91355FE931408CF4CAFA9B97518B9E5C02078F64CE81279801B090348213DCAA7D12DC098BFF58C5A3202EFC38F64AD894379747B54AB5A9843F82E5FF1F394C8B783C3A8F1655DDEF8D5FE09EBB3E703853ABD716743507000696FB6B35216B088E499F53880375521442ED45DCDD1B31AAEBDAD3C7DA958593425206C4B2A0BC6CADE3B0B1598499E08016E84F33E3EB9D7B03B9C9DFA91B8CE5C74DEF2BC97FEE9982B0AEC16C75EEB7AE9A858A9C37F6C12B040C68A49111DCF0F3A4780F3879E93D904676BE908FDC66373D34AA715A39EFBC2795C6C8F058CA24392FB2591AD06ACD6AED8746F926886180C2B007ED58C9884A8BEF6CCA1F549F5C4FB411A3FF78770D1147363AC80B98B5A8FDB3DEC4E61709F66A622BDA835B1FD67B7C7CB166ABB163FB7C5204AE200C71C6A18B532C407647323B8F2FAC7ECB68C250877FC8DD5FE05B2B39E66F687EBB6EEFB7D5209E22F451B76F57D90BB6641DFFDE1A1821C4D783E4756F3CEE7F63B9BA284F8E114B0D9A086D83233BED4A8F5B60933DC16AF4DDE19C9FC59BCC1646343ECE7007B1C4DC65C4A939CDD47F6ED8855913183149BECE66D8FE7793AE607EB8E28513749B9548252764110D3B58D1D8B348DB18F7F24F8CA0C7D9CB515D90F7F1848FF58472B2EF52EBAB123AFC7F87890CE9FC55B31160014294A9B7F81638A27335E29E15A10B1068D5E049B1C239814DBBCC1BB30E11EEBAD5ACF8FB1B986C4F48D73FEA6129D9708A0B5AC435402BEC8C79C71DB94394811B9A604141A125A4669F9A139A0264E93E822117BE8E0D93A1487C51214E9FBF5763A3FBE9DA700B9C9B435472AF9F0B4446B3239307DD8B64511D60B9030CA1EC9E9B1C467FB0204595A
+...

kwk wrote:
> labath wrote:
> > Nit: You most likely don't need such a gigantic blob to test this bit of 
> > functionality, as you can't read the data anyway...
> I kept it the same for the

[Lldb-commits] [PATCH] D66638: Unwind: Add a stack scanning mechanism to support win32 unwinding

2019-09-06 Thread Pavel Labath via Phabricator via lldb-commits
labath updated this revision to Diff 219071.
labath marked an inline comment as done.
labath edited the summary of this revision.
labath added a comment.

- s/FoundHeuristically/RaSearch
- max_iterations:=256
- tweak the handling of "own frame size" instead of having the unwinder ask for 
it, it is now embedded directly into the unwind plan. This automatically makes 
it possible to have different frame sizes at different points in the function, 
and also reduces the api surface a bit. The "parameter size" is still in a 
separate function, because that belongs to a different frame/function/module.


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

https://reviews.llvm.org/D66638

Files:
  include/lldb/Symbol/SymbolFile.h
  include/lldb/Symbol/UnwindPlan.h
  lit/SymbolFile/Breakpad/Inputs/unwind-via-raSearch.syms
  lit/SymbolFile/Breakpad/unwind-via-raSearch.test
  source/Plugins/Process/Utility/RegisterContextLLDB.cpp
  source/Plugins/Process/Utility/RegisterContextLLDB.h
  source/Plugins/SymbolFile/Breakpad/SymbolFileBreakpad.cpp
  source/Plugins/SymbolFile/Breakpad/SymbolFileBreakpad.h
  source/Symbol/UnwindPlan.cpp

Index: source/Symbol/UnwindPlan.cpp
===
--- source/Symbol/UnwindPlan.cpp
+++ source/Symbol/UnwindPlan.cpp
@@ -170,7 +170,8 @@
   if (m_type == rhs.m_type) {
 switch (m_type) {
 case unspecified:
-  return true;
+case isRaSearch:
+  return m_value.ra_search_offset == rhs.m_value.ra_search_offset;
 
 case isRegisterPlusOffset:
   return m_value.reg.offset == rhs.m_value.reg.offset;
@@ -205,9 +206,12 @@
   llvm::makeArrayRef(m_value.expr.opcodes, m_value.expr.length),
   thread);
 break;
-  default:
+  case unspecified:
 s.PutCString("unspecified");
 break;
+  case isRaSearch:
+s.Printf("RaSearch@SP%+d", m_value.ra_search_offset);
+break;
   }
 }
 
Index: source/Plugins/SymbolFile/Breakpad/SymbolFileBreakpad.h
===
--- source/Plugins/SymbolFile/Breakpad/SymbolFileBreakpad.h
+++ source/Plugins/SymbolFile/Breakpad/SymbolFileBreakpad.h
@@ -135,6 +135,8 @@
 
   void AddSymbols(Symtab &symtab) override;
 
+  llvm::Expected GetParameterStackSize(Symbol &symbol) override;
+
   lldb::UnwindPlanSP
   GetUnwindPlan(const Address &address,
 const RegisterInfoResolver &resolver) override;
Index: source/Plugins/SymbolFile/Breakpad/SymbolFileBreakpad.cpp
===
--- source/Plugins/SymbolFile/Breakpad/SymbolFileBreakpad.cpp
+++ source/Plugins/SymbolFile/Breakpad/SymbolFileBreakpad.cpp
@@ -374,6 +374,20 @@
   symtab.CalculateSymbolSizes();
 }
 
+llvm::Expected
+SymbolFileBreakpad::GetParameterStackSize(Symbol &symbol) {
+  ParseUnwindData();
+  if (auto *entry = m_unwind_data->win.FindEntryThatContains(
+  symbol.GetAddress().GetFileAddress())) {
+auto record = StackWinRecord::parse(
+*LineIterator(*m_objfile_sp, Record::StackWin, entry->data));
+assert(record.hasValue());
+return record->ParameterSize;
+  }
+  return llvm::createStringError(llvm::inconvertibleErrorCode(),
+ "Parameter size unknown.");
+}
+
 static llvm::Optional>
 GetRule(llvm::StringRef &unwind_rules) {
   // Unwind rules are of the form
@@ -585,12 +599,19 @@
 
   // We assume the first value will be the CFA. It is usually called T0, but
   // clang will use T1, if it needs to realign the stack.
-  if (!postfix::ResolveSymbols(it->second, symbol_resolver)) {
-LLDB_LOG(log, "Resolving symbols in `{0}` failed.", record->ProgramString);
-return nullptr;
+  auto *symbol = llvm::dyn_cast(it->second);
+  if (symbol && symbol->GetName() == ".raSearch") {
+row_sp->GetCFAValue().SetRaSearch(record->LocalSize +
+  record->SavedRegisterSize);
+  } else {
+if (!postfix::ResolveSymbols(it->second, symbol_resolver)) {
+  LLDB_LOG(log, "Resolving symbols in `{0}` failed.",
+   record->ProgramString);
+  return nullptr;
+}
+llvm::ArrayRef saved  = SaveAsDWARF(*it->second);
+row_sp->GetCFAValue().SetIsDWARFExpression(saved.data(), saved.size());
   }
-  llvm::ArrayRef saved = SaveAsDWARF(*it->second);
-  row_sp->GetCFAValue().SetIsDWARFExpression(saved.data(), saved.size());
 
   // Replace the node value with InitialValueNode, so that subsequent
   // expressions refer to the CFA value instead of recomputing the whole
Index: source/Plugins/Process/Utility/RegisterContextLLDB.h
===
--- source/Plugins/Process/Utility/RegisterContextLLDB.h
+++ source/Plugins/Process/Utility/RegisterContextLLDB.h
@@ -201,6 +201,8 @@
   bool IsUnwindPlanValidForCurrentPC(lldb::UnwindPlanSP unwind_plan_sp,
  int &valid_pc_offset);
 
+  lldb::addr_

[Lldb-commits] [PATCH] D65677: [VirtualFileSystem] Make the RedirectingFileSystem hold on to its own working directory.

2019-09-06 Thread Pavel Labath via Phabricator via lldb-commits
labath added a comment.

Thanks Jonas. This looks fine to me, but someone who actually works on VFS (/me 
looks at @sammccall)  will need to ack that.


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

https://reviews.llvm.org/D65677



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


[Lldb-commits] [PATCH] D67230: Remove call to obsolete gethostbyname, using getaddrinfo

2019-09-06 Thread David Zarzycki via Phabricator via lldb-commits
davezarzycki added a comment.

This code is trying too hard and failing. Either the result of gethostname() is 
canonical or it is not. If it is not, then trying to canonicalize it is – for 
various reasons – a lost cause. For example, a given machine might have 
multiple network interfaces with multiple addresses per interface, each with a 
different canonical name. Separably, the result of 
`HostInfoPosix::GetHostname()` and latency thereof shouldn't depend on whether 
networking is up or down or what network the machine happened to be attached to 
at any given moment (like a laptop that travels between work and home).


Repository:
  rL LLVM

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

https://reviews.llvm.org/D67230



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


[Lldb-commits] [PATCH] D66638: Unwind: Add a stack scanning mechanism to support win32 unwinding

2019-09-06 Thread Greg Clayton via Phabricator via lldb-commits
clayborg added a comment.

So made a "sbt" command in a Python module as a way to get a backtrace when our 
backtracing fails because Android almost never makes it back to the first frame 
for any stacks. This code just grabs the current SP, looks up the memory region 
using the SP, and then it uses this as the address range (current SP back to 
the base of the stack) to scan for any pointers with an address aligned address 
that falls into executable sections. What it doesn't do, is to try and backup 
one instruction from the potential RA values to see if there is a branch to the 
current function. This avoids having to know anything about stack parameter 
sizes and just scan the stack for all executable memory region pointers, and 
then ask each architecture to backup one instruction from each proposed RA and 
see if there is a function call to the current function. For ARM this is easy: 
backup by 4 for ARM and 2 or 4 for Thumb and see if there is a branch and link. 
For x64, it would be trickier, but it might be as easy as backup up by 1 + 
address size and looking for a callq. If we can successfully do this, we could 
really improve stack backtracing for all architectures and OSs. Thoughts?


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

https://reviews.llvm.org/D66638



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


[Lldb-commits] [PATCH] D66638: Unwind: Add a stack scanning mechanism to support win32 unwinding

2019-09-06 Thread Greg Clayton via Phabricator via lldb-commits
clayborg added inline comments.



Comment at: source/Plugins/Process/Utility/RegisterContextLLDB.cpp:1875
+  if (addr.SetLoadAddress(candidate, &process.GetTarget()) &&
+  addr.GetSection()->GetPermissions() & lldb::ePermissionsExecutable) {
+address = candidate_addr;

WE should probably be using the memory region permissions using:

```
bool Process::GetLoadAddressPermissions(lldb::addr_t load_addr, uint32_t 
&permissions);
```

Why? You might have a stack going through JIT'ed code that might not have a 
section. But the memory region info will know about the permissions.



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

https://reviews.llvm.org/D66638



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


[Lldb-commits] [PATCH] D67022: Enhance SymbolFileDWARF::ParseDeclsForContext performance

2019-09-06 Thread Greg Clayton via Phabricator via lldb-commits
clayborg added a comment.

This looks like a good approach to me. Pavel?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67022



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


[Lldb-commits] [PATCH] D67022: Enhance SymbolFileDWARF::ParseDeclsForContext performance

2019-09-06 Thread Guilherme Andrade via Phabricator via lldb-commits
guiandrade added a comment.

In D67022#1660901 , @clayborg wrote:

> This looks like a good approach to me. Pavel?


Even without tests? Just to clarify my last comment, I could not find a way to 
use the command "target modules dump as" to ensure we won't have a regression 
in the future. Apparently, with or without the extra calls, that command's 
output looks the same.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67022



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


[Lldb-commits] [PATCH] D67022: Enhance SymbolFileDWARF::ParseDeclsForContext performance

2019-09-06 Thread Greg Clayton via Phabricator via lldb-commits
clayborg added a comment.

In D67022#1660945 , @guiandrade wrote:

> In D67022#1660901 , @clayborg wrote:
>
> > This looks like a good approach to me. Pavel?
>
>
> Even without tests? Just to clarify my last comment, I could not find a way 
> to use the command "target modules dump as" to ensure we won't have a 
> regression in the future. Apparently, with or without the extra calls, that 
> command's output looks the same.


I would prefer to have tests. I was just saying that the code looked good, and 
it is now time to proceed with finding a way to test.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67022



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


[Lldb-commits] [PATCH] D67022: Enhance SymbolFileDWARF::ParseDeclsForContext performance

2019-09-06 Thread Guilherme Andrade via Phabricator via lldb-commits
guiandrade added a comment.

In D67022#1660979 , @clayborg wrote:

> In D67022#1660945 , @guiandrade 
> wrote:
>
> > In D67022#1660901 , @clayborg 
> > wrote:
> >
> > > This looks like a good approach to me. Pavel?
> >
> >
> > Even without tests? Just to clarify my last comment, I could not find a way 
> > to use the command "target modules dump as" to ensure we won't have a 
> > regression in the future. Apparently, with or without the extra calls, that 
> > command's output looks the same.
>
>
> I would prefer to have tests. I was just saying that the code looked good, 
> and it is now time to proceed with finding a way to test.


Oh, got it. Thanks for the clarification.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67022



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


[Lldb-commits] [PATCH] D67230: Remove call to obsolete gethostbyname, using getaddrinfo

2019-09-06 Thread serge via Phabricator via lldb-commits
serge-sans-paille added a comment.

@davezarzycki I tend to agree with you. We can just remove 35:44 and just keep 
the hostname.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D67230



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


[Lldb-commits] [PATCH] D67227: [lldb] Extend and document TestIRInterpreter.py

2019-09-06 Thread Shafik Yaghmour via Phabricator via lldb-commits
shafik added inline comments.



Comment at: 
lldb/packages/Python/lldbsuite/test/commands/expression/ir-interpreter/TestIRInterpreter.py:48
+self.type = type
+self.decl_expr = type + " " + self.name + " = " + str(self.value)
+self.unsigned_type = "unsigned" in type

Maybe be worth noting here that for the unsigned case we are relying in the 
fact that converting an signed value to an unsigned value works as we would 
expect with twos complement numbers. 



Comment at: 
lldb/packages/Python/lldbsuite/test/commands/expression/ir-interpreter/TestIRInterpreter.py:110
+variable_list.append(v)
+interp_result = self.frame().EvaluateExpression(
+v.decl_expr, nojit_options).GetValueAsUnsigned()

You don't see to use `interp_result` here



Comment at: 
lldb/packages/Python/lldbsuite/test/commands/expression/ir-interpreter/TestIRInterpreter.py:126
+# to the expression. This will be shown when the test 
fails.
+expr += " // " + str(var1.value) + " " + op.name + " " + 
str(var2.value)
+exprs_to_run.append(expr)

In the unsigned case should we be converting the python value which is signed 
manually to an unsigned value via a mask like [it is discussed 
here](https://stackoverflow.com/q/20766813/1708801)


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

https://reviews.llvm.org/D67227



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


[Lldb-commits] [lldb] r371234 - [lldb] Small optimization of FormatMap::Delete and FormatMap::Get

2019-09-06 Thread Jan Kratochvil via lldb-commits
Author: jankratochvil
Date: Fri Sep  6 10:52:27 2019
New Revision: 371234

URL: http://llvm.org/viewvc/llvm-project?rev=371234&view=rev
Log:
[lldb] Small optimization of FormatMap::Delete and FormatMap::Get

Modified:
lldb/trunk/include/lldb/DataFormatters/FormattersContainer.h

Modified: lldb/trunk/include/lldb/DataFormatters/FormattersContainer.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/DataFormatters/FormattersContainer.h?rev=371234&r1=371233&r2=371234&view=diff
==
--- lldb/trunk/include/lldb/DataFormatters/FormattersContainer.h (original)
+++ lldb/trunk/include/lldb/DataFormatters/FormattersContainer.h Fri Sep  6 
10:52:27 2019
@@ -84,7 +84,7 @@ public:
   listener->Changed();
   }
 
-  bool Delete(KeyType name) {
+  bool Delete(const KeyType &name) {
 std::lock_guard guard(m_map_mutex);
 MapIterator iter = m_map.find(name);
 if (iter == m_map.end())
@@ -102,7 +102,7 @@ public:
   listener->Changed();
   }
 
-  bool Get(KeyType name, ValueSP &entry) {
+  bool Get(const KeyType &name, ValueSP &entry) {
 std::lock_guard guard(m_map_mutex);
 MapIterator iter = m_map.find(name);
 if (iter == m_map.end())


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


[Lldb-commits] [PATCH] D67239: [Core] Remove use of ClangASTContext in DumpDataExtractor

2019-09-06 Thread Alex Langford via Phabricator via lldb-commits
xiaobai updated this revision to Diff 219145.
xiaobai added a comment.

Refactored slightly to be a bit safer


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67239

Files:
  lldb/include/lldb/Symbol/ClangASTContext.h
  lldb/include/lldb/Symbol/TypeSystem.h
  lldb/source/Core/DumpDataExtractor.cpp
  lldb/source/Symbol/ClangASTContext.cpp

Index: lldb/source/Symbol/ClangASTContext.cpp
===
--- lldb/source/Symbol/ClangASTContext.cpp
+++ lldb/source/Symbol/ClangASTContext.cpp
@@ -4991,6 +4991,22 @@
 }
 // Exploring the type
 
+const llvm::fltSemantics &
+ClangASTContext::GetFloatTypeSemantics(size_t byte_size) {
+  if (auto *ast = getASTContext()) {
+const size_t bit_size = byte_size * 8;
+if (bit_size == ast->getTypeSize(ast->FloatTy))
+  return ast->getFloatTypeSemantics(ast->FloatTy);
+else if (bit_size == ast->getTypeSize(ast->DoubleTy))
+  return ast->getFloatTypeSemantics(ast->DoubleTy);
+else if (bit_size == ast->getTypeSize(ast->LongDoubleTy))
+  return ast->getFloatTypeSemantics(ast->LongDoubleTy);
+else if (bit_size == ast->getTypeSize(ast->HalfTy))
+  return ast->getFloatTypeSemantics(ast->HalfTy);
+  }
+  return llvm::APFloatBase::Bogus();
+}
+
 Optional
 ClangASTContext::GetBitSize(lldb::opaque_compiler_type_t type,
 ExecutionContextScope *exe_scope) {
Index: lldb/source/Core/DumpDataExtractor.cpp
===
--- lldb/source/Core/DumpDataExtractor.cpp
+++ lldb/source/Core/DumpDataExtractor.cpp
@@ -14,7 +14,6 @@
 #include "lldb/Core/Address.h"
 #include "lldb/Core/Disassembler.h"
 #include "lldb/Core/ModuleList.h"
-#include "lldb/Symbol/ClangASTContext.h"
 #include "lldb/Target/ExecutionContext.h"
 #include "lldb/Target/ExecutionContextScope.h"
 #include "lldb/Target/SectionLoadList.h"
@@ -69,6 +68,9 @@
 static llvm::Optional GetAPInt(const DataExtractor &data,
 lldb::offset_t *offset_ptr,
 lldb::offset_t byte_size) {
+  if (byte_size == 0)
+return llvm::None;
+
   llvm::SmallVector uint64_array;
   lldb::offset_t bytes_left = byte_size;
   uint64_t u64;
@@ -556,57 +558,31 @@
   if (exe_scope)
 target_sp = exe_scope->CalculateTarget();
   if (target_sp) {
-ClangASTContext *clang_ast = target_sp->GetScratchClangASTContext();
-if (clang_ast) {
-  clang::ASTContext *ast = clang_ast->getASTContext();
-  if (ast) {
-llvm::SmallVector sv;
-// Show full precision when printing float values
-const unsigned format_precision = 0;
-const unsigned format_max_padding =
-target_sp->GetMaxZeroPaddingInFloatFormat();
-size_t item_bit_size = item_byte_size * 8;
-
-if (item_bit_size == ast->getTypeSize(ast->FloatTy)) {
-  llvm::Optional apint =
-  GetAPInt(DE, &offset, item_byte_size);
-  if (apint.hasValue()) {
-llvm::APFloat apfloat(ast->getFloatTypeSemantics(ast->FloatTy),
-  apint.getValue());
-apfloat.toString(sv, format_precision, format_max_padding);
-  }
-} else if (item_bit_size == ast->getTypeSize(ast->DoubleTy)) {
-  llvm::Optional apint =
-  GetAPInt(DE, &offset, item_byte_size);
-  if (apint.hasValue()) {
-llvm::APFloat apfloat(ast->getFloatTypeSemantics(ast->DoubleTy),
-  apint.getValue());
-apfloat.toString(sv, format_precision, format_max_padding);
-  }
-} else if (item_bit_size == ast->getTypeSize(ast->LongDoubleTy)) {
-  const auto &semantics =
-  ast->getFloatTypeSemantics(ast->LongDoubleTy);
-
-  offset_t byte_size = item_byte_size;
-  if (&semantics == &llvm::APFloatBase::x87DoubleExtended())
-byte_size = (llvm::APFloat::getSizeInBits(semantics) + 7) / 8;
-
-  llvm::Optional apint =
-  GetAPInt(DE, &offset, byte_size);
-  if (apint.hasValue()) {
-llvm::APFloat apfloat(semantics, apint.getValue());
-apfloat.toString(sv, format_precision, format_max_padding);
-  }
-} else if (item_bit_size == ast->getTypeSize(ast->HalfTy)) {
-  llvm::Optional apint =
-  GetAPInt(DE, &offset, item_byte_size);
-  if (apint.hasValue()) {
-llvm::APFloat apfloat(ast->getFloatTypeSemantics(ast->HalfTy),
-  apint.getValue());
-apfloat.toString(sv, format_precision, format_max_padding);
-  }
- 

[Lldb-commits] [PATCH] D66654: 2/2: Process formatters in reverse-chronological order

2019-09-06 Thread Jan Kratochvil via Phabricator via lldb-commits
jankratochvil updated this revision to Diff 219147.
jankratochvil added a comment.

I have tried the `MapVector` with `RegularExpressionSP` as its key as suggested 
by @labath but that would be even more code than the `std::list` I provided 
here, both for its custom shared-pointer sorting and for its 
`EmptyKey`+`TombstoneKey` if we should not put `std::map` there.
So I returned back to a single `std::vector` as originally suggested by @labath 
and after fixing missing `Delete` in the `Add` implementation for vector it I 
think that may be a good compromise from all the variants.


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D66654

Files:
  lldb/include/lldb/DataFormatters/FormattersContainer.h
  lldb/include/lldb/Utility/RegularExpression.h
  
lldb/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-advanced/TestDataFormatterAdv.py

Index: lldb/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-advanced/TestDataFormatterAdv.py
===
--- lldb/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-advanced/TestDataFormatterAdv.py
+++ lldb/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-advanced/TestDataFormatterAdv.py
@@ -136,6 +136,13 @@
 self.expect("frame variable int_array",
 substrs=['1,2'])
 
+# Test the patterns are matched in reverse-chronological order.
+self.runCmd(
+'type summary add --summary-string \"${var[2-3]}\" "int []"')
+
+self.expect("frame variable int_array",
+substrs=['3,4'])
+
 self.runCmd("type summary clear")
 
 self.runCmd("type summary add -c -x \"i_am_cool \[[0-9]\]\"")
Index: lldb/include/lldb/Utility/RegularExpression.h
===
--- lldb/include/lldb/Utility/RegularExpression.h
+++ lldb/include/lldb/Utility/RegularExpression.h
@@ -78,10 +78,6 @@
   /// otherwise.
   llvm::Error GetError() const;
 
-  bool operator<(const RegularExpression &rhs) const {
-return GetText() < rhs.GetText();
-  }
-
   bool operator==(const RegularExpression &rhs) const {
 return GetText() == rhs.GetText();
   }
Index: lldb/include/lldb/DataFormatters/FormattersContainer.h
===
--- lldb/include/lldb/DataFormatters/FormattersContainer.h
+++ lldb/include/lldb/DataFormatters/FormattersContainer.h
@@ -65,7 +65,7 @@
 template  class FormatMap {
 public:
   typedef typename ValueType::SharedPointer ValueSP;
-  typedef std::map MapType;
+  typedef std::vector> MapType;
   typedef typename MapType::iterator MapIterator;
   typedef std::function ForEachCallback;
 
@@ -79,20 +79,22 @@
   entry->GetRevision() = 0;
 
 std::lock_guard guard(m_map_mutex);
-m_map[std::move(name)] = entry;
+Delete(name);
+m_map.push_back(std::make_pair(std::move(name), std::move(entry)));
 if (listener)
   listener->Changed();
   }
 
   bool Delete(const KeyType &name) {
 std::lock_guard guard(m_map_mutex);
-MapIterator iter = m_map.find(name);
-if (iter == m_map.end())
-  return false;
-m_map.erase(iter);
-if (listener)
-  listener->Changed();
-return true;
+for (MapIterator iter = m_map.begin(); iter != m_map.end(); ++iter)
+  if (iter->first == name) {
+m_map.erase(iter);
+if (listener)
+  listener->Changed();
+return true;
+  }
+return false;
   }
 
   void Clear() {
@@ -104,11 +106,12 @@
 
   bool Get(const KeyType &name, ValueSP &entry) {
 std::lock_guard guard(m_map_mutex);
-MapIterator iter = m_map.find(name);
-if (iter == m_map.end())
-  return false;
-entry = iter->second;
-return true;
+for (MapIterator iter = m_map.begin(); iter != m_map.end(); ++iter)
+  if (iter->first == name) {
+entry = iter->second;
+return true;
+  }
+return false;
   }
 
   void ForEach(ForEachCallback callback) {
@@ -127,29 +130,17 @@
 
   ValueSP GetValueAtIndex(size_t index) {
 std::lock_guard guard(m_map_mutex);
-MapIterator iter = m_map.begin();
-MapIterator end = m_map.end();
-while (index > 0) {
-  iter++;
-  index--;
-  if (end == iter)
-return ValueSP();
-}
-return iter->second;
+if (index >= m_map.size())
+  return ValueSP();
+return m_map[index].second;
   }
 
   // If caller holds the mutex we could return a reference without copy ctor.
   KeyType GetKeyAtIndex(size_t index) {
 std::lock_guard guard(m_map_mutex);
-MapIterator iter = m_map.begin();
-MapIterator end = m_map.end();
-while (index > 0) {
-  iter++;
-  index--;
-  if (end == iter)
-return KeyType();
-}
-return iter->first;
+if (index >= m_map.size(

[Lldb-commits] [lldb] r371258 - [Core] Remove use of ClangASTContext in DumpDataExtractor

2019-09-06 Thread Alex Langford via lldb-commits
Author: xiaobai
Date: Fri Sep  6 14:05:21 2019
New Revision: 371258

URL: http://llvm.org/viewvc/llvm-project?rev=371258&view=rev
Log:
[Core] Remove use of ClangASTContext in DumpDataExtractor

Summary:
DumpDataExtractor uses ClangASTContext in order to get the proper llvm
fltSemantics for the type it needs so that it can dump floats in a more
precise way. However, there's no reason that this behavior needs to be
specific ClangASTContext. Instead, I think it makes sense to ask
TypeSystems for the float semantics for a type of a given size.

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

Modified:
lldb/trunk/include/lldb/Symbol/ClangASTContext.h
lldb/trunk/include/lldb/Symbol/TypeSystem.h
lldb/trunk/source/Core/DumpDataExtractor.cpp
lldb/trunk/source/Symbol/ClangASTContext.cpp

Modified: lldb/trunk/include/lldb/Symbol/ClangASTContext.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Symbol/ClangASTContext.h?rev=371258&r1=371257&r2=371258&view=diff
==
--- lldb/trunk/include/lldb/Symbol/ClangASTContext.h (original)
+++ lldb/trunk/include/lldb/Symbol/ClangASTContext.h Fri Sep  6 14:05:21 2019
@@ -694,6 +694,8 @@ public:
 
   // Exploring the type
 
+  const llvm::fltSemantics &GetFloatTypeSemantics(size_t byte_size) override;
+
   llvm::Optional GetByteSize(lldb::opaque_compiler_type_t type,
ExecutionContextScope *exe_scope) {
 if (llvm::Optional bit_size = GetBitSize(type, exe_scope))

Modified: lldb/trunk/include/lldb/Symbol/TypeSystem.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Symbol/TypeSystem.h?rev=371258&r1=371257&r2=371258&view=diff
==
--- lldb/trunk/include/lldb/Symbol/TypeSystem.h (original)
+++ lldb/trunk/include/lldb/Symbol/TypeSystem.h Fri Sep  6 14:05:21 2019
@@ -14,6 +14,7 @@
 #include 
 #include 
 
+#include "llvm/ADT/APFloat.h"
 #include "llvm/ADT/APSInt.h"
 #include "llvm/ADT/SmallBitVector.h"
 #include "llvm/Support/Casting.h"
@@ -276,6 +277,8 @@ public:
 
   // Exploring the type
 
+  virtual const llvm::fltSemantics &GetFloatTypeSemantics(size_t byte_size) = 
0;
+
   virtual llvm::Optional
   GetBitSize(lldb::opaque_compiler_type_t type,
  ExecutionContextScope *exe_scope) = 0;

Modified: lldb/trunk/source/Core/DumpDataExtractor.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Core/DumpDataExtractor.cpp?rev=371258&r1=371257&r2=371258&view=diff
==
--- lldb/trunk/source/Core/DumpDataExtractor.cpp (original)
+++ lldb/trunk/source/Core/DumpDataExtractor.cpp Fri Sep  6 14:05:21 2019
@@ -14,7 +14,6 @@
 #include "lldb/Core/Address.h"
 #include "lldb/Core/Disassembler.h"
 #include "lldb/Core/ModuleList.h"
-#include "lldb/Symbol/ClangASTContext.h"
 #include "lldb/Target/ExecutionContext.h"
 #include "lldb/Target/ExecutionContextScope.h"
 #include "lldb/Target/SectionLoadList.h"
@@ -69,6 +68,9 @@ static float half2float(uint16_t half) {
 static llvm::Optional GetAPInt(const DataExtractor &data,
 lldb::offset_t *offset_ptr,
 lldb::offset_t byte_size) {
+  if (byte_size == 0)
+return llvm::None;
+
   llvm::SmallVector uint64_array;
   lldb::offset_t bytes_left = byte_size;
   uint64_t u64;
@@ -556,57 +558,31 @@ lldb::offset_t lldb_private::DumpDataExt
   if (exe_scope)
 target_sp = exe_scope->CalculateTarget();
   if (target_sp) {
-ClangASTContext *clang_ast = target_sp->GetScratchClangASTContext();
-if (clang_ast) {
-  clang::ASTContext *ast = clang_ast->getASTContext();
-  if (ast) {
-llvm::SmallVector sv;
-// Show full precision when printing float values
-const unsigned format_precision = 0;
-const unsigned format_max_padding =
-target_sp->GetMaxZeroPaddingInFloatFormat();
-size_t item_bit_size = item_byte_size * 8;
-
-if (item_bit_size == ast->getTypeSize(ast->FloatTy)) {
-  llvm::Optional apint =
-  GetAPInt(DE, &offset, item_byte_size);
-  if (apint.hasValue()) {
-llvm::APFloat apfloat(ast->getFloatTypeSemantics(ast->FloatTy),
-  apint.getValue());
-apfloat.toString(sv, format_precision, format_max_padding);
-  }
-} else if (item_bit_size == ast->getTypeSize(ast->DoubleTy)) {
-  llvm::Optional apint =
-  GetAPInt(DE, &offset, item_byte_size);
-  if (apint.hasValue()) {
-llvm::APFloat 
apfloat(ast->getFloatTypeSemantics(ast->DoubleTy),
-  apint.getValue());
-apfloat.toString(sv, format_precisi

[Lldb-commits] [PATCH] D67239: [Core] Remove use of ClangASTContext in DumpDataExtractor

2019-09-06 Thread Alex Langford via Phabricator via lldb-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL371258: [Core] Remove use of ClangASTContext in 
DumpDataExtractor (authored by xiaobai, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D67239?vs=219145&id=219174#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D67239

Files:
  lldb/trunk/include/lldb/Symbol/ClangASTContext.h
  lldb/trunk/include/lldb/Symbol/TypeSystem.h
  lldb/trunk/source/Core/DumpDataExtractor.cpp
  lldb/trunk/source/Symbol/ClangASTContext.cpp

Index: lldb/trunk/source/Core/DumpDataExtractor.cpp
===
--- lldb/trunk/source/Core/DumpDataExtractor.cpp
+++ lldb/trunk/source/Core/DumpDataExtractor.cpp
@@ -14,7 +14,6 @@
 #include "lldb/Core/Address.h"
 #include "lldb/Core/Disassembler.h"
 #include "lldb/Core/ModuleList.h"
-#include "lldb/Symbol/ClangASTContext.h"
 #include "lldb/Target/ExecutionContext.h"
 #include "lldb/Target/ExecutionContextScope.h"
 #include "lldb/Target/SectionLoadList.h"
@@ -69,6 +68,9 @@
 static llvm::Optional GetAPInt(const DataExtractor &data,
 lldb::offset_t *offset_ptr,
 lldb::offset_t byte_size) {
+  if (byte_size == 0)
+return llvm::None;
+
   llvm::SmallVector uint64_array;
   lldb::offset_t bytes_left = byte_size;
   uint64_t u64;
@@ -556,57 +558,31 @@
   if (exe_scope)
 target_sp = exe_scope->CalculateTarget();
   if (target_sp) {
-ClangASTContext *clang_ast = target_sp->GetScratchClangASTContext();
-if (clang_ast) {
-  clang::ASTContext *ast = clang_ast->getASTContext();
-  if (ast) {
-llvm::SmallVector sv;
-// Show full precision when printing float values
-const unsigned format_precision = 0;
-const unsigned format_max_padding =
-target_sp->GetMaxZeroPaddingInFloatFormat();
-size_t item_bit_size = item_byte_size * 8;
-
-if (item_bit_size == ast->getTypeSize(ast->FloatTy)) {
-  llvm::Optional apint =
-  GetAPInt(DE, &offset, item_byte_size);
-  if (apint.hasValue()) {
-llvm::APFloat apfloat(ast->getFloatTypeSemantics(ast->FloatTy),
-  apint.getValue());
-apfloat.toString(sv, format_precision, format_max_padding);
-  }
-} else if (item_bit_size == ast->getTypeSize(ast->DoubleTy)) {
-  llvm::Optional apint =
-  GetAPInt(DE, &offset, item_byte_size);
-  if (apint.hasValue()) {
-llvm::APFloat apfloat(ast->getFloatTypeSemantics(ast->DoubleTy),
-  apint.getValue());
-apfloat.toString(sv, format_precision, format_max_padding);
-  }
-} else if (item_bit_size == ast->getTypeSize(ast->LongDoubleTy)) {
-  const auto &semantics =
-  ast->getFloatTypeSemantics(ast->LongDoubleTy);
-
-  offset_t byte_size = item_byte_size;
-  if (&semantics == &llvm::APFloatBase::x87DoubleExtended())
-byte_size = (llvm::APFloat::getSizeInBits(semantics) + 7) / 8;
-
-  llvm::Optional apint =
-  GetAPInt(DE, &offset, byte_size);
-  if (apint.hasValue()) {
-llvm::APFloat apfloat(semantics, apint.getValue());
-apfloat.toString(sv, format_precision, format_max_padding);
-  }
-} else if (item_bit_size == ast->getTypeSize(ast->HalfTy)) {
-  llvm::Optional apint =
-  GetAPInt(DE, &offset, item_byte_size);
-  if (apint.hasValue()) {
-llvm::APFloat apfloat(ast->getFloatTypeSemantics(ast->HalfTy),
-  apint.getValue());
-apfloat.toString(sv, format_precision, format_max_padding);
-  }
-}
-
+auto type_system_or_err =
+target_sp->GetScratchTypeSystemForLanguage(eLanguageTypeC);
+if (!type_system_or_err) {
+  llvm::consumeError(type_system_or_err.takeError());
+} else {
+  auto &type_system = *type_system_or_err;
+  llvm::SmallVector sv;
+  // Show full precision when printing float values
+  const unsigned format_precision = 0;
+  const unsigned format_max_padding =
+  target_sp->GetMaxZeroPaddingInFloatFormat();
+
+  const auto &semantics =
+  type_system.GetFloatTypeSemantics(item_byte_size);
+
+  // Recalculate the byte size in case of a difference. This is possible
+  // when item_byte_size is 16 (128-bit), because you could get back

[Lldb-commits] [lldb] r371259 - [test] Add a FIXME test for stop-command-source-on-error

2019-09-06 Thread Jonas Devlieghere via lldb-commits
Author: jdevlieghere
Date: Fri Sep  6 14:43:33 2019
New Revision: 371259

URL: http://llvm.org/viewvc/llvm-project?rev=371259&view=rev
Log:
[test] Add a FIXME test for stop-command-source-on-error

Modifying the interpreter settings is tricky because they don't take
effect until we create a new command interpreter, which should be merely
an implementation detail. This leads to confusing and unexpected
scenarios.

This adds a test cases with FIXMEs for some of the odd scenarios I
encountered. I didn't XFAIL the test because I don't think there's a way
to get an unexpected PASS if any of the commands succeeds and splitting
up the file in multiple tests seems excessive.

Added:
lldb/trunk/lit/Settings/Inputs/DontStopCommandSource.in
lldb/trunk/lit/Settings/Inputs/StopCommandSource.in
lldb/trunk/lit/Settings/TestStopCommandSourceOnError.test

Added: lldb/trunk/lit/Settings/Inputs/DontStopCommandSource.in
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/lit/Settings/Inputs/DontStopCommandSource.in?rev=371259&view=auto
==
--- lldb/trunk/lit/Settings/Inputs/DontStopCommandSource.in (added)
+++ lldb/trunk/lit/Settings/Inputs/DontStopCommandSource.in Fri Sep  6 14:43:33 
2019
@@ -0,0 +1,3 @@
+settings set interpreter.stop-command-source-on-error false
+bogus
+print 12340 + 56789

Added: lldb/trunk/lit/Settings/Inputs/StopCommandSource.in
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/lit/Settings/Inputs/StopCommandSource.in?rev=371259&view=auto
==
--- lldb/trunk/lit/Settings/Inputs/StopCommandSource.in (added)
+++ lldb/trunk/lit/Settings/Inputs/StopCommandSource.in Fri Sep  6 14:43:33 2019
@@ -0,0 +1,3 @@
+settings set interpreter.stop-command-source-on-error true
+bogus
+print 12340 + 56789

Added: lldb/trunk/lit/Settings/TestStopCommandSourceOnError.test
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/lit/Settings/TestStopCommandSourceOnError.test?rev=371259&view=auto
==
--- lldb/trunk/lit/Settings/TestStopCommandSourceOnError.test (added)
+++ lldb/trunk/lit/Settings/TestStopCommandSourceOnError.test Fri Sep  6 
14:43:33 2019
@@ -0,0 +1,24 @@
+# Modifying the interpreter settings is tricky because they don't take effect
+# until we create a new command interpreter, which should be merely an
+# implementation detail. This leads to confusing and unexpected scenarios.
+#
+# Below are a few scenarios that we should fix.
+
+# CONTINUE: 123456789
+# STOP-NOT: 1
+# STOP-NOT: 123456789
+
+# FIXME: Should stop
+# RUN: %lldb -b -o 'settings set interpreter.stop-command-source-on-error 
false' -s %S/Inputs/StopCommandSource.in | FileCheck %s --check-prefix CONTINUE
+
+# FIXME: Should continue
+# RUN: %lldb -b -s %S/Inputs/DontStopCommandSource.in -o 'bogus' -o 'print 
0 + 1' | FileCheck %s --check-prefix STOP
+
+# FIXME: Should continue
+# RUN: %lldb -b -o 'settings set interpreter.stop-command-source-on-error 
false' -o 'bogus' -o 'print 12340 + 56789'  | FileCheck %s --check-prefix 
STOP
+
+# FIXME: Should continue
+# RUN: %lldb -b -s %S/Inputs/DontStopCommandSource.in | FileCheck %s 
--check-prefix STOP
+
+# FIXME: Should continue
+# RUN: %lldb -b -o 'settings set interpreter.stop-command-source-on-error 
true' -s %S/Inputs/DontStopCommandSource.in | FileCheck %s --check-prefix STOP


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


[Lldb-commits] [lldb] r371280 - Long timeouts for the MacOSX SystemRuntime plugins under ASAN; else quick.

2019-09-06 Thread Jason Molenda via lldb-commits
Author: jmolenda
Date: Fri Sep  6 18:38:37 2019
New Revision: 371280

URL: http://llvm.org/viewvc/llvm-project?rev=371280&view=rev
Log:
Long timeouts for the MacOSX SystemRuntime plugins under ASAN; else quick.

In April via r357829, Adrian unified timeouts across lldb and set the
default value high so that we wouldn't get timeouts on ASAN bots that
were running under load.

The library that the MacOSX SystemRuntime has functions that need
to take a lock, and if that lock is held already, those functions
will never complete; we're seeing the 15 second timeout being hit
with inferiors that are doing a lot of enqueuing and dequeuing of
libdispatch work items causing this deadlocking behavior.

This patch reverts to a very short timeout for these SystemRuntime
function calls, given the behavior of this library that they are 
calling into.  When lldb is built with AddressSanitizer enabled,
they will use the default 15 second timeout.

tl;dr: this reverts to the previous timeouts for these SystemRuntime
inf func calls.

 


Modified:
lldb/trunk/source/Plugins/SystemRuntime/MacOSX/AppleGetItemInfoHandler.cpp

lldb/trunk/source/Plugins/SystemRuntime/MacOSX/AppleGetPendingItemsHandler.cpp
lldb/trunk/source/Plugins/SystemRuntime/MacOSX/AppleGetQueuesHandler.cpp

lldb/trunk/source/Plugins/SystemRuntime/MacOSX/AppleGetThreadItemInfoHandler.cpp

Modified: 
lldb/trunk/source/Plugins/SystemRuntime/MacOSX/AppleGetItemInfoHandler.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/SystemRuntime/MacOSX/AppleGetItemInfoHandler.cpp?rev=371280&r1=371279&r2=371280&view=diff
==
--- lldb/trunk/source/Plugins/SystemRuntime/MacOSX/AppleGetItemInfoHandler.cpp 
(original)
+++ lldb/trunk/source/Plugins/SystemRuntime/MacOSX/AppleGetItemInfoHandler.cpp 
Fri Sep  6 18:38:37 2019
@@ -332,6 +332,11 @@ AppleGetItemInfoHandler::GetItemInfo(Thr
   options.SetUnwindOnError(true);
   options.SetIgnoreBreakpoints(true);
   options.SetStopOthers(true);
+#if __has_feature(address_sanitizer)
+  options.SetTimeout(process_sp->GetUtilityExpressionTimeout());
+#else
+  options.SetTimeout(std::chrono::milliseconds(500));
+#endif
   options.SetTimeout(process_sp->GetUtilityExpressionTimeout());
   options.SetTryAllThreads(false);
   options.SetIsForUtilityExpr(true);

Modified: 
lldb/trunk/source/Plugins/SystemRuntime/MacOSX/AppleGetPendingItemsHandler.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/SystemRuntime/MacOSX/AppleGetPendingItemsHandler.cpp?rev=371280&r1=371279&r2=371280&view=diff
==
--- 
lldb/trunk/source/Plugins/SystemRuntime/MacOSX/AppleGetPendingItemsHandler.cpp 
(original)
+++ 
lldb/trunk/source/Plugins/SystemRuntime/MacOSX/AppleGetPendingItemsHandler.cpp 
Fri Sep  6 18:38:37 2019
@@ -338,7 +338,11 @@ AppleGetPendingItemsHandler::GetPendingI
   options.SetUnwindOnError(true);
   options.SetIgnoreBreakpoints(true);
   options.SetStopOthers(true);
+#if __has_feature(address_sanitizer)
   options.SetTimeout(process_sp->GetUtilityExpressionTimeout());
+#else
+  options.SetTimeout(std::chrono::milliseconds(500));
+#endif
   options.SetTryAllThreads(false);
   options.SetIsForUtilityExpr(true);
   thread.CalculateExecutionContext(exe_ctx);

Modified: 
lldb/trunk/source/Plugins/SystemRuntime/MacOSX/AppleGetQueuesHandler.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/SystemRuntime/MacOSX/AppleGetQueuesHandler.cpp?rev=371280&r1=371279&r2=371280&view=diff
==
--- lldb/trunk/source/Plugins/SystemRuntime/MacOSX/AppleGetQueuesHandler.cpp 
(original)
+++ lldb/trunk/source/Plugins/SystemRuntime/MacOSX/AppleGetQueuesHandler.cpp 
Fri Sep  6 18:38:37 2019
@@ -344,7 +344,11 @@ AppleGetQueuesHandler::GetCurrentQueues(
   options.SetUnwindOnError(true);
   options.SetIgnoreBreakpoints(true);
   options.SetStopOthers(true);
+#if __has_feature(address_sanitizer)
   options.SetTimeout(process_sp->GetUtilityExpressionTimeout());
+#else
+  options.SetTimeout(std::chrono::milliseconds(500));
+#endif
   options.SetTryAllThreads(false);
   options.SetIsForUtilityExpr(true);
   thread.CalculateExecutionContext(exe_ctx);

Modified: 
lldb/trunk/source/Plugins/SystemRuntime/MacOSX/AppleGetThreadItemInfoHandler.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/SystemRuntime/MacOSX/AppleGetThreadItemInfoHandler.cpp?rev=371280&r1=371279&r2=371280&view=diff
==
--- 
lldb/trunk/source/Plugins/SystemRuntime/MacOSX/AppleGetThreadItemInfoHandler.cpp
 (original)
+++ 
lldb/trunk/source/Plugins/SystemRuntime/MacOSX/AppleGetThreadItemInfoHandler.cpp
 Fri Sep  6 18:38:37 2019
@@ -341,7 +341,11 @@ AppleGetThreadItemInfoHandler::GetThread
   options.SetUnwindOnError(true);
   option