date:20190717

[Lldb-commits] [lldb] r366292 - [Target][NFCI] Rename variable

2019-07-17 Thread Alex Langford via lldb-commits

Author: xiaobai
Date: Wed Jul 17 00:03:17 2019
New Revision: 366292

URL: http://llvm.org/viewvc/llvm-project?rev=366292&view=rev
Log:
[Target][NFCI] Rename variable

This variable doesn't have anything to do with clang.

Modified:
lldb/trunk/source/Target/ABI.cpp

Modified: lldb/trunk/source/Target/ABI.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Target/ABI.cpp?rev=366292&r1=366291&r2=366292&view=diff
==
--- lldb/trunk/source/Target/ABI.cpp (original)
+++ lldb/trunk/source/Target/ABI.cpp Wed Jul 17 00:03:17 2019
@@ -124,11 +124,11 @@ ValueObjectSP ABI::GetReturnValueObject(
 
 return_valobj_sp = const_valobj_sp;
 
-ExpressionVariableSP clang_expr_variable_sp(
+ExpressionVariableSP expr_variable_sp(
 persistent_expression_state->CreatePersistentVariable(
 return_valobj_sp));
 
-assert(clang_expr_variable_sp);
+assert(expr_variable_sp);
 
 // Set flags and live data as appropriate
 
@@ -141,21 +141,21 @@ ValueObjectSP ABI::GetReturnValueObject(
   break;
 case Value::eValueTypeScalar:
 case Value::eValueTypeVector:
-  clang_expr_variable_sp->m_flags |=
+  expr_variable_sp->m_flags |=
   ExpressionVariable::EVIsFreezeDried;
-  clang_expr_variable_sp->m_flags |=
+  expr_variable_sp->m_flags |=
   ExpressionVariable::EVIsLLDBAllocated;
-  clang_expr_variable_sp->m_flags |=
+  expr_variable_sp->m_flags |=
   ExpressionVariable::EVNeedsAllocation;
   break;
 case Value::eValueTypeLoadAddress:
-  clang_expr_variable_sp->m_live_sp = live_valobj_sp;
-  clang_expr_variable_sp->m_flags |=
+  expr_variable_sp->m_live_sp = live_valobj_sp;
+  expr_variable_sp->m_flags |=
   ExpressionVariable::EVIsProgramReference;
   break;
 }
 
-return_valobj_sp = clang_expr_variable_sp->GetValueObject();
+return_valobj_sp = expr_variable_sp->GetValueObject();
   }
   return return_valobj_sp;
 }


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

[Lldb-commits] [PATCH] D64853: Fix CommandInterpreter for _regexp-break with options

2019-07-17 Thread Med Ismail Bennani via Phabricator via lldb-commits

mib created this revision.
Herald added a project: LLDB.
Herald added a subscriber: lldb-commits.

This patch fixes the regular expressions used by the CommandInterpreter
to match GDB style breakpoint command to the LLDB style.

The previous version passed the breakpoint options to _regex-break as a name
identifier, instead of recognising the options.

In addition to that, several test case have been added to check if all the
supported _regex-break command match their `b` alias.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D64853

Files:
  
lldb/packages/Python/lldbsuite/test/functionalities/breakpoint/breakpoint_command/TestRegexpBreakCommand.py
  
lldb/packages/Python/lldbsuite/test/functionalities/breakpoint/breakpoint_command/main.c
  lldb/source/Interpreter/CommandInterpreter.cpp

Index: lldb/source/Interpreter/CommandInterpreter.cpp
===
--- lldb/source/Interpreter/CommandInterpreter.cpp
+++ lldb/source/Interpreter/CommandInterpreter.cpp
@@ -516,27 +516,27 @@
   CommandObjectSP(new CommandObjectLanguage(*this));
 
   const char *break_regexes[][2] = {
-  {"^(.*[^[:space:]])[[:space:]]*:[[:space:]]*([[:digit:]]+)[[:space:]]*$",
-   "breakpoint set --file '%1' --line %2"},
-  {"^/([^/]+)/$", "breakpoint set --source-pattern-regexp '%1'"},
-  {"^([[:digit:]]+)[[:space:]]*$", "breakpoint set --line %1"},
-  {"^\\*?(0x[[:xdigit:]]+)[[:space:]]*$", "breakpoint set --address %1"},
-  {"^[\"']?([-+]?\\[.*\\])[\"']?[[:space:]]*$",
-   "breakpoint set --name '%1'"},
+  {"^([^[:space:]]+)[[:space:]]*:[[:space:]]*([[:digit:]]+)(?:$|\\s+)(-.*)*$",
+   "breakpoint set --file '%1' --line %2 %3"},
+  {"/([^/]+)/(?:$|\\s+)(-.*)*$", "breakpoint set --source-pattern-regexp '%1' %2"},
+  {"^([[:digit:]]+)(?:$|\\s+)(-.*)*$", "breakpoint set --line %1 %2"},
+  {"^(0x[[:xdigit:]]+)(?:$|\\s+)(-.*)*$", "breakpoint set --address %1 %2"},
+  {"^[\"']?([-+]?\\[[^[:space:]\"']+\\s+[^[:space:]\"']+\\])[\"']?(?:$|\\s+)(-.*)*$",
+   "breakpoint set --name '%1' %2"}, // Objective-C Identifier
   {"^(-.*)$", "breakpoint set %1"},
-  {"^(.*[^[:space:]])`(.*[^[:space:]])[[:space:]]*$",
-   "breakpoint set --name '%2' --shlib '%1'"},
-  {"^\\&(.*[^[:space:]])[[:space:]]*$",
+  {"^([^[:space:]]+)`([^[:space:]]+)(?:$|\\s+)(-.*)*$",
+   "breakpoint set --name '%2' --shlib '%1' %3"},
+  {"^\\&([^[:space:]]+)(?:$|\\s+)(-.*)*$",
"breakpoint set --name '%1' --skip-prologue=0"},
-  {"^[\"']?(.*[^[:space:]\"'])[\"']?[[:space:]]*$",
-   "breakpoint set --name '%1'"}};
+  {"^[\"']?([^[:space:]\"']+)[\"']?(?:$|\\s+(-.*))*$",
+   "breakpoint set --name '%1' %2"}};
 
   size_t num_regexes = llvm::array_lengthof(break_regexes);
 
   std::unique_ptr break_regex_cmd_up(
   new CommandObjectRegexCommand(
   *this, "_regexp-break",
-  "Set a breakpoint using one of several shorthand formats.",
+  "Set a breakpoint using one of several shorthand formats. Accepts breakpoint options.",
   "\n"
   "_regexp-break :\n"
   "  main.c:12 // Break at line 12 of "
@@ -561,7 +561,7 @@
   "current file\n"
   "// containing text 'break "
   "here'.\n",
-  2,
+  3,
   CommandCompletions::eSymbolCompletion |
   CommandCompletions::eSourceFileCompletion,
   false));
Index: lldb/packages/Python/lldbsuite/test/functionalities/breakpoint/breakpoint_command/main.c
===
--- lldb/packages/Python/lldbsuite/test/functionalities/breakpoint/breakpoint_command/main.c
+++ lldb/packages/Python/lldbsuite/test/functionalities/breakpoint/breakpoint_command/main.c
@@ -6,11 +6,14 @@
 //
 //===--===//
 
+#include 
+
 int main (int argc, char const *argv[])
 {
 // Add a body to the function, so we can set more than one
 // breakpoint in it.
 static volatile int var = 0;
 var++;
+malloc(sizeof(int));
 return 0; // Set break point at this line.
 }
Index: lldb/packages/Python/lldbsuite/test/functionalities/breakpoint/breakpoint_command/TestRegexpBreakCommand.py
===
--- lldb/packages/Python/lldbsuite/test/functionalities/breakpoint/breakpoint_command/TestRegexpBreakCommand.py
+++ lldb/packages/Python/lldbsuite/test/functionalities/breakpoint/breakpoint_command/TestRegexpBreakCommand.py
@@ -16,21 +16,68 @@
 
 mydir = TestBase.compute_mydir(__file__)
 
-def test(self):
-"""Test _regexp-break command."""
+def test_line(self):
+"""Test _regexp-break command with a line number."""
 self.build()
-self.regexp_break_command()
+self.regexp_break_command_line()
+
+de

[Lldb-commits] [lldb] r366295 - [Target][NFCI] Remove commented out code

2019-07-17 Thread Alex Langford via lldb-commits

Author: xiaobai
Date: Wed Jul 17 00:13:42 2019
New Revision: 366295

URL: http://llvm.org/viewvc/llvm-project?rev=366295&view=rev
Log:
[Target][NFCI] Remove commented out code

Modified:
lldb/trunk/source/Target/ThreadPlanTracer.cpp

Modified: lldb/trunk/source/Target/ThreadPlanTracer.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Target/ThreadPlanTracer.cpp?rev=366295&r1=366294&r2=366295&view=diff
==
--- lldb/trunk/source/Target/ThreadPlanTracer.cpp (original)
+++ lldb/trunk/source/Target/ThreadPlanTracer.cpp Wed Jul 17 00:13:42 2019
@@ -187,8 +187,6 @@ void ThreadPlanAssemblyTracer::Log() {
 for (int arg_index = 0; arg_index < num_args; ++arg_index) {
   Value value;
   value.SetValueType(Value::eValueTypeScalar);
-  //value.SetContext (Value::eContextTypeClangType,
-  //intptr_type.GetOpaqueQualType());
   value.SetCompilerType(intptr_type);
   value_list.PushValue(value);
 }


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

[Lldb-commits] [PATCH] D64769: [lldb][test_suite] change the test main.cpp to avoid expression reschedule

2019-07-17 Thread Pavel Labath via Phabricator via lldb-commits

labath added a comment.

In D64769#1587992 , @kusmour wrote:

> The test set the breakpoint to the return statement, even thought the 
> compiler flag `-O0` was set, the first hit to that bp showed that `g_common_1 
> = 0` which actually should be 21. The test assume when we hit the return 
> statement, the value should already be calculated, but that's not the case 
> for NDK20 clang.
>
> So we reproduce the test manually, turned out that the value was calculated 
> later. lldb first hit the return statement then jump back to line 20. By 
> looking at the assembly that clang provided, it indeed jump back and forth.
>
> It's possible that the jumping behavior is caused by optimization, 
> considering there're some other tests having similar problem, and the 
> behavior changed a lot from NDK 19 to 20. I made this change because this is 
> irrelevant to testing global variables.

Yeah, this problem isn't a bug in the debugger, but it could be considered a 
bug in the compiler, as one wouldn't expect the line numbers to jump around 
like this at -O0. And indeed, if we compare the the ndk r20 clang output with 
the current ToT, then we can see that they generate nearly identical assembly, 
but their line numbers differ. So it looks like somebody did consider this to 
be a bug and fixed it already.

Anyway, working around that here seems fine...

Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D64769

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

[Lldb-commits] [PATCH] D64853: Fix CommandInterpreter for _regex-break with options

2019-07-17 Thread Raphael Isemann via Phabricator via lldb-commits

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

This breaks several tests on linux:

  Failing Tests (20):
  LLDB :: Breakpoint/debug_addrx.test
  LLDB :: Breakpoint/debug_rnglist_basic.test
  LLDB :: Breakpoint/debug_rnglist_offset_pair.test
  LLDB :: Breakpoint/debug_rnglist_rlestartend.test
  LLDB :: Breakpoint/debug_rnglistx_rlex.test
  LLDB :: Breakpoint/implicit_const_form_support.test
  LLDB :: Breakpoint/jitbp_elf.test
  LLDB :: Breakpoint/single-file-split-dwarf.test
  LLDB :: Breakpoint/split-dwarf-5-addrbase.test
  LLDB :: Breakpoint/split-dwarf5-debug-stroffsets.test
  LLDB :: Expr/TestIRMemoryMap.test
  LLDB :: Settings/TestFrameFormatColor.test
  LLDB :: Watchpoint/SetErrorCases.test
  lldb-Suite :: 
functionalities/breakpoint/breakpoint_command/TestRegexpBreakCommand.py
  lldb-Suite :: 
functionalities/breakpoint/breakpoint_hit_count/TestBreakpointHitCount.py
  lldb-Suite :: functionalities/command_script/TestCommandScript.py
  lldb-Suite :: functionalities/format/TestFormats.py
  lldb-Suite :: functionalities/show_location/TestShowLocationDwarf5.py
  lldb-Suite :: functionalities/target_command/TestTargetCommand.py
  lldb-Suite :: 
functionalities/watchpoint/watchpoint_on_vectors/TestValueOfVectorVariable.py

I uploaded the test output here: https://teemperor.de/pub/FailingRegexLog.txt


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D64853



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

[Lldb-commits] [PATCH] D63813: Adjust variable formatting table

2019-07-17 Thread Lukas Böger via Phabricator via lldb-commits

lubgr updated this revision to Diff 210278.
lubgr added a comment.

I updated the description of the `address` format, is it appropriate? And I 
can't commit that myself, so thanks in advance for doing so when it's ready.


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D63813

Files:
  docs/use/variable.rst


Index: docs/use/variable.rst
===
--- docs/use/variable.rst
+++ docs/use/variable.rst
@@ -197,7 +197,7 @@
 
+---+--+--+
 | ``c-string``  | s| show this 
as a 0-terminated C string |
 
+---+--+--+
-| ``decimal``   | i| show this 
as a signed integer number (this does not perform a cast, it   |
+| ``decimal``   | d| show this 
as a signed integer number (this does not perform a cast, it   |
 |   |  | simply 
shows the bytes as  an integer with sign) |
 
+---+--+--+
 | ``enumeration``   | E| show this 
as an enumeration, printing the|
@@ -239,6 +239,15 @@
 
+---+--+--+
 | ``character array``   | a| show this 
as a character array   |
 
+---+--+--+
+| ``address``   | A| show this 
as an address target (symbol/file/line + offset), possibly |
+|   |  | also the 
string this address is pointing to  |
++---+--+--+
+| ``hex float`` |  | show this 
as hexadecimal floating point  |
++---+--+--+
+| ``instruction``   | i| show this 
as an disassembled opcode  |
++---+--+--+
+| ``void``  | v| don't 
show anything  |
++---+--+--+
 
 Type Summary
 


Index: docs/use/variable.rst
===
--- docs/use/variable.rst
+++ docs/use/variable.rst
@@ -197,7 +197,7 @@
 +---+--+--+
 | ``c-string``  | s| show this as a 0-terminated C string |
 +---+--+--+
-| ``decimal``   | i| show this as a signed integer number (this does not perform a cast, it   |
+| ``decimal``   | d| show this as a signed integer number (this does not perform a cast, it   |
 |   |  | simply shows the bytes as  an integer with sign) |
 +---+--+--+
 | ``enumeration``   | E| show this as an enumeration, printing the|
@@ -239,6 +239,15 @@
 +---+--+

[Lldb-commits] [PATCH] D64821: [CMake] Remove duplicated logic to find Python when doing a standalone build

2019-07-17 Thread Stefan Gränitz via Phabricator via lldb-commits

sgraenitz added a comment.

> I'm pretty sure there's no need to have this logic living in LLDBStandalone. 
> We always go through LLDBConfig.cmake which has the canonical way to find the 
> Python libs and interpreter.

LLDBStandalone is supposed to act like a polyfill for whatever LLVM would 
usually do, so LLDBConfig (and ideally everything else) can ignore in-tree vs. 
standalone. Thus, the Python logic here should always behave like its LLVM 
counterpart. If it turns out to be incorrect, we should either adapt LLDBConfig 
or change both LLVM and LLDBStandalone.

> Indeed, the culprit appears to be 
> https://github.com/llvm/llvm-project/blob/master/llvm/CMakeLists.txt#L645, 
> which prefer Python 3 over Python 2.

This changed quite recently https://reviews.llvm.org/D64443




Comment at: lldb/cmake/modules/LLDBStandalone.cmake:101
-  endif()
-
   set(PACKAGE_VERSION "${LLVM_PACKAGE_VERSION}")

The actual difference to 
https://github.com/llvm/llvm-project/blob/c23bc97e85f6/llvm/CMakeLists.txt#L645 
is the condition on `PYTHON_EXECUTABLE`.


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D64821



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

[Lldb-commits] [PATCH] D61333: [ASTImporter] Fix LLDB lookup in transparent ctx and with ext src

2019-07-17 Thread Gabor Marton via Phabricator via lldb-commits

martong marked an inline comment as done.
martong added inline comments.



Comment at: lldb/packages/Python/lldbsuite/test/lang/c/ast/TestAST.py:57
+# This expr command imports __sFILE with definition
+# (FILE is a typedef to __sFILE.)
+self.expect(

teemperor wrote:
> I think this test has a good chance to fail once someone 
> renamed/removes/changes this internal struct (especially if it's currently  
> abstracted with a typedef). Would it be possible to just make a minimal 
> module with open and FILE/__sFILE instead? If it's too much trouble, then I'm 
> also fine with merging this as-is (as this regression is easy to fix).
I'd rather keep this as-is, because I don't have enough confidence and 
experience with c modules (and with macOS).



Comment at: lldb/packages/Python/lldbsuite/test/lang/c/ast/TestAST.py:67
+# Check that the AST log contains exactly one definition of __sFILE.
+f = open(log_file)
+log_lines = f.readlines()

teemperor wrote:
> It seems that this is the only different in the test compared to 
> TestCModules.py. Would it be possible to just add this logging/checking to 
> TestCModules.py as it's anyway testing something very similar?
Ok, I have removed the TestAST.py and added the extra logging and the check 
into TestCModules.py.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D61333



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

[Lldb-commits] [PATCH] D61333: [ASTImporter] Fix LLDB lookup in transparent ctx and with ext src

2019-07-17 Thread Gabor Marton via Phabricator via lldb-commits

martong updated this revision to Diff 210281.
martong marked 5 inline comments as done.
martong added a comment.

- Applied clang-format on lldb parts (this changed two lines)
- Added a comment for predicate
- Merged the test into TestCModules.py


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D61333

Files:
  clang/lib/AST/ASTImporter.cpp
  clang/unittests/AST/ASTImporterTest.cpp
  lldb/packages/Python/lldbsuite/test/lang/c/modules/TestCModules.py
  lldb/packages/Python/lldbsuite/test/lang/c/modules/main.c
  lldb/source/Plugins/ExpressionParser/Clang/ClangASTSource.cpp

Index: lldb/source/Plugins/ExpressionParser/Clang/ClangASTSource.cpp
===
--- lldb/source/Plugins/ExpressionParser/Clang/ClangASTSource.cpp
+++ lldb/source/Plugins/ExpressionParser/Clang/ClangASTSource.cpp
@@ -611,10 +611,15 @@
   if (!original_decl_context)
 return;
 
+  // Indicates whether we skipped any Decls of the original DeclContext.
+  bool SkippedDecls = false;
   for (TagDecl::decl_iterator iter = original_decl_context->decls_begin();
iter != original_decl_context->decls_end(); ++iter) {
 Decl *decl = *iter;
 
+// The predicate function returns true if the passed declaration kind is
+// the one we are looking for.
+// See clang::ExternalASTSource::FindExternalLexicalDecls()
 if (predicate(decl->getKind())) {
   if (log) {
 ASTDumper ast_dumper(decl);
@@ -639,21 +644,22 @@
 
 m_ast_importer_sp->RequireCompleteType(copied_field_type);
   }
-
-  DeclContext *decl_context_non_const =
-  const_cast(decl_context);
-
-  if (copied_decl->getDeclContext() != decl_context) {
-if (copied_decl->getDeclContext()->containsDecl(copied_decl))
-  copied_decl->getDeclContext()->removeDecl(copied_decl);
-copied_decl->setDeclContext(decl_context_non_const);
-  }
-
-  if (!decl_context_non_const->containsDecl(copied_decl))
-decl_context_non_const->addDeclInternal(copied_decl);
+} else {
+  SkippedDecls = true;
 }
   }
 
+  // CopyDecl may build a lookup table which may set up ExternalLexicalStorage
+  // to false.  However, since we skipped some of the external Decls we must
+  // set it back!
+  if (SkippedDecls) {
+decl_context->setHasExternalLexicalStorage(true);
+// This sets HasLazyExternalLexicalLookups to true.  By setting this bit we
+// ensure that the lookup table is rebuilt, which means the external source
+// is consulted again when a clang::DeclContext::lookup is called.
+const_cast(decl_context)->setMustBuildLookupTable();
+  }
+
   return;
 }
 
Index: lldb/packages/Python/lldbsuite/test/lang/c/modules/main.c
===
--- lldb/packages/Python/lldbsuite/test/lang/c/modules/main.c
+++ lldb/packages/Python/lldbsuite/test/lang/c/modules/main.c
@@ -5,11 +5,11 @@
 typedef struct {
 int a;
 int b;
-} FILE;
+} MYFILE;
 
 int main()
 {
-FILE *myFile = malloc(sizeof(FILE));
+MYFILE *myFile = malloc(sizeof(MYFILE));
 
 myFile->a = 5;
 myFile->b = 9;
Index: lldb/packages/Python/lldbsuite/test/lang/c/modules/TestCModules.py
===
--- lldb/packages/Python/lldbsuite/test/lang/c/modules/TestCModules.py
+++ lldb/packages/Python/lldbsuite/test/lang/c/modules/TestCModules.py
@@ -47,6 +47,10 @@
 self.expect("breakpoint list -f", BREAKPOINT_HIT_ONCE,
 substrs=[' resolved, hit count = 1'])
 
+# Enable logging of the imported AST.
+log_file = os.path.join(self.getBuildDir(), "lldb-ast-log.txt")
+self.runCmd("log enable lldb ast -f '%s'" % log_file)
+
 self.expect(
 "expr -l objc++ -- @import Darwin; 3",
 VARIABLES_DISPLAYED_CORRECTLY,
@@ -54,6 +58,8 @@
 "int",
 "3"])
 
+# This expr command imports __sFILE with definition
+# (FILE is a typedef to __sFILE.)
 self.expect(
 "expr *fopen(\"/dev/zero\", \"w\")",
 VARIABLES_DISPLAYED_CORRECTLY,
@@ -61,6 +67,14 @@
 "FILE",
 "_close"])
 
+# Check that the AST log contains exactly one definition of __sFILE.
+f = open(log_file)
+log_lines = f.readlines()
+f.close()
+os.remove(log_file)
+self.assertEqual(" ".join(log_lines).count("struct __sFILE definition"),
+ 1)
+
 self.expect("expr *myFile", VARIABLES_DISPLAYED_CORRECTLY,
 substrs=["a", "5", "b", "9"])
 
Index: clang/unittests/AST/ASTImporterTest.cpp
===
--- clang/unittests/AST/ASTImporterTest.cpp
+++ clang/unittests/AST/ASTImporterTest.cpp
@@ -5122,6 +5122,51 @@
   EXPECT_EQ(ToLSize, F

[Lldb-commits] [PATCH] D64853: Fix CommandInterpreter for _regex-break with options

2019-07-17 Thread Tom Weaver via Phabricator via lldb-commits

TWeaver added inline comments.



Comment at: 
lldb/packages/Python/lldbsuite/test/functionalities/breakpoint/breakpoint_command/main.c:9
 
+#include 
+

Hi there,

this is a little nit picky, and I'm not entirely sure If im right in saying so, 
but, if this is a C++ file as denoted by the license header, then shouldn't 
this include by  rather than the c library stdlib.h?

thanks for your time
Tom




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D64853



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

[Lldb-commits] [PATCH] D64858: [lldb] Make log for ClangModulesDeclVendor's compiler flag less verbose

2019-07-17 Thread Raphael Isemann via Phabricator via lldb-commits

teemperor created this revision.
teemperor added a reviewer: shafik.
Herald added subscribers: lldb-commits, abidh.
Herald added a project: LLDB.

Currently the ClangModulesDeclVendor is spamming the expression log with the 
compiler flags it is using, which creates a log that looks like this:

  clang
  
  
   -fmodules
  
  
   -fimplicit-module-maps

This patch removes all these newlines and just prints the compiler flags in one 
line as you see in the command line:

  clang -fmodules -fimplicit-module-maps [...]


Repository:
  rLLDB LLDB

https://reviews.llvm.org/D64858

Files:
  lldb/source/Plugins/ExpressionParser/Clang/ClangModulesDeclVendor.cpp


Index: lldb/source/Plugins/ExpressionParser/Clang/ClangModulesDeclVendor.cpp
===
--- lldb/source/Plugins/ExpressionParser/Clang/ClangModulesDeclVendor.cpp
+++ lldb/source/Plugins/ExpressionParser/Clang/ClangModulesDeclVendor.cpp
@@ -632,21 +632,16 @@
   clang::CompilerInstance::createDiagnostics(new clang::DiagnosticOptions,
  new 
StoringDiagnosticConsumer);
 
-  Log *log(lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_EXPRESSIONS));
-  if (log)
-log->PutString("ClangModulesDeclVendor::Create()");
   std::vector compiler_invocation_argument_cstrs;
   compiler_invocation_argument_cstrs.reserve(
   compiler_invocation_arguments.size());
-  for (const std::string &arg : compiler_invocation_arguments) {
+  for (const std::string &arg : compiler_invocation_arguments)
 compiler_invocation_argument_cstrs.push_back(arg.c_str());
-if (log) {
-  log->PutString("\n  ");
-  log->PutString(arg);
-}
-  }
-  if (log)
-log->PutString("\n");
+
+  Log *log(lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_EXPRESSIONS));
+  LLDB_LOG(log, "ClangModulesDeclVendor's compiler flags {0:$[ ]}",
+   llvm::make_range(compiler_invocation_arguments.begin(),
+compiler_invocation_arguments.end()));
 
   std::shared_ptr invocation =
   
clang::createInvocationFromCommandLine(compiler_invocation_argument_cstrs,


Index: lldb/source/Plugins/ExpressionParser/Clang/ClangModulesDeclVendor.cpp
===
--- lldb/source/Plugins/ExpressionParser/Clang/ClangModulesDeclVendor.cpp
+++ lldb/source/Plugins/ExpressionParser/Clang/ClangModulesDeclVendor.cpp
@@ -632,21 +632,16 @@
   clang::CompilerInstance::createDiagnostics(new clang::DiagnosticOptions,
  new StoringDiagnosticConsumer);
 
-  Log *log(lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_EXPRESSIONS));
-  if (log)
-log->PutString("ClangModulesDeclVendor::Create()");
   std::vector compiler_invocation_argument_cstrs;
   compiler_invocation_argument_cstrs.reserve(
   compiler_invocation_arguments.size());
-  for (const std::string &arg : compiler_invocation_arguments) {
+  for (const std::string &arg : compiler_invocation_arguments)
 compiler_invocation_argument_cstrs.push_back(arg.c_str());
-if (log) {
-  log->PutString("\n  ");
-  log->PutString(arg);
-}
-  }
-  if (log)
-log->PutString("\n");
+
+  Log *log(lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_EXPRESSIONS));
+  LLDB_LOG(log, "ClangModulesDeclVendor's compiler flags {0:$[ ]}",
+   llvm::make_range(compiler_invocation_arguments.begin(),
+compiler_invocation_arguments.end()));
 
   std::shared_ptr invocation =
   clang::createInvocationFromCommandLine(compiler_invocation_argument_cstrs,
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D64824: [CMake] Move standalone check so we don't have to reconfigure LLDB

2019-07-17 Thread Stefan Gränitz via Phabricator via lldb-commits

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

LGTM


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D64824



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

[Lldb-commits] [lldb] r366316 - [lldb][NFC] Tablegenify watchpoint commands

2019-07-17 Thread Raphael Isemann via lldb-commits

Author: teemperor
Date: Wed Jul 17 04:48:29 2019
New Revision: 366316

URL: http://llvm.org/viewvc/llvm-project?rev=366316&view=rev
Log:
[lldb][NFC] Tablegenify watchpoint commands

Part of the project that migrates these struct initializers to our
new lldb-tablegen.

Modified:
lldb/trunk/source/Commands/CommandObjectWatchpoint.cpp
lldb/trunk/source/Commands/CommandObjectWatchpointCommand.cpp
lldb/trunk/source/Commands/Options.td

Modified: lldb/trunk/source/Commands/CommandObjectWatchpoint.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Commands/CommandObjectWatchpoint.cpp?rev=366316&r1=366315&r2=366316&view=diff
==
--- lldb/trunk/source/Commands/CommandObjectWatchpoint.cpp (original)
+++ lldb/trunk/source/Commands/CommandObjectWatchpoint.cpp Wed Jul 17 04:48:29 
2019
@@ -148,11 +148,8 @@ bool CommandObjectMultiwordWatchpoint::V
 #pragma mark List::CommandOptions
 
 static constexpr OptionDefinition g_watchpoint_list_options[] = {
-// clang-format off
-  { LLDB_OPT_SET_1, false, "brief",   'b', OptionParser::eNoArgument, nullptr, 
{}, 0, eArgTypeNone, "Give a brief description of the watchpoint (no location 
info)." },
-  { LLDB_OPT_SET_2, false, "full",'f', OptionParser::eNoArgument, nullptr, 
{}, 0, eArgTypeNone, "Give a full description of the watchpoint and its 
locations." },
-  { LLDB_OPT_SET_3, false, "verbose", 'v', OptionParser::eNoArgument, nullptr, 
{}, 0, eArgTypeNone, "Explain everything we know about the watchpoint (for 
debugging debugger bugs)." }
-// clang-format on
+#define LLDB_OPTIONS_watchpoint_list
+#include "CommandOptions.inc"
 };
 
 #pragma mark List
@@ -511,9 +508,8 @@ protected:
 
 #pragma mark Ignore::CommandOptions
 static constexpr OptionDefinition g_watchpoint_ignore_options[] = {
-// clang-format off
-  { LLDB_OPT_SET_ALL, true, "ignore-count", 'i', 
OptionParser::eRequiredArgument, nullptr, {}, 0, eArgTypeCount, "Set the number 
of times this watchpoint is skipped before stopping." }
-// clang-format on
+#define LLDB_OPTIONS_watchpoint_ignore
+#include "CommandOptions.inc"
 };
 
 class CommandObjectWatchpointIgnore : public CommandObjectParsed {
@@ -631,9 +627,8 @@ private:
 #pragma mark Modify::CommandOptions
 
 static constexpr OptionDefinition g_watchpoint_modify_options[] = {
-// clang-format off
-  { LLDB_OPT_SET_ALL, false, "condition", 'c', 
OptionParser::eRequiredArgument, nullptr, {}, 0, eArgTypeExpression, "The 
watchpoint stops only if this condition expression evaluates to true." }
-// clang-format on
+#define LLDB_OPTIONS_watchpoint_modify
+#include "CommandOptions.inc"
 };
 
 #pragma mark Modify

Modified: lldb/trunk/source/Commands/CommandObjectWatchpointCommand.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Commands/CommandObjectWatchpointCommand.cpp?rev=366316&r1=366315&r2=366316&view=diff
==
--- lldb/trunk/source/Commands/CommandObjectWatchpointCommand.cpp (original)
+++ lldb/trunk/source/Commands/CommandObjectWatchpointCommand.cpp Wed Jul 17 
04:48:29 2019
@@ -43,12 +43,8 @@ static constexpr OptionEnumValues Script
 }
 
 static constexpr OptionDefinition g_watchpoint_command_add_options[] = {
-// clang-format off
-  { LLDB_OPT_SET_1,   false, "one-liner",   'o', 
OptionParser::eRequiredArgument, nullptr, {}, 0, 
eArgTypeOneLiner,   "Specify a one-line watchpoint command inline. Be sure 
to surround it with quotes." },
-  { LLDB_OPT_SET_ALL, false, "stop-on-error",   'e', 
OptionParser::eRequiredArgument, nullptr, {}, 0, 
eArgTypeBoolean,"Specify whether watchpoint command execution should 
terminate on error." },
-  { LLDB_OPT_SET_ALL, false, "script-type", 's', 
OptionParser::eRequiredArgument, nullptr, ScriptOptionEnum(), 0, eArgTypeNone,  
 "Specify the language for the commands - if none is specified, the 
lldb command interpreter will be used." },
-  { LLDB_OPT_SET_2,   false, "python-function", 'F', 
OptionParser::eRequiredArgument, nullptr, {}, 0, 
eArgTypePythonFunction, "Give the name of a Python function to run as command 
for this watchpoint. Be sure to give a module name if appropriate." }
-// clang-format on
+#define LLDB_OPTIONS_watchpoint_command_add
+#include "CommandOptions.inc"
 };
 
 class CommandObjectWatchpointCommandAdd : public CommandObjectParsed,

Modified: lldb/trunk/source/Commands/Options.td
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Commands/Options.td?rev=366316&r1=366315&r2=366316&view=diff
==
--- lldb/trunk/source/Commands/Options.td (original)
+++ lldb/trunk/source/Commands/Options.td Wed Jul 17 04:48:29 2019
@@ -51,3 +51,41 @@ let Command = "breakpoint list" in {
 Desc<"List Dummy breakpoints - i.e. breakpoints set before

[Lldb-commits] [PATCH] D61333: [ASTImporter] Fix LLDB lookup in transparent ctx and with ext src

2019-07-17 Thread Raphael Isemann via Phabricator via lldb-commits

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

LGTM, thanks a lot for fixing this!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D61333



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

[Lldb-commits] [PATCH] D64823: [CMake] Default LLDB_PATH_TO_LLVM_BUILD to LLVM_DIR

2019-07-17 Thread Stefan Gränitz via Phabricator via lldb-commits

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

We shouldn't do the sole change here, but instead remove all 
`LLDB_PATH_TO__BUILD` variables in favor of CMake standard `_DIR` 
variables. Summarizing a discussion on this a while ago:

LLDB_PATH_TO_LLVM_BUILD used to be something like `/path/to/llvm-build-tree`
LLVM_DIR, however, is `/path/to/llvm-build-tree/lib/cmake/llvm`. Fine so far, 
but initializing..
LLDB_PATH_TO_CLANG_BUILD with the same value is incorrect, because it should be 
`/path/to/llvm-build-tree/lib/cmake/clang`!

In the past we also had (and downstream still have) things that would break, 
like:

  set(CLANG_RESOURCE_PATH 
"${LLDB_PATH_TO_CLANG_BUILD}/lib${LLVM_LIBDIR_SUFFIX}/clang/${CLANG_VERSION}")

Fortunately most of it was cleaned up in the meantime. It looks like the only 
remaining blocker is the one below.




Comment at: lldb/cmake/modules/LLDBStandalone.cmake:45
   if(CMAKE_CROSSCOMPILING)
 set(LLVM_NATIVE_BUILD "${LLDB_PATH_TO_LLVM_BUILD}/NATIVE")
 if (NOT EXISTS "${LLVM_NATIVE_BUILD}")

@xiaobai Can this be changed to something like `${LLVM_DIR}/../../../NATIVE`?


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D64823



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

[Lldb-commits] [PATCH] D64865: [CMake] Polish folders in generated Xcode project

2019-07-17 Thread Stefan Gränitz via Phabricator via lldb-commits

sgraenitz created this revision.
sgraenitz added reviewers: jingham, mib, stella.stamenova.
Herald added a subscriber: mgorny.
Herald added a project: LLDB.

Group plugins by subfolder. Move liblldb-resource-headers to `lldb misc`. Avoid 
install-distribution related targets in IDE-enabled builds.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D64865

Files:
  lldb/CMakeLists.txt
  lldb/cmake/modules/AddLLDB.cmake
  lldb/cmake/modules/LLDBFramework.cmake


Index: lldb/cmake/modules/LLDBFramework.cmake
===
--- lldb/cmake/modules/LLDBFramework.cmake
+++ lldb/cmake/modules/LLDBFramework.cmake
@@ -78,6 +78,7 @@
 
 # Wrap output in a target, so lldb-framework can depend on it.
 add_custom_target(liblldb-resource-headers DEPENDS ${lldb_staged_headers})
+set_target_properties(liblldb-resource-headers PROPERTIES FOLDER "lldb misc")
 add_dependencies(liblldb liblldb-resource-headers)
 
 # At build time, copy the staged headers into the framework bundle (and do
Index: lldb/cmake/modules/AddLLDB.cmake
===
--- lldb/cmake/modules/AddLLDB.cmake
+++ lldb/cmake/modules/AddLLDB.cmake
@@ -122,7 +122,11 @@
   target_compile_options(${name} PRIVATE ${PARAM_EXTRA_CXXFLAGS})
 
   if(PARAM_PLUGIN)
-set_target_properties(${name} PROPERTIES FOLDER "lldb plugins")
+get_property(parent_dir DIRECTORY PROPERTY PARENT_DIRECTORY)
+if(EXISTS ${parent_dir})
+  get_filename_component(category ${parent_dir} NAME)
+  set_target_properties(${name} PROPERTIES FOLDER "lldb 
plugins/${category}")
+endif()
   else()
 set_target_properties(${name} PROPERTIES FOLDER "lldb libraries")
   endif()
Index: lldb/CMakeLists.txt
===
--- lldb/CMakeLists.txt
+++ lldb/CMakeLists.txt
@@ -219,6 +219,6 @@
 endif ()
 endif ()
 
-if(LLDB_BUILT_STANDALONE)
+if(LLDB_BUILT_STANDALONE AND NOT LLVM_ENABLE_IDE)
   llvm_distribution_add_targets()
 endif()


Index: lldb/cmake/modules/LLDBFramework.cmake
===
--- lldb/cmake/modules/LLDBFramework.cmake
+++ lldb/cmake/modules/LLDBFramework.cmake
@@ -78,6 +78,7 @@
 
 # Wrap output in a target, so lldb-framework can depend on it.
 add_custom_target(liblldb-resource-headers DEPENDS ${lldb_staged_headers})
+set_target_properties(liblldb-resource-headers PROPERTIES FOLDER "lldb misc")
 add_dependencies(liblldb liblldb-resource-headers)
 
 # At build time, copy the staged headers into the framework bundle (and do
Index: lldb/cmake/modules/AddLLDB.cmake
===
--- lldb/cmake/modules/AddLLDB.cmake
+++ lldb/cmake/modules/AddLLDB.cmake
@@ -122,7 +122,11 @@
   target_compile_options(${name} PRIVATE ${PARAM_EXTRA_CXXFLAGS})
 
   if(PARAM_PLUGIN)
-set_target_properties(${name} PROPERTIES FOLDER "lldb plugins")
+get_property(parent_dir DIRECTORY PROPERTY PARENT_DIRECTORY)
+if(EXISTS ${parent_dir})
+  get_filename_component(category ${parent_dir} NAME)
+  set_target_properties(${name} PROPERTIES FOLDER "lldb plugins/${category}")
+endif()
   else()
 set_target_properties(${name} PROPERTIES FOLDER "lldb libraries")
   endif()
Index: lldb/CMakeLists.txt
===
--- lldb/CMakeLists.txt
+++ lldb/CMakeLists.txt
@@ -219,6 +219,6 @@
 endif ()
 endif ()
 
-if(LLDB_BUILT_STANDALONE)
+if(LLDB_BUILT_STANDALONE AND NOT LLVM_ENABLE_IDE)
   llvm_distribution_add_targets()
 endif()
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D64865: [CMake] Polish folders in generated Xcode project

2019-07-17 Thread Stefan Gränitz via Phabricator via lldb-commits

sgraenitz added a comment.

Should give this folder structure in Xcode standalone builds: F9605898: 
Screenshot 2019-07-17 at 15.11.54.png 
We try to cut the parent folder names from the leaf folders, but that gets a 
mess quickly as not all names are consistent with their parent directories.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D64865



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

[Lldb-commits] [PATCH] D61333: [ASTImporter] Fix LLDB lookup in transparent ctx and with ext src

2019-07-17 Thread Gabor Marton via Phabricator via lldb-commits

martong added a comment.

Thank you guys for the review!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D61333



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

[Lldb-commits] [PATCH] D61333: [ASTImporter] Fix LLDB lookup in transparent ctx and with ext src

2019-07-17 Thread Gabor Marton via Phabricator via lldb-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rL366325: [ASTImporter] Fix LLDB lookup in transparent ctx and 
with ext src (authored by martong, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D61333?vs=210281&id=210318#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D61333

Files:
  cfe/trunk/lib/AST/ASTImporter.cpp
  cfe/trunk/unittests/AST/ASTImporterTest.cpp
  lldb/trunk/packages/Python/lldbsuite/test/lang/c/modules/TestCModules.py
  lldb/trunk/packages/Python/lldbsuite/test/lang/c/modules/main.c
  lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangASTSource.cpp

Index: cfe/trunk/lib/AST/ASTImporter.cpp
===
--- cfe/trunk/lib/AST/ASTImporter.cpp
+++ cfe/trunk/lib/AST/ASTImporter.cpp
@@ -1707,6 +1707,17 @@
 
 Error ASTNodeImporter::ImportDefinition(
 RecordDecl *From, RecordDecl *To, ImportDefinitionKind Kind) {
+  auto DefinitionCompleter = [To]() {
+// There are cases in LLDB when we first import a class without its
+// members. The class will have DefinitionData, but no members. Then,
+// importDefinition is called from LLDB, which tries to get the members, so
+// when we get here, the class already has the DefinitionData set, so we
+// must unset the CompleteDefinition here to be able to complete again the
+// definition.
+To->setCompleteDefinition(false);
+To->completeDefinition();
+  };
+
   if (To->getDefinition() || To->isBeingDefined()) {
 if (Kind == IDK_Everything ||
 // In case of lambdas, the class already has a definition ptr set, but
@@ -1717,7 +1728,7 @@
   Error Result = ImportDeclContext(From, /*ForceImport=*/true);
   // Finish the definition of the lambda, set isBeingDefined to false.
   if (To->isLambda())
-To->completeDefinition();
+DefinitionCompleter();
   return Result;
 }
 
@@ -1728,8 +1739,8 @@
   // Complete the definition even if error is returned.
   // The RecordDecl may be already part of the AST so it is better to
   // have it in complete state even if something is wrong with it.
-  auto DefinitionCompleter =
-  llvm::make_scope_exit([To]() { To->completeDefinition(); });
+  auto DefinitionCompleterScopeExit =
+  llvm::make_scope_exit(DefinitionCompleter);
 
   if (Error Err = setTypedefNameForAnonDecl(From, To, Importer))
 return Err;
@@ -7757,10 +7768,20 @@
 SharedState->getLookupTable()->lookup(ReDC, Name);
 return FoundDeclsTy(LookupResult.begin(), LookupResult.end());
   } else {
-// FIXME Can we remove this kind of lookup?
-// Or lldb really needs this C/C++ lookup?
-FoundDeclsTy Result;
-ReDC->localUncachedLookup(Name, Result);
+DeclContext::lookup_result NoloadLookupResult = ReDC->noload_lookup(Name);
+FoundDeclsTy Result(NoloadLookupResult.begin(), NoloadLookupResult.end());
+// We must search by the slow case of localUncachedLookup because that is
+// working even if there is no LookupPtr for the DC. We could use
+// DC::buildLookup() to create the LookupPtr, but that would load external
+// decls again, we must avoid that case.
+// Also, even if we had the LookupPtr, we must find Decls which are not
+// in the LookupPtr, so we need the slow case.
+// These cases are handled in ASTImporterLookupTable, but we cannot use
+// that with LLDB since that traverses through the AST which initiates the
+// load of external decls again via DC::decls().  And again, we must avoid
+// loading external decls during the import.
+if (Result.empty())
+  ReDC->localUncachedLookup(Name, Result);
 return Result;
   }
 }
Index: cfe/trunk/unittests/AST/ASTImporterTest.cpp
===
--- cfe/trunk/unittests/AST/ASTImporterTest.cpp
+++ cfe/trunk/unittests/AST/ASTImporterTest.cpp
@@ -5122,6 +5122,51 @@
   EXPECT_EQ(ToLSize, FromLSize);
 }
 
+struct LLDBLookupTest : ASTImporterOptionSpecificTestBase {
+  LLDBLookupTest() {
+Creator = [](ASTContext &ToContext, FileManager &ToFileManager,
+ ASTContext &FromContext, FileManager &FromFileManager,
+ bool MinimalImport,
+ const std::shared_ptr &SharedState) {
+  return new ASTImporter(ToContext, ToFileManager, FromContext,
+ FromFileManager, MinimalImport,
+ // We use the regular lookup.
+ /*SharedState=*/nullptr);
+};
+  }
+};
+
+TEST_P(LLDBLookupTest, ImporterShouldFindInTransparentContext) {
+  TranslationUnitDecl *ToTU = getToTuDecl(
+  R"(
+  extern "C" {
+class X{};
+  };
+  )",
+  Lang_CXX);
+  auto *ToX = FirstDeclMatcher().match(
+  ToTU, cxxRecordDecl(ha

[Lldb-commits] [PATCH] D61333: [ASTImporter] Fix LLDB lookup in transparent ctx and with ext src

2019-07-17 Thread Gabor Marton via Phabricator via lldb-commits

martong added a comment.

Jenkins looks okay: 
http://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/31157/ .The build is 
red but the the previous run has the very same failing test case:
expression_command/weak_symbols/TestWeakSymbols.py


Repository:
  rL LLVM

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

https://reviews.llvm.org/D61333



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

[Lldb-commits] [PATCH] D64853: Fix CommandInterpreter for _regex-break with options

2019-07-17 Thread Davide Italiano via Phabricator via lldb-commits

davide added inline comments.



Comment at: 
lldb/packages/Python/lldbsuite/test/functionalities/breakpoint/breakpoint_command/main.c:9
 
+#include 
+

TWeaver wrote:
> Hi there,
> 
> this is a little nit picky, and I'm not entirely sure If im right in saying 
> so, but, if this is a C++ file as denoted by the license header, then 
> shouldn't this include by  rather than the c library stdlib.h?
> 
> thanks for your time
> Tom
> 
> 
This is definitely a C file, the header is wrong.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D64853



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

[Lldb-commits] [PATCH] D64853: Fix CommandInterpreter for _regex-break with options

2019-07-17 Thread Davide Italiano via Phabricator via lldb-commits

davide added subscribers: jasonmolenda, compnerd.
davide added inline comments.



Comment at: 
lldb/packages/Python/lldbsuite/test/functionalities/breakpoint/breakpoint_command/TestRegexpBreakCommand.py:212-215
+
+module_name = "libsystem_malloc.dylib"
+if not os_description == "Darwin":
+module_name = "libc.so"

Something like this will definitely break on Windows (@compnerd), so you 
probably need to generalize this test or skip it there. Also, what about other 
platforms, e.g. iOS? (@jasonmolenda)



Comment at: 
lldb/packages/Python/lldbsuite/test/functionalities/breakpoint/breakpoint_command/main.c:17
 var++;
+malloc(sizeof(int));
 return 0; // Set break point at this line.

Not that it matters a lot, but I would free this memory before returning.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D64853



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

[Lldb-commits] [PATCH] D64853: Fix CommandInterpreter for _regex-break with options

2019-07-17 Thread Davide Italiano via Phabricator via lldb-commits

davide added inline comments.



Comment at: 
lldb/packages/Python/lldbsuite/test/functionalities/breakpoint/breakpoint_command/TestRegexpBreakCommand.py:242-257
+break_results = lldbutil.run_break_set_command(
+self, "b /%s/" %
+self.regex)
+lldbutil.check_breakpoint_result(
+self,
+break_results,
+file_name='main.c',

I was under the impression this could be expressed more concisely [Jim has an 
utility for doing that, so he might point you in the right direction]


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D64853



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

[Lldb-commits] [PATCH] D64853: Fix CommandInterpreter for _regex-break with options

2019-07-17 Thread Pavel Labath via Phabricator via lldb-commits

labath added inline comments.



Comment at: 
lldb/packages/Python/lldbsuite/test/functionalities/breakpoint/breakpoint_command/TestRegexpBreakCommand.py:212-215
+
+module_name = "libsystem_malloc.dylib"
+if not os_description == "Darwin":
+module_name = "libc.so"

davide wrote:
> Something like this will definitely break on Windows (@compnerd), so you 
> probably need to generalize this test or skip it there. Also, what about 
> other platforms, e.g. iOS? (@jasonmolenda)
The best thing to do here is to build a shared library as a part of the test. 
This way, you can control exactly which symbols are present inside it. There 
are examples of building shared libraries in the test suite (TestLoadUnload 
comes to mind..)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D64853



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

[Lldb-commits] [PATCH] D64769: [lldb][test_suite] change the test main.cpp to avoid expression reschedule

2019-07-17 Thread Davide Italiano via Phabricator via lldb-commits

davide added a comment.

That real

In D64769#1587992 , @kusmour wrote:

> In D64769#1587318 , @labath wrote:
>
> > The change is fine, but for my own education, could you elaborate on what 
> > this "delayed calculation" is, and how does it make the test fail?
>
>
> The test set the breakpoint to the return statement, even thought the 
> compiler flag `-O0` was set, the first hit to that bp showed that `g_common_1 
> = 0` which actually should be 21. The test assume when we hit the return 
> statement, the value should already be calculated, but that's not the case 
> for NDK20 clang.
>
> So we reproduce the test manually, turned out that the value was calculated 
> later. lldb first hit the return statement then jump back to line 20. By 
> looking at the assembly that clang provided, it indeed jump back and forth.
>
> It's possible that the jumping behavior is caused by optimization, 
> considering there're some other tests having similar problem, and the 
> behavior changed a lot from NDK 19 to 20. I made this change because this is 
> irrelevant to testing global variables.


that really sounds like a DebugInfo problem. Can you reproduce on ToT?


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D64769



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

[Lldb-commits] [PATCH] D64858: [lldb] Make log for ClangModulesDeclVendor's compiler flag less verbose

2019-07-17 Thread Davide Italiano via Phabricator via lldb-commits

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

This looks good. If it bothers you a lot (given you're probably one of the few 
users), you can do this only under `verbose` (although now that's a single line 
is very concise).


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D64858



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

[Lldb-commits] [PATCH] D64858: [lldb] Make log for ClangModulesDeclVendor's compiler flag less verbose

2019-07-17 Thread Shafik Yaghmour via Phabricator via lldb-commits

shafik added a comment.

Is it worth it to write a test that verifies the output? Otherwise LGTM.


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D64858



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

[Lldb-commits] [PATCH] D64858: [lldb] Make log for ClangModulesDeclVendor's compiler flag less verbose

2019-07-17 Thread Davide Italiano via Phabricator via lldb-commits

davide added a comment.

I don't think it's worth adding a test for the logs.


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D64858



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

[Lldb-commits] [lldb] r366346 - [CMake] Move standalone check so we don't have to reconfigure LLDB

2019-07-17 Thread Jonas Devlieghere via lldb-commits

Author: jdevlieghere
Date: Wed Jul 17 09:47:02 2019
New Revision: 366346

URL: http://llvm.org/viewvc/llvm-project?rev=366346&view=rev
Log:
[CMake] Move standalone check so we don't have to reconfigure LLDB

By moving the standalone check into the main CMake file, the whole file
is ignored in a regular (non-standalone) build. This means that you can
make changes to LLDBStandalone.cmake without having to reconfigure a
build in a different directory. This matters when you share one source
repository with different build directories (e.g. release-assert, debug,
standalone).

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

Modified:
lldb/trunk/CMakeLists.txt
lldb/trunk/cmake/modules/LLDBStandalone.cmake

Modified: lldb/trunk/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/CMakeLists.txt?rev=366346&r1=366345&r2=366346&view=diff
==
--- lldb/trunk/CMakeLists.txt (original)
+++ lldb/trunk/CMakeLists.txt Wed Jul 17 09:47:02 2019
@@ -11,7 +11,12 @@ set(CMAKE_MODULE_PATH
   "${CMAKE_CURRENT_SOURCE_DIR}/cmake/modules"
   )
 
-include(LLDBStandalone)
+# If we are not building as part of LLVM, build LLDB as a standalone project,
+# using LLVM as an external library.
+if (CMAKE_SOURCE_DIR STREQUAL CMAKE_CURRENT_SOURCE_DIR)
+  include(LLDBStandalone)
+endif()
+
 include(LLDBConfig)
 include(AddLLDB)
 

Modified: lldb/trunk/cmake/modules/LLDBStandalone.cmake
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/cmake/modules/LLDBStandalone.cmake?rev=366346&r1=366345&r2=366346&view=diff
==
--- lldb/trunk/cmake/modules/LLDBStandalone.cmake (original)
+++ lldb/trunk/cmake/modules/LLDBStandalone.cmake Wed Jul 17 09:47:02 2019
@@ -1,3 +1,30 @@
+project(lldb)
+
+option(LLVM_INSTALL_TOOLCHAIN_ONLY "Only include toolchain files in the 
'install' target." OFF)
+
+set(LLDB_PATH_TO_LLVM_BUILD "" CACHE PATH "Path to LLVM build tree")
+set(LLDB_PATH_TO_CLANG_BUILD "${LLDB_PATH_TO_LLVM_BUILD}" CACHE PATH "Path to 
Clang build tree")
+
+file(TO_CMAKE_PATH "${LLDB_PATH_TO_LLVM_BUILD}" LLDB_PATH_TO_LLVM_BUILD)
+file(TO_CMAKE_PATH "${LLDB_PATH_TO_CLANG_BUILD}" LLDB_PATH_TO_CLANG_BUILD)
+
+find_package(LLVM REQUIRED CONFIG
+  HINTS "${LLDB_PATH_TO_LLVM_BUILD}" NO_CMAKE_FIND_ROOT_PATH)
+find_package(Clang REQUIRED CONFIG
+  HINTS "${LLDB_PATH_TO_CLANG_BUILD}" NO_CMAKE_FIND_ROOT_PATH)
+
+# We set LLVM_CMAKE_PATH so that GetSVN.cmake is found correctly when building 
SVNVersion.inc
+set(LLVM_CMAKE_PATH ${LLVM_CMAKE_DIR} CACHE PATH "Path to LLVM CMake modules")
+
+set(LLVM_MAIN_SRC_DIR ${LLVM_BUILD_MAIN_SRC_DIR} CACHE PATH "Path to LLVM 
source tree")
+set(LLVM_MAIN_INCLUDE_DIR ${LLVM_MAIN_INCLUDE_DIR} CACHE PATH "Path to 
llvm/include")
+set(LLVM_BINARY_DIR ${LLVM_BINARY_DIR} CACHE PATH "Path to LLVM build tree")
+
+set(lit_file_name "llvm-lit")
+if(CMAKE_HOST_WIN32 AND NOT CYGWIN)
+  set(lit_file_name "${lit_file_name}.py")
+endif()
+
 function(append_configuration_directories input_dir output_dirs)
   set(dirs_list ${input_dir})
   foreach(config_type ${LLVM_CONFIGURATION_TYPES})
@@ -7,118 +34,88 @@ function(append_configuration_directorie
   set(${output_dirs} ${dirs_list} PARENT_SCOPE)
 endfunction()
 
-# If we are not building as a part of LLVM, build LLDB as an
-# standalone project, using LLVM as an external library:
-if (CMAKE_SOURCE_DIR STREQUAL CMAKE_CURRENT_SOURCE_DIR)
-  project(lldb)
-
-  option(LLVM_INSTALL_TOOLCHAIN_ONLY "Only include toolchain files in the 
'install' target." OFF)
-
-  set(LLDB_PATH_TO_LLVM_BUILD "" CACHE PATH "Path to LLVM build tree")
-  set(LLDB_PATH_TO_CLANG_BUILD "${LLDB_PATH_TO_LLVM_BUILD}" CACHE PATH "Path 
to Clang build tree")
-
-  file(TO_CMAKE_PATH "${LLDB_PATH_TO_LLVM_BUILD}" LLDB_PATH_TO_LLVM_BUILD)
-  file(TO_CMAKE_PATH "${LLDB_PATH_TO_CLANG_BUILD}" LLDB_PATH_TO_CLANG_BUILD)
-
-  find_package(LLVM REQUIRED CONFIG
-HINTS "${LLDB_PATH_TO_LLVM_BUILD}" NO_CMAKE_FIND_ROOT_PATH)
-  find_package(Clang REQUIRED CONFIG
-HINTS "${LLDB_PATH_TO_CLANG_BUILD}" NO_CMAKE_FIND_ROOT_PATH)
-
-  # We set LLVM_CMAKE_PATH so that GetSVN.cmake is found correctly when 
building SVNVersion.inc
-  set(LLVM_CMAKE_PATH ${LLVM_CMAKE_DIR} CACHE PATH "Path to LLVM CMake 
modules")
-
-  set(LLVM_MAIN_SRC_DIR ${LLVM_BUILD_MAIN_SRC_DIR} CACHE PATH "Path to LLVM 
source tree")
-  set(LLVM_MAIN_INCLUDE_DIR ${LLVM_MAIN_INCLUDE_DIR} CACHE PATH "Path to 
llvm/include")
-  set(LLVM_BINARY_DIR ${LLVM_BINARY_DIR} CACHE PATH "Path to LLVM build tree")
-
-  set(lit_file_name "llvm-lit")
-  if(CMAKE_HOST_WIN32 AND NOT CYGWIN)
-set(lit_file_name "${lit_file_name}.py")
-  endif()
-
-  append_configuration_directories(${LLVM_TOOLS_BINARY_DIR} config_dirs)
-  find_program(lit_full_path ${lit_file_name} ${config_dirs} NO_DEFAULT_PATH)
-  set(LLVM_DEFAULT_EXTERNAL_LIT ${lit_full_path} CACHE PATH "Path to llvm-lit")
 
-  if(CMAKE_CROSSCOMPILING)
-set

[Lldb-commits] [PATCH] D64824: [CMake] Move standalone check so we don't have to reconfigure LLDB

2019-07-17 Thread Jonas Devlieghere via Phabricator via lldb-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rL366346: [CMake] Move standalone check so we don't have 
to reconfigure LLDB (authored by JDevlieghere, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D64824?vs=210185&id=210352#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D64824

Files:
  lldb/trunk/CMakeLists.txt
  lldb/trunk/cmake/modules/LLDBStandalone.cmake

Index: lldb/trunk/cmake/modules/LLDBStandalone.cmake
===
--- lldb/trunk/cmake/modules/LLDBStandalone.cmake
+++ lldb/trunk/cmake/modules/LLDBStandalone.cmake
@@ -1,3 +1,30 @@
+project(lldb)
+
+option(LLVM_INSTALL_TOOLCHAIN_ONLY "Only include toolchain files in the 'install' target." OFF)
+
+set(LLDB_PATH_TO_LLVM_BUILD "" CACHE PATH "Path to LLVM build tree")
+set(LLDB_PATH_TO_CLANG_BUILD "${LLDB_PATH_TO_LLVM_BUILD}" CACHE PATH "Path to Clang build tree")
+
+file(TO_CMAKE_PATH "${LLDB_PATH_TO_LLVM_BUILD}" LLDB_PATH_TO_LLVM_BUILD)
+file(TO_CMAKE_PATH "${LLDB_PATH_TO_CLANG_BUILD}" LLDB_PATH_TO_CLANG_BUILD)
+
+find_package(LLVM REQUIRED CONFIG
+  HINTS "${LLDB_PATH_TO_LLVM_BUILD}" NO_CMAKE_FIND_ROOT_PATH)
+find_package(Clang REQUIRED CONFIG
+  HINTS "${LLDB_PATH_TO_CLANG_BUILD}" NO_CMAKE_FIND_ROOT_PATH)
+
+# We set LLVM_CMAKE_PATH so that GetSVN.cmake is found correctly when building SVNVersion.inc
+set(LLVM_CMAKE_PATH ${LLVM_CMAKE_DIR} CACHE PATH "Path to LLVM CMake modules")
+
+set(LLVM_MAIN_SRC_DIR ${LLVM_BUILD_MAIN_SRC_DIR} CACHE PATH "Path to LLVM source tree")
+set(LLVM_MAIN_INCLUDE_DIR ${LLVM_MAIN_INCLUDE_DIR} CACHE PATH "Path to llvm/include")
+set(LLVM_BINARY_DIR ${LLVM_BINARY_DIR} CACHE PATH "Path to LLVM build tree")
+
+set(lit_file_name "llvm-lit")
+if(CMAKE_HOST_WIN32 AND NOT CYGWIN)
+  set(lit_file_name "${lit_file_name}.py")
+endif()
+
 function(append_configuration_directories input_dir output_dirs)
   set(dirs_list ${input_dir})
   foreach(config_type ${LLVM_CONFIGURATION_TYPES})
@@ -7,118 +34,88 @@
   set(${output_dirs} ${dirs_list} PARENT_SCOPE)
 endfunction()
 
-# If we are not building as a part of LLVM, build LLDB as an
-# standalone project, using LLVM as an external library:
-if (CMAKE_SOURCE_DIR STREQUAL CMAKE_CURRENT_SOURCE_DIR)
-  project(lldb)
-
-  option(LLVM_INSTALL_TOOLCHAIN_ONLY "Only include toolchain files in the 'install' target." OFF)
-
-  set(LLDB_PATH_TO_LLVM_BUILD "" CACHE PATH "Path to LLVM build tree")
-  set(LLDB_PATH_TO_CLANG_BUILD "${LLDB_PATH_TO_LLVM_BUILD}" CACHE PATH "Path to Clang build tree")
-
-  file(TO_CMAKE_PATH "${LLDB_PATH_TO_LLVM_BUILD}" LLDB_PATH_TO_LLVM_BUILD)
-  file(TO_CMAKE_PATH "${LLDB_PATH_TO_CLANG_BUILD}" LLDB_PATH_TO_CLANG_BUILD)
-
-  find_package(LLVM REQUIRED CONFIG
-HINTS "${LLDB_PATH_TO_LLVM_BUILD}" NO_CMAKE_FIND_ROOT_PATH)
-  find_package(Clang REQUIRED CONFIG
-HINTS "${LLDB_PATH_TO_CLANG_BUILD}" NO_CMAKE_FIND_ROOT_PATH)
-
-  # We set LLVM_CMAKE_PATH so that GetSVN.cmake is found correctly when building SVNVersion.inc
-  set(LLVM_CMAKE_PATH ${LLVM_CMAKE_DIR} CACHE PATH "Path to LLVM CMake modules")
-
-  set(LLVM_MAIN_SRC_DIR ${LLVM_BUILD_MAIN_SRC_DIR} CACHE PATH "Path to LLVM source tree")
-  set(LLVM_MAIN_INCLUDE_DIR ${LLVM_MAIN_INCLUDE_DIR} CACHE PATH "Path to llvm/include")
-  set(LLVM_BINARY_DIR ${LLVM_BINARY_DIR} CACHE PATH "Path to LLVM build tree")
-
-  set(lit_file_name "llvm-lit")
-  if(CMAKE_HOST_WIN32 AND NOT CYGWIN)
-set(lit_file_name "${lit_file_name}.py")
-  endif()
-
-  append_configuration_directories(${LLVM_TOOLS_BINARY_DIR} config_dirs)
-  find_program(lit_full_path ${lit_file_name} ${config_dirs} NO_DEFAULT_PATH)
-  set(LLVM_DEFAULT_EXTERNAL_LIT ${lit_full_path} CACHE PATH "Path to llvm-lit")
 
-  if(CMAKE_CROSSCOMPILING)
-set(LLVM_NATIVE_BUILD "${LLDB_PATH_TO_LLVM_BUILD}/NATIVE")
-if (NOT EXISTS "${LLVM_NATIVE_BUILD}")
-  message(FATAL_ERROR
-"Attempting to cross-compile LLDB standalone but no native LLVM build
-found. Please cross-compile LLVM as well.")
-endif()
-
-if (CMAKE_HOST_SYSTEM_NAME MATCHES "Windows")
-  set(HOST_EXECUTABLE_SUFFIX ".exe")
-endif()
-
-if (NOT CMAKE_CONFIGURATION_TYPES)
-  set(LLVM_TABLEGEN_EXE
-"${LLVM_NATIVE_BUILD}/bin/llvm-tblgen${HOST_EXECUTABLE_SUFFIX}")
-else()
-  # NOTE: LLVM NATIVE build is always built Release, as is specified in
-  # CrossCompile.cmake
-  set(LLVM_TABLEGEN_EXE
-"${LLVM_NATIVE_BUILD}/Release/bin/llvm-tblgen${HOST_EXECUTABLE_SUFFIX}")
-endif()
-  else()
-set(tblgen_file_name "llvm-tblgen${CMAKE_EXECUTABLE_SUFFIX}")
-append_configuration_directories(${LLVM_TOOLS_BINARY_DIR} config_dirs)
-find_program(LLVM_TABLEGEN_EXE ${tblgen_file_name} ${config_dirs} NO_DEFAULT_PATH)
+append_configuration_directories(${LLVM_TOOLS_BINARY_DIR} config_dirs

[Lldb-commits] [lldb] r366347 - [lldb] Make log for ClangModulesDeclVendor's compiler flag less verbose

2019-07-17 Thread Raphael Isemann via lldb-commits

Author: teemperor
Date: Wed Jul 17 09:51:16 2019
New Revision: 366347

URL: http://llvm.org/viewvc/llvm-project?rev=366347&view=rev
Log:
[lldb] Make log for ClangModulesDeclVendor's compiler flag less verbose

Summary:
Currently the ClangModulesDeclVendor is spamming the expression log with the 
compiler flags it is using, which creates a log that looks like this:

```
clang

 -fmodules

 -fimplicit-module-maps
```

This patch removes all these newlines and just prints the compiler flags in one 
line as you see in the command line:

```
clang -fmodules -fimplicit-module-maps [...]
```

Reviewers: shafik, davide

Reviewed By: davide

Subscribers: davide, abidh, lldb-commits

Tags: #lldb

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

Modified:
lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangModulesDeclVendor.cpp

Modified: 
lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangModulesDeclVendor.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangModulesDeclVendor.cpp?rev=366347&r1=366346&r2=366347&view=diff
==
--- lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangModulesDeclVendor.cpp 
(original)
+++ lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangModulesDeclVendor.cpp 
Wed Jul 17 09:51:16 2019
@@ -632,21 +632,16 @@ ClangModulesDeclVendor::Create(Target &t
   clang::CompilerInstance::createDiagnostics(new clang::DiagnosticOptions,
  new 
StoringDiagnosticConsumer);
 
-  Log *log(lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_EXPRESSIONS));
-  if (log)
-log->PutString("ClangModulesDeclVendor::Create()");
   std::vector compiler_invocation_argument_cstrs;
   compiler_invocation_argument_cstrs.reserve(
   compiler_invocation_arguments.size());
-  for (const std::string &arg : compiler_invocation_arguments) {
+  for (const std::string &arg : compiler_invocation_arguments)
 compiler_invocation_argument_cstrs.push_back(arg.c_str());
-if (log) {
-  log->PutString("\n  ");
-  log->PutString(arg);
-}
-  }
-  if (log)
-log->PutString("\n");
+
+  Log *log(lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_EXPRESSIONS));
+  LLDB_LOG(log, "ClangModulesDeclVendor's compiler flags {0:$[ ]}",
+   llvm::make_range(compiler_invocation_arguments.begin(),
+compiler_invocation_arguments.end()));
 
   std::shared_ptr invocation =
   
clang::createInvocationFromCommandLine(compiler_invocation_argument_cstrs,


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

[Lldb-commits] [PATCH] D64858: [lldb] Make log for ClangModulesDeclVendor's compiler flag less verbose

2019-07-17 Thread Raphael Isemann via Phabricator via lldb-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rL366347: [lldb] Make log for ClangModulesDeclVendor's 
compiler flag less verbose (authored by teemperor, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D64858?vs=210285&id=210355#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D64858

Files:
  lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangModulesDeclVendor.cpp


Index: 
lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangModulesDeclVendor.cpp
===
--- lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangModulesDeclVendor.cpp
+++ lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangModulesDeclVendor.cpp
@@ -632,21 +632,16 @@
   clang::CompilerInstance::createDiagnostics(new clang::DiagnosticOptions,
  new 
StoringDiagnosticConsumer);
 
-  Log *log(lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_EXPRESSIONS));
-  if (log)
-log->PutString("ClangModulesDeclVendor::Create()");
   std::vector compiler_invocation_argument_cstrs;
   compiler_invocation_argument_cstrs.reserve(
   compiler_invocation_arguments.size());
-  for (const std::string &arg : compiler_invocation_arguments) {
+  for (const std::string &arg : compiler_invocation_arguments)
 compiler_invocation_argument_cstrs.push_back(arg.c_str());
-if (log) {
-  log->PutString("\n  ");
-  log->PutString(arg);
-}
-  }
-  if (log)
-log->PutString("\n");
+
+  Log *log(lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_EXPRESSIONS));
+  LLDB_LOG(log, "ClangModulesDeclVendor's compiler flags {0:$[ ]}",
+   llvm::make_range(compiler_invocation_arguments.begin(),
+compiler_invocation_arguments.end()));
 
   std::shared_ptr invocation =
   
clang::createInvocationFromCommandLine(compiler_invocation_argument_cstrs,


Index: lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangModulesDeclVendor.cpp
===
--- lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangModulesDeclVendor.cpp
+++ lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangModulesDeclVendor.cpp
@@ -632,21 +632,16 @@
   clang::CompilerInstance::createDiagnostics(new clang::DiagnosticOptions,
  new StoringDiagnosticConsumer);
 
-  Log *log(lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_EXPRESSIONS));
-  if (log)
-log->PutString("ClangModulesDeclVendor::Create()");
   std::vector compiler_invocation_argument_cstrs;
   compiler_invocation_argument_cstrs.reserve(
   compiler_invocation_arguments.size());
-  for (const std::string &arg : compiler_invocation_arguments) {
+  for (const std::string &arg : compiler_invocation_arguments)
 compiler_invocation_argument_cstrs.push_back(arg.c_str());
-if (log) {
-  log->PutString("\n  ");
-  log->PutString(arg);
-}
-  }
-  if (log)
-log->PutString("\n");
+
+  Log *log(lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_EXPRESSIONS));
+  LLDB_LOG(log, "ClangModulesDeclVendor's compiler flags {0:$[ ]}",
+   llvm::make_range(compiler_invocation_arguments.begin(),
+compiler_invocation_arguments.end()));
 
   std::shared_ptr invocation =
   clang::createInvocationFromCommandLine(compiler_invocation_argument_cstrs,
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D64013: Correctly use GetLoadedModuleList to take advantage of libraries-svr4

2019-07-17 Thread António Afonso via Phabricator via lldb-commits

aadsm marked an inline comment as done.
aadsm added inline comments.

Comment at: 
lldb/source/Plugins/DynamicLoader/POSIX-DYLD/DYLDRendezvous.cpp:185-207
+  if (
+  // When the previous and current states are consistent this is the first
+  // time we have been asked to update.  Just take a snapshot of the
+  // currently loaded modules.
+  (m_previous.state == eConsistent && m_current.state == eConsistent) ||
+  // If we are about to add or remove a shared object clear out the current
+  // state and take a snapshot of the currently loaded images.

labath wrote:
> This logic is pretty hard to follow. I'd suggest trying to structure as some 
> switch statements. Something like:
> ```
> switch(current_state) {
> case Consistent:
>   switch (previous_state) {
> case Consistent: return TakeSnapshot;
> case Add: return Add;
> case Remove: return Remove;
>   }
> case Add: case Remove:
>   @#%@#%!@%
> }
> ```
Interesting, I actually think it's easier to follow than breaking it down to 
nested switches. I wanted to code to reflect the mental model that decides 
which action to take.

That's why I structured it in the way of:
```
if (state A) do action 1
if (state B) do action 2
...
```
The switch statement basically creates a logic decision tree that I personally 
find harder to follow. If I want to know what states makes us take a snapshot I 
need to search the entire code for return eTakeSnapshot and then go up the 
nested switch for each one of them and collect all the cases. In the other one 
I can focus my attention just to the condition for "do action 1".

Here's how it looks like:
```
switch (m_current.state) {
case eConsistent:
  switch (m_previous.state) {
case eConsistent: return eTakeSnapshot;
case eAdd: return eAddModules;
case eDelete: return eRemoveModules;
  }
  break;
case eAdd:
case eDelete: 
  switch (m_previous.state) {
case eConsistent: return eTakeSnapshot;
case eAdd: if (m_current.state == eDelete)
  return eTakeSnapshot;
  }
  }

  return eNoAction;
```

I also wanted to make the hacks a bit more obvious so I came up with this which 
I think strikes a good balance in making the decision clear and isolates the 
hack we have for android loaders:

```
if (m_current.state == eConsistent) {
switch (m_previous.state) {
  // When the previous and current states are consistent this is the first
  // time we have been asked to update.  Just take a snapshot of the
  // currently loaded modules.
  case eConsistent: return eTakeSnapshot;
  // If we are about to add or remove a shared object clear out the current
  // state and take a snapshot of the currently loaded images.
  case eAdd: return eAddModules;
  case eDelete: return eRemoveModules;
}
return eNoAction;
  }

  if (m_current.state == eAdd || m_current.state == eDelete) {
// Some versions of the android dynamic linker might send two
// notifications with state == eAdd back to back. Ignore them until we
// get an eConsistent notification.
if (!(m_previous.state == eConsistent ||
  (m_previous.state == eAdd && m_current.state == eDelete)))
  return eNoAction;

return eTakeSnapshot;
  }

  return eNoAction;
```

Thoughts?

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D64013

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

[Lldb-commits] [PATCH] D64806: [CMake] Always build debugserver on Darwin and allow tests to use the system's one

2019-07-17 Thread Stefan Gränitz via Phabricator via lldb-commits

sgraenitz updated this revision to Diff 210357.
sgraenitz added a comment.

Don't pass `ON`/`OFF` for `LLDB_SERVER_IS_DEBUGSERVER` as it becomes as #define


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D64806

Files:
  lldb/CMakeLists.txt
  lldb/cmake/modules/AddLLDB.cmake
  lldb/cmake/modules/LLDBConfig.cmake
  lldb/test/CMakeLists.txt
  lldb/tools/debugserver/source/CMakeLists.txt
  lldb/unittests/CMakeLists.txt
  lldb/unittests/tools/lldb-server/CMakeLists.txt

Index: lldb/unittests/tools/lldb-server/CMakeLists.txt
===
--- lldb/unittests/tools/lldb-server/CMakeLists.txt
+++ lldb/unittests/tools/lldb-server/CMakeLists.txt
@@ -13,8 +13,13 @@
 add_lldb_test_executable(thread_inferior inferior/thread_inferior.cpp)
 add_lldb_test_executable(environment_check inferior/environment_check.cpp)
 
-if(DEBUGSERVER_PATH)
-  add_definitions(-DLLDB_SERVER="${DEBUGSERVER_PATH}" -DLLDB_SERVER_IS_DEBUGSERVER=1)
+if(LLDB_CAN_USE_DEBUGSERVER)
+  if(LLDB_USE_SYSTEM_DEBUGSERVER)
+lldb_find_system_debugserver(debugserver_path)
+  else()
+set(debugserver_path $)
+  endif()
+  add_definitions(-DLLDB_SERVER="${debugserver_path}" -DLLDB_SERVER_IS_DEBUGSERVER=1)
 else()
   add_definitions(-DLLDB_SERVER="$" -DLLDB_SERVER_IS_DEBUGSERVER=0)
 endif()
Index: lldb/unittests/CMakeLists.txt
===
--- lldb/unittests/CMakeLists.txt
+++ lldb/unittests/CMakeLists.txt
@@ -78,6 +78,6 @@
 add_subdirectory(UnwindAssembly)
 add_subdirectory(Utility)
 
-if(LLDB_CAN_USE_DEBUGSERVER AND NOT SKIP_TEST_DEBUGSERVER)
+if(LLDB_CAN_USE_DEBUGSERVER AND NOT LLDB_USE_SYSTEM_DEBUGSERVER)
   add_subdirectory(debugserver)
 endif()
Index: lldb/tools/debugserver/source/CMakeLists.txt
===
--- lldb/tools/debugserver/source/CMakeLists.txt
+++ lldb/tools/debugserver/source/CMakeLists.txt
@@ -6,6 +6,58 @@
 
 include_directories(MacOSX)
 
+function(check_certificate identity result_valid)
+  execute_process(
+COMMAND security find-certificate -Z -p -c ${identity} /Library/Keychains/System.keychain
+RESULT_VARIABLE exit_code OUTPUT_QUIET ERROR_QUIET)
+  if(exit_code)
+set(${result_valid} FALSE PARENT_SCOPE)
+  else()
+set(${result_valid} TRUE PARENT_SCOPE)
+  endif()
+endfunction()
+
+function(get_debugserver_codesign_identity result)
+  string(CONCAT not_found_help
+"This will cause failures in the test suite."
+"Pass '-DLLDB_USE_SYSTEM_DEBUGSERVER=ON' to use the system one instead."
+"See 'Code Signing on macOS' in the documentation."
+  )
+
+  # Explicit override: warn if unavailable
+  if(LLDB_CODESIGN_IDENTITY)
+set(${result} ${LLDB_CODESIGN_IDENTITY} PARENT_SCOPE)
+check_certificate(${LLDB_CODESIGN_IDENTITY} available)
+if(NOT available AND NOT LLDB_USE_SYSTEM_DEBUGSERVER)
+  message(WARNING "LLDB_CODESIGN_IDENTITY not found: '${LLDB_CODESIGN_IDENTITY}' ${not_found_help}")
+endif()
+return()
+  endif()
+
+  # Development signing identity: use if available
+  check_certificate(lldb_codesign available)
+  if(available)
+set(${result} lldb_codesign PARENT_SCOPE)
+return()
+  endif()
+
+  if(NOT LLDB_USE_SYSTEM_DEBUGSERVER)
+message(WARNING "Development code sign identiy not found: 'lldb_codesign' ${not_found_help}")
+  endif()
+
+  # LLVM pendant: fallback if available
+  if(LLVM_CODESIGNING_IDENTITY)
+check_certificate(${LLVM_CODESIGNING_IDENTITY} available)
+if(available)
+  set(${result} ${LLVM_CODESIGNING_IDENTITY} PARENT_SCOPE)
+  return()
+endif()
+  endif()
+
+  # Ad-hoc signing: last resort
+  set(${result} "-" PARENT_SCOPE)
+endfunction()
+
 set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -stdlib=libc++ -Wl,-sectcreate,__TEXT,__info_plist,${CMAKE_CURRENT_SOURCE_DIR}/../resources/lldb-debugserver-Info.plist")
 
 check_cxx_compiler_flag("-Wno-gnu-zero-variadic-macro-arguments"
@@ -30,132 +82,17 @@
 
 add_subdirectory(MacOSX)
 
-# LLDB-specific identity, currently used for code signing debugserver.
 set(LLDB_CODESIGN_IDENTITY "" CACHE STRING
-"Override code sign identity for debugserver and for use in tests; falls back to LLVM_CODESIGNING_IDENTITY if set or lldb_codesign otherwise (Darwin only)")
-
-# Determine which identity to use and store it in the separate cache entry.
-# We will query it later for LLDB_TEST_COMMON_ARGS.
-if(LLDB_CODESIGN_IDENTITY)
-  set(LLDB_CODESIGN_IDENTITY_USED ${LLDB_CODESIGN_IDENTITY} CACHE INTERNAL "" FORCE)
-elseif(LLVM_CODESIGNING_IDENTITY)
-  set(LLDB_CODESIGN_IDENTITY_USED ${LLVM_CODESIGNING_IDENTITY} CACHE INTERNAL "" FORCE)
-else()
-  set(LLDB_CODESIGN_IDENTITY_USED lldb_codesign CACHE INTERNAL "" FORCE)
-endif()
+"Identity override for debugserver; see 'Code Signing on macOS' in the documentation (Darwin only)")
 
-# Override locally, so the identity

[Lldb-commits] [lldb] r366350 - [CMake] Avoid liblldb genex when figuring out the copy destination for framework tools

2019-07-17 Thread Stefan Granitz via lldb-commits

Author: stefan.graenitz
Date: Wed Jul 17 10:14:40 2019
New Revision: 366350

URL: http://llvm.org/viewvc/llvm-project?rev=366350&view=rev
Log:
[CMake] Avoid liblldb genex when figuring out the copy destination for 
framework tools

This genex created an order-only dependency to liblldb for every framework 
tool. It reduced build throughput in the first half of the compilation and 
pulled in unnecessary build units, e.g. debugserver required ~900 build units. 
With this change debugserver is (again) down at 52 build units!

Modified:
lldb/trunk/cmake/modules/AddLLDB.cmake

Modified: lldb/trunk/cmake/modules/AddLLDB.cmake
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/cmake/modules/AddLLDB.cmake?rev=366350&r1=366349&r2=366350&view=diff
==
--- lldb/trunk/cmake/modules/AddLLDB.cmake (original)
+++ lldb/trunk/cmake/modules/AddLLDB.cmake Wed Jul 17 10:14:40 2019
@@ -199,7 +199,8 @@ endfunction()
 function(lldb_add_to_buildtree_lldb_framework name subdir)
   # Destination for the copy in the build-tree. While the framework target may
   # not exist yet, it will exist when the generator expression gets expanded.
-  set(copy_dest "$/../../../${subdir}")
+  get_target_property(framework_build_dir liblldb LIBRARY_OUTPUT_DIRECTORY)
+  set(copy_dest "${framework_build_dir}/${subdir}")
 
   # Copy into the given subdirectory for testing.
   add_custom_command(TARGET ${name} POST_BUILD


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

[Lldb-commits] [PATCH] D64536: Adding inline comments to code view type records

2019-07-17 Thread Reid Kleckner via Phabricator via lldb-commits

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

lgtm, sorry this fell out of my inbox.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D64536



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

[Lldb-commits] [lldb] r366352 - [Test] Add module cache for TestWeakSymbols

2019-07-17 Thread Jonas Devlieghere via lldb-commits

Author: jdevlieghere
Date: Wed Jul 17 10:22:29 2019
New Revision: 366352

URL: http://llvm.org/viewvc/llvm-project?rev=366352&view=rev
Log:
[Test] Add module cache for TestWeakSymbols

Explicitly set the module cache in the Makefile with
-fmodules-cache-path.

Modified:

lldb/trunk/packages/Python/lldbsuite/test/expression_command/weak_symbols/Makefile

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/expression_command/weak_symbols/Makefile
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/expression_command/weak_symbols/Makefile?rev=366352&r1=366351&r2=366352&view=diff
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/expression_command/weak_symbols/Makefile
 (original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/expression_command/weak_symbols/Makefile
 Wed Jul 17 10:22:29 2019
@@ -22,5 +22,5 @@ dylib2.o: dylib.h $(SRCDIR)/dylib.c
$(CC)  $(CFLAGS) -c $(SRCDIR)/dylib.c -o dylib2.o
 
 main.o: dylib.h $(SRCDIR)/main.c
-   $(CC)  $(CFLAGS) -c $(SRCDIR)/main.c -fmodules
+   $(CC)  $(CFLAGS) -c $(SRCDIR)/main.c -fmodules 
-fmodules-cache-path=$(CLANG_MODULE_CACHE_DIR)
 


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

[Lldb-commits] [PATCH] D64844: [Target] Remove Target::GetScratchClangASTContext

2019-07-17 Thread Jim Ingham via Phabricator via lldb-commits

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

This seems partly wrong to me.  The point is that the Target holds keeps 
scratch AST contexts for all the languages it supports.  They are the central 
repository for the accumulation of effects of expressions evaluated while that 
target is alive.  For instance, all the user defined types and variables go 
there. The Target also manages its lifecycle.   So all the Scratch AST Contexts 
are properly owned by the target.  For instance, in the swift case if there's a 
module that we can't import, we have to fall back to making an AST Context for 
each module we can successfully import and dispatching expressions to the 
appropriate one of those.

This move doesn't keep all the clients from knowing they are getting their 
hands on a ClangASTContext, so it doesn't seem like it achieves much hiding.  
All it does is conceal the ownership of the scratch AST context for C-family 
languages.


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

https://reviews.llvm.org/D64844



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

[Lldb-commits] [PATCH] D64853: Fix CommandInterpreter for _regex-break with options

2019-07-17 Thread Jonas Devlieghere via Phabricator via lldb-commits

JDevlieghere added inline comments.



Comment at: 
lldb/packages/Python/lldbsuite/test/functionalities/breakpoint/breakpoint_command/main.c:9
 
+#include 
+

davide wrote:
> TWeaver wrote:
> > Hi there,
> > 
> > this is a little nit picky, and I'm not entirely sure If im right in saying 
> > so, but, if this is a C++ file as denoted by the license header, then 
> > shouldn't this include by  rather than the c library stdlib.h?
> > 
> > thanks for your time
> > Tom
> > 
> > 
> This is definitely a C file, the header is wrong.
Also, I believe the consensus is that we don't need the header in test files. 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D64853



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

[Lldb-commits] [PATCH] D62183: [Windows] Fix race condition between state changes

2019-07-17 Thread Martin Andersson via Phabricator via lldb-commits

martin updated this revision to Diff 210365.
martin added a reviewer: amccarth.
martin added a comment.

Rebased against master


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

https://reviews.llvm.org/D62183

Files:
  source/Plugins/Process/Windows/Common/ProcessWindows.cpp


Index: source/Plugins/Process/Windows/Common/ProcessWindows.cpp
===
--- source/Plugins/Process/Windows/Common/ProcessWindows.cpp
+++ source/Plugins/Process/Windows/Common/ProcessWindows.cpp
@@ -205,16 +205,6 @@
  m_session_data->m_debugger->GetProcess().GetProcessId(),
  GetPrivateState());
 
-ExceptionRecordSP active_exception =
-m_session_data->m_debugger->GetActiveException().lock();
-if (active_exception) {
-  // Resume the process and continue processing debug events.  Mask the
-  // exception so that from the process's view, there is no indication that
-  // anything happened.
-  m_session_data->m_debugger->ContinueAsyncException(
-  ExceptionResult::MaskException);
-}
-
 LLDB_LOG(log, "resuming {0} threads.", m_thread_list.GetSize());
 
 bool failed = false;
@@ -233,10 +223,19 @@
 
 if (failed) {
   error.SetErrorString("ProcessWindows::DoResume failed");
-  return error;
 } else {
   SetPrivateState(eStateRunning);
 }
+
+ExceptionRecordSP active_exception =
+m_session_data->m_debugger->GetActiveException().lock();
+if (active_exception) {
+  // Resume the process and continue processing debug events.  Mask the
+  // exception so that from the process's view, there is no indication that
+  // anything happened.
+  m_session_data->m_debugger->ContinueAsyncException(
+  ExceptionResult::MaskException);
+}
   } else {
 LLDB_LOG(log, "error: process {0} is in state {1}.  Returning...",
  m_session_data->m_debugger->GetProcess().GetProcessId(),


Index: source/Plugins/Process/Windows/Common/ProcessWindows.cpp
===
--- source/Plugins/Process/Windows/Common/ProcessWindows.cpp
+++ source/Plugins/Process/Windows/Common/ProcessWindows.cpp
@@ -205,16 +205,6 @@
  m_session_data->m_debugger->GetProcess().GetProcessId(),
  GetPrivateState());
 
-ExceptionRecordSP active_exception =
-m_session_data->m_debugger->GetActiveException().lock();
-if (active_exception) {
-  // Resume the process and continue processing debug events.  Mask the
-  // exception so that from the process's view, there is no indication that
-  // anything happened.
-  m_session_data->m_debugger->ContinueAsyncException(
-  ExceptionResult::MaskException);
-}
-
 LLDB_LOG(log, "resuming {0} threads.", m_thread_list.GetSize());
 
 bool failed = false;
@@ -233,10 +223,19 @@
 
 if (failed) {
   error.SetErrorString("ProcessWindows::DoResume failed");
-  return error;
 } else {
   SetPrivateState(eStateRunning);
 }
+
+ExceptionRecordSP active_exception =
+m_session_data->m_debugger->GetActiveException().lock();
+if (active_exception) {
+  // Resume the process and continue processing debug events.  Mask the
+  // exception so that from the process's view, there is no indication that
+  // anything happened.
+  m_session_data->m_debugger->ContinueAsyncException(
+  ExceptionResult::MaskException);
+}
   } else {
 LLDB_LOG(log, "error: process {0} is in state {1}.  Returning...",
  m_session_data->m_debugger->GetProcess().GetProcessId(),
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D62183: [Windows] Fix race condition between state changes

2019-07-17 Thread Martin Andersson via Phabricator via lldb-commits

martin added a comment.

In D62183#1556645 , @amccarth wrote:

> zturner is not a regular here anymore.  I think he pops in from time-to-time, 
> but I wouldn't depend on just him for a review.
>
> Are you still wanting to land this?  If you rebase and add me as a reviewer, 
> I'd be happy to take a look.

I unfortunately missed your reply since it was somehow marked as spam. But yes 
I would like to see this land in some shape or form. I was a bit unsure on how 
much to change, I thought about also moving the call to LLDB_LOG for instance, 
but I opted for the least disruptive change I could manage.

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

https://reviews.llvm.org/D62183

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

[Lldb-commits] [lldb] r366356 - [dotest] Disable color while testing.

2019-07-17 Thread Jonas Devlieghere via lldb-commits

Author: jdevlieghere
Date: Wed Jul 17 10:56:57 2019
New Revision: 366356

URL: http://llvm.org/viewvc/llvm-project?rev=366356&view=rev
Log:
[dotest] Disable color while testing.

Disable colors so we don't risk having unexpected ANSI codes in the test
output. Currently, the behavior of a test can change depending on
whether it's run under a color-supporting terminal, or under a dummy
terminal, for example when using lit or multiprocessing.

Modified:
lldb/trunk/packages/Python/lldbsuite/test/lldbtest.py

Modified: lldb/trunk/packages/Python/lldbsuite/test/lldbtest.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/lldbtest.py?rev=366356&r1=366355&r2=366356&view=diff
==
--- lldb/trunk/packages/Python/lldbsuite/test/lldbtest.py (original)
+++ lldb/trunk/packages/Python/lldbsuite/test/lldbtest.py Wed Jul 17 10:56:57 
2019
@@ -1869,6 +1869,9 @@ class TestBase(Base):
 # differ in the debug info, which is not being hashed.
 self.runCmd('settings set symbols.enable-external-lookup false')
 
+# Disable color.
+self.runCmd("settings set use-color false")
+
 # Make sure that a sanitizer LLDB's environment doesn't get passed on.
 if 'DYLD_LIBRARY_PATH' in os.environ:
 self.runCmd('settings set target.env-vars DYLD_LIBRARY_PATH=')


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

[Lldb-commits] [PATCH] D64806: [CMake] Always build debugserver on Darwin and allow tests to use the system's one

2019-07-17 Thread Alex Langford via Phabricator via lldb-commits

xiaobai added a comment.

I think that this is a good change overall to do but the name 
`LLDB_USE_SYSTEM_DEBUGSERVER` is kind of a confusing to me. The name itself 
doesn't really convey to me that the system debugserver is going to be used for 
just testing. Before this change, that flag indicated that the system 
debugserver was going to be used for everything. Maybe you could change it to 
something like `LLDB_TEST_WITH_SYSTEM_DEBUGSERVER`?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D64806



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

[Lldb-commits] [PATCH] D64823: [CMake] Default LLDB_PATH_TO_LLVM_BUILD to LLVM_DIR

2019-07-17 Thread Alex Langford via Phabricator via lldb-commits

xiaobai added inline comments.



Comment at: lldb/cmake/modules/LLDBStandalone.cmake:45
   if(CMAKE_CROSSCOMPILING)
 set(LLVM_NATIVE_BUILD "${LLDB_PATH_TO_LLVM_BUILD}/NATIVE")
 if (NOT EXISTS "${LLVM_NATIVE_BUILD}")

sgraenitz wrote:
> @xiaobai Can this be changed to something like `${LLVM_DIR}/../../../NATIVE`?
Yeah I don't see why not. We could probably even change it to 
`${LLVM_BINARY_DIR}/NATIVE` instead.


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D64823



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

[Lldb-commits] [PATCH] D64583: [lldb][test_suite] Fix skipIfTargetAndroid decorator

2019-07-17 Thread Alex Langford via Phabricator via lldb-commits

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

LGTM


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D64583



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

[Lldb-commits] [PATCH] D64823: [CMake] Default LLDB_PATH_TO_LLVM_BUILD to LLVM_DIR

2019-07-17 Thread Jonas Devlieghere via Phabricator via lldb-commits

JDevlieghere updated this revision to Diff 210373.
JDevlieghere added a comment.

Use `LLVM_DIR` and `Clang_DIR`


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

https://reviews.llvm.org/D64823

Files:
  lldb/cmake/modules/LLDBStandalone.cmake


Index: lldb/cmake/modules/LLDBStandalone.cmake
===
--- lldb/cmake/modules/LLDBStandalone.cmake
+++ lldb/cmake/modules/LLDBStandalone.cmake
@@ -2,16 +2,8 @@
 
 option(LLVM_INSTALL_TOOLCHAIN_ONLY "Only include toolchain files in the 
'install' target." OFF)
 
-set(LLDB_PATH_TO_LLVM_BUILD "" CACHE PATH "Path to LLVM build tree")
-set(LLDB_PATH_TO_CLANG_BUILD "${LLDB_PATH_TO_LLVM_BUILD}" CACHE PATH "Path to 
Clang build tree")
-
-file(TO_CMAKE_PATH "${LLDB_PATH_TO_LLVM_BUILD}" LLDB_PATH_TO_LLVM_BUILD)
-file(TO_CMAKE_PATH "${LLDB_PATH_TO_CLANG_BUILD}" LLDB_PATH_TO_CLANG_BUILD)
-
-find_package(LLVM REQUIRED CONFIG
-  HINTS "${LLDB_PATH_TO_LLVM_BUILD}" NO_CMAKE_FIND_ROOT_PATH)
-find_package(Clang REQUIRED CONFIG
-  HINTS "${LLDB_PATH_TO_CLANG_BUILD}" NO_CMAKE_FIND_ROOT_PATH)
+find_package(LLVM REQUIRED CONFIG HINTS "${LLVM_DIR}" NO_CMAKE_FIND_ROOT_PATH)
+find_package(Clang REQUIRED CONFIG HINTS "${Clang_DIR}" 
NO_CMAKE_FIND_ROOT_PATH)
 
 # We set LLVM_CMAKE_PATH so that GetSVN.cmake is found correctly when building 
SVNVersion.inc
 set(LLVM_CMAKE_PATH ${LLVM_CMAKE_DIR} CACHE PATH "Path to LLVM CMake modules")
@@ -40,7 +32,7 @@
 set(LLVM_DEFAULT_EXTERNAL_LIT ${lit_full_path} CACHE PATH "Path to llvm-lit")
 
 if(CMAKE_CROSSCOMPILING)
-  set(LLVM_NATIVE_BUILD "${LLDB_PATH_TO_LLVM_BUILD}/NATIVE")
+  set(LLVM_NATIVE_BUILD "${LLVM_BINARY_DIR}/NATIVE")
   if (NOT EXISTS "${LLVM_NATIVE_BUILD}")
 message(FATAL_ERROR
   "Attempting to cross-compile LLDB standalone but no native LLVM build


Index: lldb/cmake/modules/LLDBStandalone.cmake
===
--- lldb/cmake/modules/LLDBStandalone.cmake
+++ lldb/cmake/modules/LLDBStandalone.cmake
@@ -2,16 +2,8 @@
 
 option(LLVM_INSTALL_TOOLCHAIN_ONLY "Only include toolchain files in the 'install' target." OFF)
 
-set(LLDB_PATH_TO_LLVM_BUILD "" CACHE PATH "Path to LLVM build tree")
-set(LLDB_PATH_TO_CLANG_BUILD "${LLDB_PATH_TO_LLVM_BUILD}" CACHE PATH "Path to Clang build tree")
-
-file(TO_CMAKE_PATH "${LLDB_PATH_TO_LLVM_BUILD}" LLDB_PATH_TO_LLVM_BUILD)
-file(TO_CMAKE_PATH "${LLDB_PATH_TO_CLANG_BUILD}" LLDB_PATH_TO_CLANG_BUILD)
-
-find_package(LLVM REQUIRED CONFIG
-  HINTS "${LLDB_PATH_TO_LLVM_BUILD}" NO_CMAKE_FIND_ROOT_PATH)
-find_package(Clang REQUIRED CONFIG
-  HINTS "${LLDB_PATH_TO_CLANG_BUILD}" NO_CMAKE_FIND_ROOT_PATH)
+find_package(LLVM REQUIRED CONFIG HINTS "${LLVM_DIR}" NO_CMAKE_FIND_ROOT_PATH)
+find_package(Clang REQUIRED CONFIG HINTS "${Clang_DIR}" NO_CMAKE_FIND_ROOT_PATH)
 
 # We set LLVM_CMAKE_PATH so that GetSVN.cmake is found correctly when building SVNVersion.inc
 set(LLVM_CMAKE_PATH ${LLVM_CMAKE_DIR} CACHE PATH "Path to LLVM CMake modules")
@@ -40,7 +32,7 @@
 set(LLVM_DEFAULT_EXTERNAL_LIT ${lit_full_path} CACHE PATH "Path to llvm-lit")
 
 if(CMAKE_CROSSCOMPILING)
-  set(LLVM_NATIVE_BUILD "${LLDB_PATH_TO_LLVM_BUILD}/NATIVE")
+  set(LLVM_NATIVE_BUILD "${LLVM_BINARY_DIR}/NATIVE")
   if (NOT EXISTS "${LLVM_NATIVE_BUILD}")
 message(FATAL_ERROR
   "Attempting to cross-compile LLDB standalone but no native LLVM build
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D64844: [Target] Remove Target::GetScratchClangASTContext

2019-07-17 Thread Alex Langford via Phabricator via lldb-commits

xiaobai added a comment.

In D64844#1589794 , @jingham wrote:

> This seems partly wrong to me.  The point is that the Target holds scratch 
> AST contexts for all the languages it supports.  They are the central 
> repository for the accumulation of effects of expressions evaluated while 
> that target is alive.  For instance, all the user defined types and variables 
> go there. The Target also manages its lifecycle.   For instance, in the swift 
> case if there's a module that we can't import, we have to fall back to making 
> an AST Context for each module we can successfully import and dispatching 
> expressions to the appropriate one of those.
>
> So all the Scratch AST Contexts are properly owned by the target.
>
> This move doesn't keep all the clients from knowing they are getting their 
> hands on a ClangASTContext, so it doesn't seem like it achieves much hiding.  
> All it does is conceal the ownership of the scratch AST context for C-family 
> languages.


Right, I'm not trying to remove Target's ownership of any scratch type systems. 
My goal is to remove Target's knowledge about specific scratch type systems. 
Target shouldn't have to know about ClangASTContext specifically. It should 
hand out scratch TypeSystems based on what language you give it which it 
already does today with `GetScratchTypeSystemForLanguage`. I'm not trying to 
hide this information from clients, I'm trying to hide the knowledge from 
Target.


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

https://reviews.llvm.org/D64844



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

[Lldb-commits] [PATCH] D62183: [Windows] Fix race condition between state changes

2019-07-17 Thread Adrian McCarthy via Phabricator via lldb-commits

amccarth added a comment.

This change looks fine to me, but I wish there was a reliable way to test it.  
Is it a true race condition (e.g., because the unpredictability of thread 
scheduling), or is there a way to write a test that would always fail without 
this fix?


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

https://reviews.llvm.org/D62183



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

Re: [Lldb-commits] [lldb] r366356 - [dotest] Disable color while testing.

2019-07-17 Thread Adrian McCarthy via lldb-commits

I thought the color code was smart enough to figure out whether it was
actually going to an actual terminal or being redirected.  Is this hiding a
bug in that logic?

On Wed, Jul 17, 2019 at 10:56 AM Jonas Devlieghere via lldb-commits <
lldb-commits@lists.llvm.org> wrote:

> Author: jdevlieghere
> Date: Wed Jul 17 10:56:57 2019
> New Revision: 366356
>
> URL: http://llvm.org/viewvc/llvm-project?rev=366356&view=rev
> Log:
> [dotest] Disable color while testing.
>
> Disable colors so we don't risk having unexpected ANSI codes in the test
> output. Currently, the behavior of a test can change depending on
> whether it's run under a color-supporting terminal, or under a dummy
> terminal, for example when using lit or multiprocessing.
>
> Modified:
> lldb/trunk/packages/Python/lldbsuite/test/lldbtest.py
>
> Modified: lldb/trunk/packages/Python/lldbsuite/test/lldbtest.py
> URL:
> http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/lldbtest.py?rev=366356&r1=366355&r2=366356&view=diff
>
> ==
> --- lldb/trunk/packages/Python/lldbsuite/test/lldbtest.py (original)
> +++ lldb/trunk/packages/Python/lldbsuite/test/lldbtest.py Wed Jul 17
> 10:56:57 2019
> @@ -1869,6 +1869,9 @@ class TestBase(Base):
>  # differ in the debug info, which is not being hashed.
>  self.runCmd('settings set symbols.enable-external-lookup false')
>
> +# Disable color.
> +self.runCmd("settings set use-color false")
> +
>  # Make sure that a sanitizer LLDB's environment doesn't get
> passed on.
>  if 'DYLD_LIBRARY_PATH' in os.environ:
>  self.runCmd('settings set target.env-vars DYLD_LIBRARY_PATH=')
>
>
> ___
> lldb-commits mailing list
> lldb-commits@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D64821: [CMake] Remove duplicated logic to find Python when doing a standalone build

2019-07-17 Thread Stefan Gränitz via Phabricator via lldb-commits

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

Jonas is right, that there is nothing wrong with this code, but that it's just 
redundant as we'll do all of this in LLDBConfig anyway. Removing it means 
adding a potential difference for standalone builds, but in the end it should 
be fine.


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D64821



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

[Lldb-commits] [PATCH] D64844: [Target] Remove Target::GetScratchClangASTContext

2019-07-17 Thread Jim Ingham via Phabricator via lldb-commits

jingham added a comment.

I think I understand your goal - a worthy one, BTW...  But I think this is an 
unnecessary step along that path.

After all, all the clients of the Target's Scratch TypeSystem for C-family 
languages should be able to do what they need to do with a TypeSystem, rather 
than a ClangASTContext.  And that's really your goal.   It doesn't help much if 
Target doesn't need to know about ClangASTContext but everyone else 
(breakpoints, watchpoints, the LanguageRuntimes, etc.) who uses the C-family 
language Scratch TypeSystem does.

So you don't want to just move Target::GetScratchClangASTContext around, you 
want to get rid of it.  Everybody who was calling 
Target::GetScratchClangASTContext should call 
Target::GetScratchTypeSystemForLanguage and that should be sufficient for them.

So a better approach, it seems to me, would be to remove 
Target::GetScratchClangASTContext altogether, convert all it's callers to 
Target::GetScratchTypeSystemForLanguage and try changing the type the callers 
receive from ClangASTContext * to TypeSystem *.  Then if any of them ACTUALLY 
needed to cast this from a TypeSystem to a ClangASTContext, you can change the 
type back to ClangASTContext, do the cast in situ and add a FIXME: You should 
be able to do this with a TypeSystem.

That has the - to me - desirable benefit of keeping it clear that these scratch 
type systems are things handed out by the target, which your change makes less 
clear.  Plus it will quickly show us what is missing from TypeSystem.  Or 
maybe, you will find that for most uses, a TypeSystem WAS good enough, which 
will be double goodness!


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

https://reviews.llvm.org/D64844



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

[Lldb-commits] [PATCH] D64806: [CMake] Always build debugserver on Darwin and allow tests to use the system's one

2019-07-17 Thread Stefan Gränitz via Phabricator via lldb-commits

sgraenitz added a comment.

That's a fair point. However, changing the name of the parameter would force us 
to update quite a number of bot configurations, caches and documentation. So if 
it's "acceptable" I would be in favor to keep `LLDB_USE_SYSTEM_DEBUGSERVER`.
Also it's kind-of in line with the (internal) `LLDB_CAN_USE_DEBUGSERVER` and 
`LLDB_CAN_USE_LLDB_SERVER` variables.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D64806



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

[Lldb-commits] [lldb] r366362 - [CMake] Use LLVM_DIR and Clang_DIR for standalone builds.

2019-07-17 Thread Jonas Devlieghere via lldb-commits

Author: jdevlieghere
Date: Wed Jul 17 12:24:15 2019
New Revision: 366362

URL: http://llvm.org/viewvc/llvm-project?rev=366362&view=rev
Log:
[CMake] Use LLVM_DIR and Clang_DIR for standalone builds.

When doing a standalone build, without setting LLDB_PATH_TO_LLVM_BUILD
or LLDB_PATH_TO_CLANG_BUILD, you get the following error.

```
CMake Error at cmake/modules/LLDBStandalone.cmake:23 (find_package):
  Could not find a package configuration file provided by "LLVM" with any of
  the following names:

LLVMConfig.cmake
llvm-config.cmake

  Add the installation prefix of "LLVM" to CMAKE_PREFIX_PATH or set
  "LLVM_DIR" to a directory containing one of the above files.  If "LLVM"
  provides a separate development package or SDK, be sure it has been
  installed.
```

This suggests setting LLVM_DIR to LLVM's install directory. However,
LLDBStandalone.cmake takes LLDB_PATH_TO_LLVM_BUILD as its hint. As
someone who isn't familiar with the standalone process, this is rather
confusing. This patch removes LLDB_PATH_TO_LLVM_BUILD and
LLDB_PATH_TO_CLANG_BUILD and instead use LLVM_DIR and Clang_DIR
respectively.

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

Modified:
lldb/trunk/cmake/modules/LLDBStandalone.cmake

Modified: lldb/trunk/cmake/modules/LLDBStandalone.cmake
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/cmake/modules/LLDBStandalone.cmake?rev=366362&r1=366361&r2=366362&view=diff
==
--- lldb/trunk/cmake/modules/LLDBStandalone.cmake (original)
+++ lldb/trunk/cmake/modules/LLDBStandalone.cmake Wed Jul 17 12:24:15 2019
@@ -2,16 +2,8 @@ project(lldb)
 
 option(LLVM_INSTALL_TOOLCHAIN_ONLY "Only include toolchain files in the 
'install' target." OFF)
 
-set(LLDB_PATH_TO_LLVM_BUILD "" CACHE PATH "Path to LLVM build tree")
-set(LLDB_PATH_TO_CLANG_BUILD "${LLDB_PATH_TO_LLVM_BUILD}" CACHE PATH "Path to 
Clang build tree")
-
-file(TO_CMAKE_PATH "${LLDB_PATH_TO_LLVM_BUILD}" LLDB_PATH_TO_LLVM_BUILD)
-file(TO_CMAKE_PATH "${LLDB_PATH_TO_CLANG_BUILD}" LLDB_PATH_TO_CLANG_BUILD)
-
-find_package(LLVM REQUIRED CONFIG
-  HINTS "${LLDB_PATH_TO_LLVM_BUILD}" NO_CMAKE_FIND_ROOT_PATH)
-find_package(Clang REQUIRED CONFIG
-  HINTS "${LLDB_PATH_TO_CLANG_BUILD}" NO_CMAKE_FIND_ROOT_PATH)
+find_package(LLVM REQUIRED CONFIG HINTS "${LLVM_DIR}" NO_CMAKE_FIND_ROOT_PATH)
+find_package(Clang REQUIRED CONFIG HINTS "${Clang_DIR}" 
NO_CMAKE_FIND_ROOT_PATH)
 
 # We set LLVM_CMAKE_PATH so that GetSVN.cmake is found correctly when building 
SVNVersion.inc
 set(LLVM_CMAKE_PATH ${LLVM_CMAKE_DIR} CACHE PATH "Path to LLVM CMake modules")
@@ -40,7 +32,7 @@ find_program(lit_full_path ${lit_file_na
 set(LLVM_DEFAULT_EXTERNAL_LIT ${lit_full_path} CACHE PATH "Path to llvm-lit")
 
 if(CMAKE_CROSSCOMPILING)
-  set(LLVM_NATIVE_BUILD "${LLDB_PATH_TO_LLVM_BUILD}/NATIVE")
+  set(LLVM_NATIVE_BUILD "${LLVM_BINARY_DIR}/NATIVE")
   if (NOT EXISTS "${LLVM_NATIVE_BUILD}")
 message(FATAL_ERROR
   "Attempting to cross-compile LLDB standalone but no native LLVM build


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

[Lldb-commits] [PATCH] D64844: [Target] Remove Target::GetScratchClangASTContext

2019-07-17 Thread Jim Ingham via Phabricator via lldb-commits

jingham added a comment.

Seems like in most places we're just pulling out basic types or their sizes, 
which we should certainly be able to do with a TypeSystem.


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

https://reviews.llvm.org/D64844



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

[Lldb-commits] [PATCH] D64823: [CMake] Use LLVM_DIR and Clang_DIR for standalone builds.

2019-07-17 Thread Jonas Devlieghere via Phabricator via lldb-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rL366362: [CMake] Use LLVM_DIR and Clang_DIR for standalone 
builds. (authored by JDevlieghere, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D64823?vs=210373&id=210391#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D64823

Files:
  lldb/trunk/cmake/modules/LLDBStandalone.cmake


Index: lldb/trunk/cmake/modules/LLDBStandalone.cmake
===
--- lldb/trunk/cmake/modules/LLDBStandalone.cmake
+++ lldb/trunk/cmake/modules/LLDBStandalone.cmake
@@ -2,16 +2,8 @@
 
 option(LLVM_INSTALL_TOOLCHAIN_ONLY "Only include toolchain files in the 
'install' target." OFF)
 
-set(LLDB_PATH_TO_LLVM_BUILD "" CACHE PATH "Path to LLVM build tree")
-set(LLDB_PATH_TO_CLANG_BUILD "${LLDB_PATH_TO_LLVM_BUILD}" CACHE PATH "Path to 
Clang build tree")
-
-file(TO_CMAKE_PATH "${LLDB_PATH_TO_LLVM_BUILD}" LLDB_PATH_TO_LLVM_BUILD)
-file(TO_CMAKE_PATH "${LLDB_PATH_TO_CLANG_BUILD}" LLDB_PATH_TO_CLANG_BUILD)
-
-find_package(LLVM REQUIRED CONFIG
-  HINTS "${LLDB_PATH_TO_LLVM_BUILD}" NO_CMAKE_FIND_ROOT_PATH)
-find_package(Clang REQUIRED CONFIG
-  HINTS "${LLDB_PATH_TO_CLANG_BUILD}" NO_CMAKE_FIND_ROOT_PATH)
+find_package(LLVM REQUIRED CONFIG HINTS "${LLVM_DIR}" NO_CMAKE_FIND_ROOT_PATH)
+find_package(Clang REQUIRED CONFIG HINTS "${Clang_DIR}" 
NO_CMAKE_FIND_ROOT_PATH)
 
 # We set LLVM_CMAKE_PATH so that GetSVN.cmake is found correctly when building 
SVNVersion.inc
 set(LLVM_CMAKE_PATH ${LLVM_CMAKE_DIR} CACHE PATH "Path to LLVM CMake modules")
@@ -40,7 +32,7 @@
 set(LLVM_DEFAULT_EXTERNAL_LIT ${lit_full_path} CACHE PATH "Path to llvm-lit")
 
 if(CMAKE_CROSSCOMPILING)
-  set(LLVM_NATIVE_BUILD "${LLDB_PATH_TO_LLVM_BUILD}/NATIVE")
+  set(LLVM_NATIVE_BUILD "${LLVM_BINARY_DIR}/NATIVE")
   if (NOT EXISTS "${LLVM_NATIVE_BUILD}")
 message(FATAL_ERROR
   "Attempting to cross-compile LLDB standalone but no native LLVM build


Index: lldb/trunk/cmake/modules/LLDBStandalone.cmake
===
--- lldb/trunk/cmake/modules/LLDBStandalone.cmake
+++ lldb/trunk/cmake/modules/LLDBStandalone.cmake
@@ -2,16 +2,8 @@
 
 option(LLVM_INSTALL_TOOLCHAIN_ONLY "Only include toolchain files in the 'install' target." OFF)
 
-set(LLDB_PATH_TO_LLVM_BUILD "" CACHE PATH "Path to LLVM build tree")
-set(LLDB_PATH_TO_CLANG_BUILD "${LLDB_PATH_TO_LLVM_BUILD}" CACHE PATH "Path to Clang build tree")
-
-file(TO_CMAKE_PATH "${LLDB_PATH_TO_LLVM_BUILD}" LLDB_PATH_TO_LLVM_BUILD)
-file(TO_CMAKE_PATH "${LLDB_PATH_TO_CLANG_BUILD}" LLDB_PATH_TO_CLANG_BUILD)
-
-find_package(LLVM REQUIRED CONFIG
-  HINTS "${LLDB_PATH_TO_LLVM_BUILD}" NO_CMAKE_FIND_ROOT_PATH)
-find_package(Clang REQUIRED CONFIG
-  HINTS "${LLDB_PATH_TO_CLANG_BUILD}" NO_CMAKE_FIND_ROOT_PATH)
+find_package(LLVM REQUIRED CONFIG HINTS "${LLVM_DIR}" NO_CMAKE_FIND_ROOT_PATH)
+find_package(Clang REQUIRED CONFIG HINTS "${Clang_DIR}" NO_CMAKE_FIND_ROOT_PATH)
 
 # We set LLVM_CMAKE_PATH so that GetSVN.cmake is found correctly when building SVNVersion.inc
 set(LLVM_CMAKE_PATH ${LLVM_CMAKE_DIR} CACHE PATH "Path to LLVM CMake modules")
@@ -40,7 +32,7 @@
 set(LLVM_DEFAULT_EXTERNAL_LIT ${lit_full_path} CACHE PATH "Path to llvm-lit")
 
 if(CMAKE_CROSSCOMPILING)
-  set(LLVM_NATIVE_BUILD "${LLDB_PATH_TO_LLVM_BUILD}/NATIVE")
+  set(LLVM_NATIVE_BUILD "${LLVM_BINARY_DIR}/NATIVE")
   if (NOT EXISTS "${LLVM_NATIVE_BUILD}")
 message(FATAL_ERROR
   "Attempting to cross-compile LLDB standalone but no native LLVM build
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [lldb] r366356 - [dotest] Disable color while testing.

2019-07-17 Thread Jonas Devlieghere via lldb-commits

When you run the tests without multiprocessing, lldb's output is not
redirected. So the logic correctly detects that colors are supported,
leading to potential test failures under this mode.

On Wed, Jul 17, 2019 at 11:42 AM Adrian McCarthy 
wrote:

> I thought the color code was smart enough to figure out whether it was
> actually going to an actual terminal or being redirected.  Is this hiding a
> bug in that logic?
>
> On Wed, Jul 17, 2019 at 10:56 AM Jonas Devlieghere via lldb-commits <
> lldb-commits@lists.llvm.org> wrote:
>
>> Author: jdevlieghere
>> Date: Wed Jul 17 10:56:57 2019
>> New Revision: 366356
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=366356&view=rev
>> Log:
>> [dotest] Disable color while testing.
>>
>> Disable colors so we don't risk having unexpected ANSI codes in the test
>> output. Currently, the behavior of a test can change depending on
>> whether it's run under a color-supporting terminal, or under a dummy
>> terminal, for example when using lit or multiprocessing.
>>
>> Modified:
>> lldb/trunk/packages/Python/lldbsuite/test/lldbtest.py
>>
>> Modified: lldb/trunk/packages/Python/lldbsuite/test/lldbtest.py
>> URL:
>> http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/lldbtest.py?rev=366356&r1=366355&r2=366356&view=diff
>>
>> ==
>> --- lldb/trunk/packages/Python/lldbsuite/test/lldbtest.py (original)
>> +++ lldb/trunk/packages/Python/lldbsuite/test/lldbtest.py Wed Jul 17
>> 10:56:57 2019
>> @@ -1869,6 +1869,9 @@ class TestBase(Base):
>>  # differ in the debug info, which is not being hashed.
>>  self.runCmd('settings set symbols.enable-external-lookup false')
>>
>> +# Disable color.
>> +self.runCmd("settings set use-color false")
>> +
>>  # Make sure that a sanitizer LLDB's environment doesn't get
>> passed on.
>>  if 'DYLD_LIBRARY_PATH' in os.environ:
>>  self.runCmd('settings set target.env-vars
>> DYLD_LIBRARY_PATH=')
>>
>>
>> ___
>> lldb-commits mailing list
>> lldb-commits@lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
>>
>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D64853: Fix CommandInterpreter for _regex-break with options

2019-07-17 Thread Med Ismail Bennani via Phabricator via lldb-commits

mib updated this revision to Diff 210393.
mib added a comment.

Updating D64853 : Fix CommandInterpreter for 
_regex-break with options


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D64853

Files:
  
lldb/packages/Python/lldbsuite/test/functionalities/breakpoint/breakpoint_command/TestRegexpBreakCommand.py
  
lldb/packages/Python/lldbsuite/test/functionalities/breakpoint/breakpoint_command/main.c
  
lldb/packages/Python/lldbsuite/test/functionalities/breakpoint/breakpoint_command/regex_break/Makefile
  
lldb/packages/Python/lldbsuite/test/functionalities/breakpoint/breakpoint_command/regex_break/TestRegexpBreakCommand.py
  
lldb/packages/Python/lldbsuite/test/functionalities/breakpoint/breakpoint_command/regex_break/a.c
  
lldb/packages/Python/lldbsuite/test/functionalities/breakpoint/breakpoint_command/regex_break/a.h
  
lldb/packages/Python/lldbsuite/test/functionalities/breakpoint/breakpoint_command/regex_break/a.mk
  
lldb/packages/Python/lldbsuite/test/functionalities/breakpoint/breakpoint_command/regex_break/main.c
  lldb/source/Interpreter/CommandInterpreter.cpp

Index: lldb/source/Interpreter/CommandInterpreter.cpp
===
--- lldb/source/Interpreter/CommandInterpreter.cpp
+++ lldb/source/Interpreter/CommandInterpreter.cpp
@@ -516,27 +516,28 @@
   CommandObjectSP(new CommandObjectLanguage(*this));
 
   const char *break_regexes[][2] = {
-  {"^(.*[^[:space:]])[[:space:]]*:[[:space:]]*([[:digit:]]+)[[:space:]]*$",
-   "breakpoint set --file '%1' --line %2"},
-  {"^/([^/]+)/$", "breakpoint set --source-pattern-regexp '%1'"},
-  {"^([[:digit:]]+)[[:space:]]*$", "breakpoint set --line %1"},
-  {"^\\*?(0x[[:xdigit:]]+)[[:space:]]*$", "breakpoint set --address %1"},
-  {"^[\"']?([-+]?\\[.*\\])[\"']?[[:space:]]*$",
-   "breakpoint set --name '%1'"},
+  {"^([^[:space:]]+)[[:space:]]*:[[:space:]]*([[:digit:]]+)(?:$|\\s+)(-.*)*$",
+   "breakpoint set --file '%1' --line %2 %3"},
+  {"/([^/]+)/(?:$|\\s+)(-.*)*$", "breakpoint set --source-pattern-regexp '%1' %2"},
+  {"^([[:digit:]]+)(?:$|\\s+)(-.*)*$", "breakpoint set --line %1 %2"},
+  {"^(0x[[:xdigit:]]+)(?:$|\\s+)(-.*)*$", "breakpoint set --address %1 %2"},
+  {"^[\"']?([-+]?\\[[^[:space:]\"']+\\s+[^[:space:]\"']+\\])[\"']?(?:$|\\s+)(-.*)*$",
+   "breakpoint set --name '%1' %2"}, // Objective-C Identifier
   {"^(-.*)$", "breakpoint set %1"},
-  {"^(.*[^[:space:]])`(.*[^[:space:]])[[:space:]]*$",
-   "breakpoint set --name '%2' --shlib '%1'"},
-  {"^\\&(.*[^[:space:]])[[:space:]]*$",
+  {"^([^[:space:]]+)`([^[:space:]]+)(?:$|\\s+)(-.*)*$",
+   "breakpoint set --name '%2' --shlib '%1' %3"},
+  {"^\\&([^[:space:]]+)(?:$|\\s+)(-.*)*$",
"breakpoint set --name '%1' --skip-prologue=0"},
-  {"^[\"']?(.*[^[:space:]\"'])[\"']?[[:space:]]*$",
-   "breakpoint set --name '%1'"}};
+  {"^[\"']?([^[:space:]\"']+)[\"']?(?:$|\\s+(-.*))*$",
+   "breakpoint set --name '%1' %2"}};
 
   size_t num_regexes = llvm::array_lengthof(break_regexes);
 
   std::unique_ptr break_regex_cmd_up(
   new CommandObjectRegexCommand(
   *this, "_regexp-break",
-  "Set a breakpoint using one of several shorthand formats.",
+  "Set a breakpoint using one of several shorthand formats. "
+  "Accepts breakpoint options.",
   "\n"
   "_regexp-break :\n"
   "  main.c:12 // Break at line 12 of "
@@ -561,7 +562,7 @@
   "current file\n"
   "// containing text 'break "
   "here'.\n",
-  2,
+  3,
   CommandCompletions::eSymbolCompletion |
   CommandCompletions::eSourceFileCompletion,
   false));
Index: lldb/packages/Python/lldbsuite/test/functionalities/breakpoint/breakpoint_command/regex_break/main.c
===
--- lldb/packages/Python/lldbsuite/test/functionalities/breakpoint/breakpoint_command/regex_break/main.c
+++ lldb/packages/Python/lldbsuite/test/functionalities/breakpoint/breakpoint_command/regex_break/main.c
@@ -1,4 +1,4 @@
-//===-- main.c --*- C++ -*-===//
+//===-- main.c *- C -*-===//
 //
 // Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
 // See https://llvm.org/LICENSE.txt for license information.
@@ -6,11 +6,14 @@
 //
 //===--===//
 
+#include "a.h"
+
 int main (int argc, char const *argv[])
 {
 // Add a body to the function, so we can set more than one
 // breakpoint in it.
 static volatile int var = 0;
 var++;
+method();
 return 0; // Set break po

[Lldb-commits] [lldb] r366363 - [CMake] Remove duplicated logic to find Python when doing a standalone build

2019-07-17 Thread Jonas Devlieghere via lldb-commits

Author: jdevlieghere
Date: Wed Jul 17 12:36:20 2019
New Revision: 366363

URL: http://llvm.org/viewvc/llvm-project?rev=366363&view=rev
Log:
[CMake] Remove duplicated logic to find Python when doing a standalone build

I'm pretty sure there's no need to have this logic living in
LLDBStandalone. It doesn't appear anything in LLVM depends on this, and
We always go through LLDBConfig.cmake which has the canonical way to
find the Python libs and interpreter for LLDB.

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

Modified:
lldb/trunk/cmake/modules/LLDBStandalone.cmake

Modified: lldb/trunk/cmake/modules/LLDBStandalone.cmake
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/cmake/modules/LLDBStandalone.cmake?rev=366363&r1=366362&r2=366363&view=diff
==
--- lldb/trunk/cmake/modules/LLDBStandalone.cmake (original)
+++ lldb/trunk/cmake/modules/LLDBStandalone.cmake Wed Jul 17 12:36:20 2019
@@ -77,18 +77,6 @@ include(HandleLLVMOptions)
 include(CheckAtomic)
 include(LLVMDistributionSupport)
 
-set(Python_ADDITIONAL_VERSIONS 3.7 3.6 3.5 2.7)
-if (PYTHON_EXECUTABLE STREQUAL "")
-  include(FindPythonInterp)
-  if( NOT PYTHONINTERP_FOUND )
-message(FATAL_ERROR
-"Unable to find Python interpreter, required for builds and 
testing.
-  Please install Python or specify the PYTHON_EXECUTABLE CMake 
variable.")
-  endif()
-else()
-  message(STATUS "Found PythonInterp: ${PYTHON_EXECUTABLE}")
-endif()
-
 set(PACKAGE_VERSION "${LLVM_PACKAGE_VERSION}")
 set(LLVM_INCLUDE_TESTS ON CACHE INTERNAL "")
 


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

[Lldb-commits] [PATCH] D64821: [CMake] Remove duplicated logic to find Python when doing a standalone build

2019-07-17 Thread Jonas Devlieghere via Phabricator via lldb-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rL366363: [CMake] Remove duplicated logic to find Python when 
doing a standalone build (authored by JDevlieghere, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D64821?vs=210177&id=210395#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D64821

Files:
  lldb/trunk/cmake/modules/LLDBStandalone.cmake


Index: lldb/trunk/cmake/modules/LLDBStandalone.cmake
===
--- lldb/trunk/cmake/modules/LLDBStandalone.cmake
+++ lldb/trunk/cmake/modules/LLDBStandalone.cmake
@@ -77,18 +77,6 @@
 include(CheckAtomic)
 include(LLVMDistributionSupport)
 
-set(Python_ADDITIONAL_VERSIONS 3.7 3.6 3.5 2.7)
-if (PYTHON_EXECUTABLE STREQUAL "")
-  include(FindPythonInterp)
-  if( NOT PYTHONINTERP_FOUND )
-message(FATAL_ERROR
-"Unable to find Python interpreter, required for builds and 
testing.
-  Please install Python or specify the PYTHON_EXECUTABLE CMake 
variable.")
-  endif()
-else()
-  message(STATUS "Found PythonInterp: ${PYTHON_EXECUTABLE}")
-endif()
-
 set(PACKAGE_VERSION "${LLVM_PACKAGE_VERSION}")
 set(LLVM_INCLUDE_TESTS ON CACHE INTERNAL "")
 


Index: lldb/trunk/cmake/modules/LLDBStandalone.cmake
===
--- lldb/trunk/cmake/modules/LLDBStandalone.cmake
+++ lldb/trunk/cmake/modules/LLDBStandalone.cmake
@@ -77,18 +77,6 @@
 include(CheckAtomic)
 include(LLVMDistributionSupport)
 
-set(Python_ADDITIONAL_VERSIONS 3.7 3.6 3.5 2.7)
-if (PYTHON_EXECUTABLE STREQUAL "")
-  include(FindPythonInterp)
-  if( NOT PYTHONINTERP_FOUND )
-message(FATAL_ERROR
-"Unable to find Python interpreter, required for builds and testing.
-  Please install Python or specify the PYTHON_EXECUTABLE CMake variable.")
-  endif()
-else()
-  message(STATUS "Found PythonInterp: ${PYTHON_EXECUTABLE}")
-endif()
-
 set(PACKAGE_VERSION "${LLVM_PACKAGE_VERSION}")
 set(LLVM_INCLUDE_TESTS ON CACHE INTERNAL "")
 
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] r366364 - [docs] Adjust variable formatting table

2019-07-17 Thread Jonas Devlieghere via lldb-commits

Author: jdevlieghere
Date: Wed Jul 17 12:49:01 2019
New Revision: 366364

URL: http://llvm.org/viewvc/llvm-project?rev=366364&view=rev
Log:
[docs] Adjust variable formatting table

While the in-place hints on valid formats are up to date (e.g. when
choosing an invalid format expr -f nonExisting -- 42), the corresponding
online docs table is not. The formats "address", "hex float",
"instruction" and "void" are missing, and "decimal" refers to an
outdated abbreviation 'i' instead of 'd'.

Patch by: Lukas Böger

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

Modified:
lldb/trunk/docs/use/variable.rst

Modified: lldb/trunk/docs/use/variable.rst
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/docs/use/variable.rst?rev=366364&r1=366363&r2=366364&view=diff
==
--- lldb/trunk/docs/use/variable.rst (original)
+++ lldb/trunk/docs/use/variable.rst Wed Jul 17 12:49:01 2019
@@ -197,7 +197,7 @@ pick:
 
+---+--+--+
 | ``c-string``  | s| show this 
as a 0-terminated C string |
 
+---+--+--+
-| ``decimal``   | i| show this 
as a signed integer number (this does not perform a cast, it   |
+| ``decimal``   | d| show this 
as a signed integer number (this does not perform a cast, it   |
 |   |  | simply 
shows the bytes as  an integer with sign) |
 
+---+--+--+
 | ``enumeration``   | E| show this 
as an enumeration, printing the|
@@ -239,6 +239,15 @@ pick:
 
+---+--+--+
 | ``character array``   | a| show this 
as a character array   |
 
+---+--+--+
+| ``address``   | A| show this 
as an address target (symbol/file/line + offset), possibly |
+|   |  | also the 
string this address is pointing to  |
++---+--+--+
+| ``hex float`` |  | show this 
as hexadecimal floating point  |
++---+--+--+
+| ``instruction``   | i| show this 
as an disassembled opcode  |
++---+--+--+
+| ``void``  | v| don't 
show anything  |
++---+--+--+
 
 Type Summary
 


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

[Lldb-commits] [PATCH] D63813: Adjust variable formatting table

2019-07-17 Thread Jonas Devlieghere via Phabricator via lldb-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rL366364: [docs] Adjust variable formatting table (authored by 
JDevlieghere, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D63813?vs=210278&id=210397#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D63813

Files:
  lldb/trunk/docs/use/variable.rst


Index: lldb/trunk/docs/use/variable.rst
===
--- lldb/trunk/docs/use/variable.rst
+++ lldb/trunk/docs/use/variable.rst
@@ -197,7 +197,7 @@
 
+---+--+--+
 | ``c-string``  | s| show this 
as a 0-terminated C string |
 
+---+--+--+
-| ``decimal``   | i| show this 
as a signed integer number (this does not perform a cast, it   |
+| ``decimal``   | d| show this 
as a signed integer number (this does not perform a cast, it   |
 |   |  | simply 
shows the bytes as  an integer with sign) |
 
+---+--+--+
 | ``enumeration``   | E| show this 
as an enumeration, printing the|
@@ -239,6 +239,15 @@
 
+---+--+--+
 | ``character array``   | a| show this 
as a character array   |
 
+---+--+--+
+| ``address``   | A| show this 
as an address target (symbol/file/line + offset), possibly |
+|   |  | also the 
string this address is pointing to  |
++---+--+--+
+| ``hex float`` |  | show this 
as hexadecimal floating point  |
++---+--+--+
+| ``instruction``   | i| show this 
as an disassembled opcode  |
++---+--+--+
+| ``void``  | v| don't 
show anything  |
++---+--+--+
 
 Type Summary
 


Index: lldb/trunk/docs/use/variable.rst
===
--- lldb/trunk/docs/use/variable.rst
+++ lldb/trunk/docs/use/variable.rst
@@ -197,7 +197,7 @@
 +---+--+--+
 | ``c-string``  | s| show this as a 0-terminated C string |
 +---+--+--+
-| ``decimal``   | i| show this as a signed integer number (this does not perform a cast, it   |
+| ``decimal``   | d| show this as a signed integer number (this does not perform a cast, it   |
 |   |  | simply shows the bytes as  an integer with sign) |
 +---+--+--+
 | ``enumeration``   | E| show this as an enumeration, print

[Lldb-commits] [PATCH] D64844: [Target] Remove Target::GetScratchClangASTContext

2019-07-17 Thread Alex Langford via Phabricator via lldb-commits

xiaobai added a comment.

Yes, I agree that replacing ClangASTContext uses with TypeSystem would be the 
right thing to do, and it's what I plan on doing next. There are instances 
where you really do want a ClangASTContext (e.g. in plugins related to clang 
expression parsing and objc), and so having a convenience function like this 
means you don't have to cast the result of every call. This is similar to 
`ObjCLanguageRuntime::Get`. I don't mind abandoning this patch though.

Luckily, like you pointed out, most uses of ClangASTContext are very 
generalizable so it shouldn't be too bad to change things over.


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

https://reviews.llvm.org/D64844



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

[Lldb-commits] [lldb] r366365 - Fix CreateFunctionTemplateSpecialization to prevent dangling poiner to stack memory

2019-07-17 Thread Shafik Yaghmour via lldb-commits

Author: shafik
Date: Wed Jul 17 13:16:13 2019
New Revision: 366365

URL: http://llvm.org/viewvc/llvm-project?rev=366365&view=rev
Log:
Fix CreateFunctionTemplateSpecialization to prevent dangling poiner to stack 
memory

In ClangASTContext::CreateFunctionTemplateSpecializationInfo a 
TemplateArgumentList is allocated on the stack but is treated as if it is 
persistent in subsequent calls. When we exit the function func_decl will still 
point to the stack allocated memory. We will use 
TemplateArgumentList::CreateCopy instead which will allocate memory out of the 
DeclContext.

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

Added:

lldb/trunk/packages/Python/lldbsuite/test/expression_command/function_template_specialization_temp_args/

lldb/trunk/packages/Python/lldbsuite/test/expression_command/function_template_specialization_temp_args/Makefile

lldb/trunk/packages/Python/lldbsuite/test/expression_command/function_template_specialization_temp_args/TestFunctionTemplateSpecializationTempArgs.py

lldb/trunk/packages/Python/lldbsuite/test/expression_command/function_template_specialization_temp_args/main.cpp
Modified:
lldb/trunk/source/Symbol/ClangASTContext.cpp

Added: 
lldb/trunk/packages/Python/lldbsuite/test/expression_command/function_template_specialization_temp_args/Makefile
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/expression_command/function_template_specialization_temp_args/Makefile?rev=366365&view=auto
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/expression_command/function_template_specialization_temp_args/Makefile
 (added)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/expression_command/function_template_specialization_temp_args/Makefile
 Wed Jul 17 13:16:13 2019
@@ -0,0 +1,5 @@
+LEVEL = ../../make
+
+CXX_SOURCES := main.cpp
+
+include $(LEVEL)/Makefile.rules

Added: 
lldb/trunk/packages/Python/lldbsuite/test/expression_command/function_template_specialization_temp_args/TestFunctionTemplateSpecializationTempArgs.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/expression_command/function_template_specialization_temp_args/TestFunctionTemplateSpecializationTempArgs.py?rev=366365&view=auto
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/expression_command/function_template_specialization_temp_args/TestFunctionTemplateSpecializationTempArgs.py
 (added)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/expression_command/function_template_specialization_temp_args/TestFunctionTemplateSpecializationTempArgs.py
 Wed Jul 17 13:16:13 2019
@@ -0,0 +1,17 @@
+import lldb
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+
+class TestFunctionTemplateSpecializationTempArgs(TestBase):
+
+mydir = TestBase.compute_mydir(__file__)
+
+def test_function_template_specialization_temp_args(self):
+self.build()
+
+(self.target, self.process, _, bkpt) = 
lldbutil.run_to_source_breakpoint(self, '// break here',
+lldb.SBFileSpec("main.cpp", False))
+
+self.expect("expr p0",
+substrs=['(VType) $0 = {}'])

Added: 
lldb/trunk/packages/Python/lldbsuite/test/expression_command/function_template_specialization_temp_args/main.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/expression_command/function_template_specialization_temp_args/main.cpp?rev=366365&view=auto
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/expression_command/function_template_specialization_temp_args/main.cpp
 (added)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/expression_command/function_template_specialization_temp_args/main.cpp
 Wed Jul 17 13:16:13 2019
@@ -0,0 +1,17 @@
+template  struct M {};
+
+template  void f(T &t);
+
+template <> void f(int &t) {
+  typedef M VType;
+
+  VType p0; // break here
+}
+
+int main() {
+  int x;
+
+  f(x);
+
+  return 0;
+}

Modified: lldb/trunk/source/Symbol/ClangASTContext.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Symbol/ClangASTContext.cpp?rev=366365&r1=366364&r2=366365&view=diff
==
--- lldb/trunk/source/Symbol/ClangASTContext.cpp (original)
+++ lldb/trunk/source/Symbol/ClangASTContext.cpp Wed Jul 17 13:16:13 2019
@@ -1615,10 +1615,11 @@ clang::FunctionTemplateDecl *ClangASTCon
 void ClangASTContext::CreateFunctionTemplateSpecializationInfo(
 FunctionDecl *func_decl, clang::FunctionTemplateDecl *func_tmpl_decl,
 const TemplateParameterInfos &infos) {
-  TemplateArgumentList template_args(TemplateArgumentList::OnStack, 
infos.args);
+  TemplateArgumentList *template_args_ptr =
+  TemplateArgumentList::Create

[Lldb-commits] [PATCH] D64777: Fix CreateFunctionTemplateSpecialization to prevent dangling poiner to stack memory

2019-07-17 Thread Shafik Yaghmour via Phabricator via lldb-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rGa0858e2f20c8: Fix CreateFunctionTemplateSpecialization to 
prevent dangling poiner to stack… (authored by shafik).
Herald added a project: LLDB.

Changed prior to commit:
  https://reviews.llvm.org/D64777?vs=210127&id=210398#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D64777

Files:
  
lldb/packages/Python/lldbsuite/test/expression_command/function_template_specialization_temp_args/Makefile
  
lldb/packages/Python/lldbsuite/test/expression_command/function_template_specialization_temp_args/TestFunctionTemplateSpecializationTempArgs.py
  
lldb/packages/Python/lldbsuite/test/expression_command/function_template_specialization_temp_args/main.cpp
  lldb/source/Symbol/ClangASTContext.cpp


Index: lldb/source/Symbol/ClangASTContext.cpp
===
--- lldb/source/Symbol/ClangASTContext.cpp
+++ lldb/source/Symbol/ClangASTContext.cpp
@@ -1615,10 +1615,11 @@
 void ClangASTContext::CreateFunctionTemplateSpecializationInfo(
 FunctionDecl *func_decl, clang::FunctionTemplateDecl *func_tmpl_decl,
 const TemplateParameterInfos &infos) {
-  TemplateArgumentList template_args(TemplateArgumentList::OnStack, 
infos.args);
+  TemplateArgumentList *template_args_ptr =
+  TemplateArgumentList::CreateCopy(func_decl->getASTContext(), infos.args);
 
-  func_decl->setFunctionTemplateSpecialization(func_tmpl_decl, &template_args,
-   nullptr);
+  func_decl->setFunctionTemplateSpecialization(func_tmpl_decl,
+   template_args_ptr, nullptr);
 }
 
 ClassTemplateDecl *ClangASTContext::CreateClassTemplateDecl(
Index: 
lldb/packages/Python/lldbsuite/test/expression_command/function_template_specialization_temp_args/main.cpp
===
--- /dev/null
+++ 
lldb/packages/Python/lldbsuite/test/expression_command/function_template_specialization_temp_args/main.cpp
@@ -0,0 +1,17 @@
+template  struct M {};
+
+template  void f(T &t);
+
+template <> void f(int &t) {
+  typedef M VType;
+
+  VType p0; // break here
+}
+
+int main() {
+  int x;
+
+  f(x);
+
+  return 0;
+}
Index: 
lldb/packages/Python/lldbsuite/test/expression_command/function_template_specialization_temp_args/TestFunctionTemplateSpecializationTempArgs.py
===
--- /dev/null
+++ 
lldb/packages/Python/lldbsuite/test/expression_command/function_template_specialization_temp_args/TestFunctionTemplateSpecializationTempArgs.py
@@ -0,0 +1,17 @@
+import lldb
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+
+class TestFunctionTemplateSpecializationTempArgs(TestBase):
+
+mydir = TestBase.compute_mydir(__file__)
+
+def test_function_template_specialization_temp_args(self):
+self.build()
+
+(self.target, self.process, _, bkpt) = 
lldbutil.run_to_source_breakpoint(self, '// break here',
+lldb.SBFileSpec("main.cpp", False))
+
+self.expect("expr p0",
+substrs=['(VType) $0 = {}'])
Index: 
lldb/packages/Python/lldbsuite/test/expression_command/function_template_specialization_temp_args/Makefile
===
--- /dev/null
+++ 
lldb/packages/Python/lldbsuite/test/expression_command/function_template_specialization_temp_args/Makefile
@@ -0,0 +1,5 @@
+LEVEL = ../../make
+
+CXX_SOURCES := main.cpp
+
+include $(LEVEL)/Makefile.rules


Index: lldb/source/Symbol/ClangASTContext.cpp
===
--- lldb/source/Symbol/ClangASTContext.cpp
+++ lldb/source/Symbol/ClangASTContext.cpp
@@ -1615,10 +1615,11 @@
 void ClangASTContext::CreateFunctionTemplateSpecializationInfo(
 FunctionDecl *func_decl, clang::FunctionTemplateDecl *func_tmpl_decl,
 const TemplateParameterInfos &infos) {
-  TemplateArgumentList template_args(TemplateArgumentList::OnStack, infos.args);
+  TemplateArgumentList *template_args_ptr =
+  TemplateArgumentList::CreateCopy(func_decl->getASTContext(), infos.args);
 
-  func_decl->setFunctionTemplateSpecialization(func_tmpl_decl, &template_args,
-   nullptr);
+  func_decl->setFunctionTemplateSpecialization(func_tmpl_decl,
+   template_args_ptr, nullptr);
 }
 
 ClassTemplateDecl *ClangASTContext::CreateClassTemplateDecl(
Index: lldb/packages/Python/lldbsuite/test/expression_command/function_template_specialization_temp_args/main.cpp
===
--- /dev/null
+++ lldb/packages/Python/lldbsuite/test/expression_command/function_template_specialization_temp_args

[Lldb-commits] [PATCH] D64881: [Cmake] Use the modern way to find Python when possible

2019-07-17 Thread Jonas Devlieghere via Phabricator via lldb-commits

JDevlieghere created this revision.
JDevlieghere added reviewers: sgraenitz, labath, xiaobai, amccarth, 
stella.stamenova, compnerd.
JDevlieghere added a project: LLDB.
Herald added subscribers: abidh, mgorny.

CMake has a much improved way to find the Python interpreter and libraries 
which guarantees that the interpreter and libraries are the same. However, this 
functionality is only available in CMake 3.12 and later. This patch changes the 
CMake logic to use that without bumping the minimum CMake version.

Question for people familiar with CMake on Windows: do you think that 
FindPython could replace the current logic in find_python_libs_windows? So we 
could do something like:

  if(NOT CMAKE_VERSION VERSION_LESS "3.12")
# Use FindPython
  else()
if (Windows) 
 # use find_python_libs_windows
else()
 # use PythonInterp / PythonLibs
endif()
  endif()


Repository:
  rLLDB LLDB

https://reviews.llvm.org/D64881

Files:
  lldb/cmake/modules/LLDBConfig.cmake


Index: lldb/cmake/modules/LLDBConfig.cmake
===
--- lldb/cmake/modules/LLDBConfig.cmake
+++ lldb/cmake/modules/LLDBConfig.cmake
@@ -185,6 +185,28 @@
   message(STATUS "LLDB Found PythonIncludeDirs: ${PYTHON_INCLUDE_DIR}")
 endfunction(find_python_libs_windows)
 
+function(find_python_libs)
+  if(NOT CMAKE_VERSION VERSION_LESS "3.12")
+find_package(Python COMPONENTS Interpreter Development)
+if(Python_FOUND)
+  set(PYTHON_EXECUTABLE  ${Python_EXECUTABLE})
+  set(PYTHON_LIBRARY ${Python_LIBRARIES})
+  set(PYTHON_INCLUDE_DIR ${Python_INCLUDE_DIRS})
+  set(PYTHON_VERSION_STRING  ${Python_VERSION})
+  set(PYTHONLIBS_VERSION_STRING  ${Python_VERSION})
+
+  set(PYTHON_EXECUTABLE  ${PYTHON_EXECUTABLE} PARENT_SCOPE)
+  set(PYTHON_LIBRARY ${PYTHON_LIBRARY} PARENT_SCOPE)
+  set(PYTHON_INCLUDE_DIR ${PYTHON_INCLUDE_DIR} PARENT_SCOPE)
+  set(PYTHON_VERSION_STRING  ${PYTHON_VERSION_STRING} PARENT_SCOPE)
+  set(PYTHONLIBS_VERSION_STRING  ${PYTHONLIBS_VERSION_STRING} PARENT_SCOPE)
+endif()
+  else()
+find_package(PythonInterp REQUIRED)
+find_package(PythonLibs REQUIRED)
+  endif()
+endfunction(find_python_libs)
+
 if (NOT LLDB_DISABLE_PYTHON)
   if ("${CMAKE_SYSTEM_NAME}" STREQUAL "Windows")
 find_python_libs_windows()
@@ -194,8 +216,7 @@
   add_definitions( -DLLDB_PYTHON_HOME="${LLDB_PYTHON_HOME}" )
 endif()
   else()
-find_package(PythonInterp REQUIRED)
-find_package(PythonLibs REQUIRED)
+find_python_libs()
   endif()
 
   if (NOT PYTHON_VERSION_STRING VERSION_EQUAL PYTHONLIBS_VERSION_STRING AND


Index: lldb/cmake/modules/LLDBConfig.cmake
===
--- lldb/cmake/modules/LLDBConfig.cmake
+++ lldb/cmake/modules/LLDBConfig.cmake
@@ -185,6 +185,28 @@
   message(STATUS "LLDB Found PythonIncludeDirs: ${PYTHON_INCLUDE_DIR}")
 endfunction(find_python_libs_windows)
 
+function(find_python_libs)
+  if(NOT CMAKE_VERSION VERSION_LESS "3.12")
+find_package(Python COMPONENTS Interpreter Development)
+if(Python_FOUND)
+  set(PYTHON_EXECUTABLE  ${Python_EXECUTABLE})
+  set(PYTHON_LIBRARY ${Python_LIBRARIES})
+  set(PYTHON_INCLUDE_DIR ${Python_INCLUDE_DIRS})
+  set(PYTHON_VERSION_STRING  ${Python_VERSION})
+  set(PYTHONLIBS_VERSION_STRING  ${Python_VERSION})
+
+  set(PYTHON_EXECUTABLE  ${PYTHON_EXECUTABLE} PARENT_SCOPE)
+  set(PYTHON_LIBRARY ${PYTHON_LIBRARY} PARENT_SCOPE)
+  set(PYTHON_INCLUDE_DIR ${PYTHON_INCLUDE_DIR} PARENT_SCOPE)
+  set(PYTHON_VERSION_STRING  ${PYTHON_VERSION_STRING} PARENT_SCOPE)
+  set(PYTHONLIBS_VERSION_STRING  ${PYTHONLIBS_VERSION_STRING} PARENT_SCOPE)
+endif()
+  else()
+find_package(PythonInterp REQUIRED)
+find_package(PythonLibs REQUIRED)
+  endif()
+endfunction(find_python_libs)
+
 if (NOT LLDB_DISABLE_PYTHON)
   if ("${CMAKE_SYSTEM_NAME}" STREQUAL "Windows")
 find_python_libs_windows()
@@ -194,8 +216,7 @@
   add_definitions( -DLLDB_PYTHON_HOME="${LLDB_PYTHON_HOME}" )
 endif()
   else()
-find_package(PythonInterp REQUIRED)
-find_package(PythonLibs REQUIRED)
+find_python_libs()
   endif()
 
   if (NOT PYTHON_VERSION_STRING VERSION_EQUAL PYTHONLIBS_VERSION_STRING AND
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D64881: [Cmake] Use the modern way to find Python when possible

2019-07-17 Thread Adrian McCarthy via Phabricator via lldb-commits

amccarth added a comment.

An aside ...

I'm still trying to get back to a buildable state the earlier changes, like the 
one that tries to enforce version consistency between the libs and the 
interpreter.  I'm currently bisecting to figure out what I hope is the final 
blocker.

For me, the find_package(PythonInterp) call was always finding the older 
interpreter (2.7) even though everything pointed to the newer one (3.6).  That 
tripped the version compatibility check that was recently added.  The algorithm 
used by find_package isn't well documented (as far as I can tell), so I 
couldn't even tell you whether it was doing the wrong thing.  I can tell you 
that the version check seemed unnecessary, as lldb built and tested fine when I 
locally removed that check, despite the fact that the versions didn't match.

The only way I was able to make things work again was to completely remove 
Python 2.7 from my machine.  Oddly, the uninstaller also took make with it, so 
then I couldn't run lldb tests.  With make re-installed, I now have a some 
crashes during tests to the Python allocator being called without the GIL being 
held.  I'm currently bisecting to figure out which change caused that.  This 
crash is especially painful, as it leaves an invisible Python process running 
and holding files open, which breaks subsequent builds.

To your question ...

Without understanding how either version of find_package finds Python, it's 
hard to say whether it solves the problems outlined in Zach's comment at the 
top of find_python_libs.  Zach's first two points don't apply anymore, as we're 
well past MSVC 2015.  But the third one, regarding a 32-bit CMake being able to 
find a 64-bit Python, seems like it would still be a problem.


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D64881



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

[Lldb-commits] [PATCH] D64853: Fix CommandInterpreter for _regex-break with options

2019-07-17 Thread Jonas Devlieghere via Phabricator via lldb-commits

JDevlieghere added inline comments.



Comment at: 
lldb/packages/Python/lldbsuite/test/functionalities/breakpoint/breakpoint_command/regex_break/TestRegexpBreakCommand.py:5
+
+from __future__ import print_function
+

I don't think you need this.



Comment at: 
lldb/packages/Python/lldbsuite/test/functionalities/breakpoint/breakpoint_command/regex_break/TestRegexpBreakCommand.py:23
+self.build()
+self.regexp_break_command_line()
+

Why not inline the test? Now you have two doc-strings, which are slightly 
different. 



Comment at: 
lldb/packages/Python/lldbsuite/test/functionalities/breakpoint/breakpoint_command/regex_break/TestRegexpBreakCommand.py:58
+TestBase.setUp(self)
+self.runCmd("settings set use-color false")
+# Find the line number to break inside main().

This is no longer necessary 



Comment at: 
lldb/packages/Python/lldbsuite/test/functionalities/breakpoint/breakpoint_command/regex_break/TestRegexpBreakCommand.py:107
+
+break_results = lldbutil.run_break_set_command(
+self, "b %s:%d" % (self.source, self.line))

`# Check breakpoint with relative file path.`



Comment at: 
lldb/packages/Python/lldbsuite/test/functionalities/breakpoint/breakpoint_command/regex_break/TestRegexpBreakCommand.py:130
+# The stop reason of the thread should be breakpoint.
+self.expect("thread list", STOPPED_DUE_TO_BREAKPOINT,
+substrs=['stopped',

Since this is repeated in every function, I'd factor this out into a method. 



Comment at: 
lldb/packages/Python/lldbsuite/test/functionalities/breakpoint/breakpoint_command/regex_break/TestRegexpBreakCommand.py:171
+break_results = lldbutil.run_break_set_command(
+self, "b %s" %
+function_name)

We discussed a few scenarios yesterday with single and double quotes. Any 
reason you didn't include those?



Comment at: 
lldb/packages/Python/lldbsuite/test/functionalities/breakpoint/breakpoint_command/regex_break/TestRegexpBreakCommand.py:243
+def regexp_break_command_regex(self):
+"""Test the super consie "b" command with a regular expression, which 
is analias for _regexp-break."""
+exe = self.getBuildArtifact("a.out")

s/consie/concise/



Comment at: 
lldb/packages/Python/lldbsuite/test/functionalities/breakpoint/breakpoint_command/regex_break/main.c:1
-//===-- main.c --*- C++ 
-*-===//
+//===-- main.c *- C 
-*-===//
 //

Just remove the header


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D64853



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

[Lldb-commits] [PATCH] D64806: [CMake] Always build debugserver on Darwin and allow tests to use the system's one

2019-07-17 Thread Saleem Abdulrasool via Phabricator via lldb-commits

compnerd added inline comments.

Comment at: lldb/cmake/modules/AddLLDB.cmake:292
+  else()
+string(STRIP ${xcode_dev_dir} xcode_dev_dir)
+set(subdir "LLDB.framework/Resources/debugserver")

Can you add a comment explaining that you want to strip leading whitespace?  
Alternatively, if its trailing whitespace, please use 
`OUTPUT_STRIP_TRAILING_WHITESPACE` in the `execute_process` on L288 please.

Comment at: lldb/cmake/modules/AddLLDB.cmake:293
+string(STRIP ${xcode_dev_dir} xcode_dev_dir)
+set(subdir "LLDB.framework/Resources/debugserver")
+set(path_shared "${xcode_dev_dir}/../SharedFrameworks/${subdir}")

I think that `subdir` is a misleading name.  This is the path to debugserver, 
`subdir` should be `LLDB.framework/Resources`.  I don't really have an opinion 
on renaming the variable or composing the variable, that choice is yours :-)

Comment at: lldb/tools/debugserver/source/CMakeLists.txt:258
   endif()
-endif()
+#endif()

sgraenitz wrote:
> Removing the `if() ... endif()` would bloat the diff even more. Would do it 
> in a follow-up NFC commit.
Sure, although ignoring whitespace also is helpful :-)

Comment at: lldb/unittests/CMakeLists.txt:83
   add_subdirectory(debugserver)
 endif()

Shouldn't debugserver not be available always?  It doesn't matter if it isn't 
being used.  Furthermore, elision from the distribution targets will also 
prevent the unnecessary build so there is no need to worry about the default 
builds being longer than necessary.

Comment at: lldb/unittests/tools/lldb-server/CMakeLists.txt:16

-if(DEBUGSERVER_PATH)
-  add_definitions(-DLLDB_SERVER="${DEBUGSERVER_PATH}" 
-DLLDB_SERVER_IS_DEBUGSERVER=1)
+if(LLDB_CAN_USE_DEBUGSERVER)
+  if(LLDB_USE_SYSTEM_DEBUGSERVER)

Why is this being checked in `lldb-server`?

Comment at: lldb/unittests/tools/lldb-server/CMakeLists.txt:20
+  else()
+set(debugserver_path $)
+  endif()

Should this not be `debugserver`?

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D64806

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

[Lldb-commits] [PATCH] D64013: Correctly use GetLoadedModuleList to take advantage of libraries-svr4

2019-07-17 Thread António Afonso via Phabricator via lldb-commits

aadsm updated this revision to Diff 210413.
aadsm added a comment.

Address comments.
In the end I used nested switches for the GetAction function. I thought about 
it and I guess it boils down to personal preference. It's still harder for me 
to read than the if version so I put some empty lines to improve that.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D64013

Files:
  lldb/include/lldb/Target/Process.h
  lldb/source/Plugins/DynamicLoader/POSIX-DYLD/DYLDRendezvous.cpp
  lldb/source/Plugins/DynamicLoader/POSIX-DYLD/DYLDRendezvous.h
  lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
  lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.h

Index: lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.h
===
--- lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.h
+++ lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.h
@@ -200,9 +200,9 @@
 
   llvm::VersionTuple GetHostOSVersion() override;
 
-  size_t LoadModules(LoadedModuleInfoList &module_list) override;
+  llvm::Error LoadModules() override;
 
-  size_t LoadModules() override;
+  llvm::Expected GetLoadedModuleList() override;
 
   Status GetFileLoadAddress(const FileSpec &file, bool &is_loaded,
 lldb::addr_t &load_addr) override;
@@ -386,9 +386,6 @@
   // Query remote GDBServer for register information
   bool GetGDBServerRegisterInfo(ArchSpec &arch);
 
-  // Query remote GDBServer for a detailed loaded library list
-  Status GetLoadedModuleList(LoadedModuleInfoList &);
-
   lldb::ModuleSP LoadModuleAtAddress(const FileSpec &file,
  lldb::addr_t link_map,
  lldb::addr_t base_addr,
Index: lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
===
--- lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
+++ lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
@@ -2375,7 +2375,14 @@
 ostr.Printf("%" PRIu64 " %" PRIu32, wp_addr, wp_index);
 description = ostr.GetString();
   } else if (key.compare("library") == 0) {
-LoadModules();
+auto error = LoadModules();
+if (error) {
+  Log *log(
+  ProcessGDBRemoteLog::GetLogIfAllCategoriesSet(GDBR_LOG_PROCESS));
+  LLDB_LOG_ERROR(log, std::move(error),
+ "ProcessGDBRemote::{1} failed to load modules: {0}",
+ __FUNCTION__);
+}
   } else if (key.size() == 2 && ::isxdigit(key[0]) && ::isxdigit(key[1])) {
 uint32_t reg = UINT32_MAX;
 if (!key.getAsInteger(16, reg))
@@ -2728,9 +2735,15 @@
 
   // the loaded module list can also provides a link map address
   if (addr == LLDB_INVALID_ADDRESS) {
-LoadedModuleInfoList list;
-if (GetLoadedModuleList(list).Success())
-  addr = list.m_link_map;
+llvm::Expected list = GetLoadedModuleList();
+if (!list) {
+  Log *log(ProcessGDBRemoteLog::GetLogIfAllCategoriesSet(GDBR_LOG_PROCESS));
+  LLDB_LOG_ERROR(log, list.takeError(),
+ "ProcessGDBRemote::{1} failed to read module list: {0}",
+ __FUNCTION__);
+} else {
+  addr = list->m_link_map;
+}
   }
 
   return addr;
@@ -4648,28 +4661,29 @@
   return m_register_info.GetNumRegisters() > 0;
 }
 
-Status ProcessGDBRemote::GetLoadedModuleList(LoadedModuleInfoList &list) {
+llvm::Expected ProcessGDBRemote::GetLoadedModuleList() {
   // Make sure LLDB has an XML parser it can use first
   if (!XMLDocument::XMLEnabled())
-return Status(0, ErrorType::eErrorTypeGeneric);
+return llvm::createStringError(llvm::inconvertibleErrorCode(),
+   "XML parsing not available");
 
   Log *log = GetLogIfAnyCategoriesSet(LIBLLDB_LOG_PROCESS);
   if (log)
 log->Printf("ProcessGDBRemote::%s", __FUNCTION__);
 
+  LoadedModuleInfoList list;
   GDBRemoteCommunicationClient &comm = m_gdb_comm;
 
   // check that we have extended feature read support
   if (comm.GetQXferLibrariesSVR4ReadSupported()) {
-list.clear();
-
 // request the loaded library list
 std::string raw;
 lldb_private::Status lldberr;
 
 if (!comm.ReadExtFeature(ConstString("libraries-svr4"), ConstString(""),
  raw, lldberr))
-  return Status(0, ErrorType::eErrorTypeGeneric);
+  return llvm::createStringError(llvm::inconvertibleErrorCode(),
+ "Error in libraries-svr4 packet");
 
 // parse the xml file in memory
 if (log)
@@ -4677,11 +4691,14 @@
 XMLDocument doc;
 
 if (!doc.ParseMemory(raw.c_str(), raw.size(), "noname.xml"))
-  return Status(0, ErrorType::eErrorTypeGeneric);
+  return llvm::createStringError(llvm::inconvertibleErrorCode(),
+

[Lldb-commits] [PATCH] D64881: [Cmake] Use the modern way to find Python when possible

2019-07-17 Thread Jonas Devlieghere via Phabricator via lldb-commits

JDevlieghere added a comment.

In D64881#1590204 , @amccarth wrote:

> An aside ...
>
> I'm still trying to get back to a buildable state the earlier changes, like 
> the one that tries to enforce version consistency between the libs and the 
> interpreter.  I'm currently bisecting to figure out what I hope is the final 
> blocker.


Maybe we should just revert D64443 ? This is 
what broke my setup, and led me to introduce to the consistency check in the 
first place, which merely diagnoses a real problem.

> For me, the find_package(PythonInterp) call was always finding the older 
> interpreter (2.7) even though everything pointed to the newer one (3.6).  
> That tripped the version compatibility check that was recently added.  The 
> algorithm used by find_package isn't well documented (as far as I can tell), 
> so I couldn't even tell you whether it was doing the wrong thing.  I can tell 
> you that the version check seemed unnecessary, as lldb built and tested fine 
> when I locally removed that check, despite the fact that the versions didn't 
> match.

This is interesting, for me on macOS, it was the other way around. It would 
always find the 3.7 interpreter because of the LLVM change and never find the 
corresponding python libs for 3.7 in LLDB. I had to remove every trace of the 
Python 3 interpreter, for it to only find the 2.7 one. Anyway, I think we all 
agree (CMake developers included) that the old way of doing things is 
inherently broken. That's why I want to start adopting the new FindPython.

> The only way I was able to make things work again was to completely remove 
> Python 2.7 from my machine.  Oddly, the uninstaller also took make with it, 
> so then I couldn't run lldb tests.  With make re-installed, I now have a some 
> crashes during tests to the Python allocator being called without the GIL 
> being held.  I'm currently bisecting to figure out which change caused that.  
> This crash is especially painful, as it leaves an invisible Python process 
> running and holding files open, which breaks subsequent builds.
> 
> To your question ...
> 
> Without understanding how either version of find_package finds Python, it's 
> hard to say whether it solves the problems outlined in Zach's comment at the 
> top of find_python_libs.  Zach's first two points don't apply anymore, as 
> we're well past MSVC 2015.  But the third one, regarding a 32-bit CMake being 
> able to find a 64-bit Python, seems like it would still be a problem.

Thanks, I guess we'd just need to try it then.


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D64881



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

[Lldb-commits] [PATCH] D64881: [Cmake] Use the modern way to find Python when possible

2019-07-17 Thread Stella Stamenova via Phabricator via lldb-commits

stella.stamenova added a comment.

Re: Windows CMake: I am not sure, I'd have to do look into it further.

On a separate note: I haven't looked into it yet, but we have a setup to run 
the LLDB tests on Ubuntu and that started failing somewhat recently with some 
Swig and Python errors. For example:

  Unable to load lldb extension module.  Possible reasons for this include:
1) LLDB was built with LLDB_DISABLE_PYTHON=1
2) PYTHONPATH and PYTHONHOME are not set correctly.  PYTHONHOME should 
refer to
   the version of Python that LLDB built and linked against, and PYTHONPATH
   should contain the Lib directory for the same python distro, as well as 
the
   location of LLDB's site-packages folder.
3) A different version of Python than that which was built against is 
exported in
   the system's PATH environment variable, causing conflicts.
4) The executable '/home/e2admin/vstsdrive/_work/29/b/bin/lldb' could not 
be found.  Please check 
   that it exists and is executable.
  Traceback (most recent call last):
File "/home/e2admin/vstsdrive/_work/29/s/lldb/test/dotest.py", line 7, in 

  lldbsuite.test.run_suite()
File 
"/home/e2admin/vstsdrive/_work/29/s/lldb/packages/Python/lldbsuite/test/dotest.py",
 line 1268, in run_suite
  import lldb
  ImportError: No module named 'lldb'

I am  not sure how this change is going to affect that - better or worse?


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D64881



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

[Lldb-commits] [PATCH] D64013: Correctly use GetLoadedModuleList to take advantage of libraries-svr4

2019-07-17 Thread António Afonso via Phabricator via lldb-commits

aadsm updated this revision to Diff 210422.
aadsm added a comment.

Missed one function


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D64013

Files:
  lldb/include/lldb/Target/Process.h
  lldb/source/Plugins/DynamicLoader/POSIX-DYLD/DYLDRendezvous.cpp
  lldb/source/Plugins/DynamicLoader/POSIX-DYLD/DYLDRendezvous.h
  lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
  lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.h

Index: lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.h
===
--- lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.h
+++ lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.h
@@ -200,9 +200,9 @@
 
   llvm::VersionTuple GetHostOSVersion() override;
 
-  size_t LoadModules(LoadedModuleInfoList &module_list) override;
+  llvm::Error LoadModules() override;
 
-  size_t LoadModules() override;
+  llvm::Expected GetLoadedModuleList() override;
 
   Status GetFileLoadAddress(const FileSpec &file, bool &is_loaded,
 lldb::addr_t &load_addr) override;
@@ -386,9 +386,6 @@
   // Query remote GDBServer for register information
   bool GetGDBServerRegisterInfo(ArchSpec &arch);
 
-  // Query remote GDBServer for a detailed loaded library list
-  Status GetLoadedModuleList(LoadedModuleInfoList &);
-
   lldb::ModuleSP LoadModuleAtAddress(const FileSpec &file,
  lldb::addr_t link_map,
  lldb::addr_t base_addr,
Index: lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
===
--- lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
+++ lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
@@ -2375,7 +2375,14 @@
 ostr.Printf("%" PRIu64 " %" PRIu32, wp_addr, wp_index);
 description = ostr.GetString();
   } else if (key.compare("library") == 0) {
-LoadModules();
+auto error = LoadModules();
+if (error) {
+  Log *log(
+  ProcessGDBRemoteLog::GetLogIfAllCategoriesSet(GDBR_LOG_PROCESS));
+  LLDB_LOG_ERROR(log, std::move(error),
+ "ProcessGDBRemote::{1} failed to load modules: {0}",
+ __FUNCTION__);
+}
   } else if (key.size() == 2 && ::isxdigit(key[0]) && ::isxdigit(key[1])) {
 uint32_t reg = UINT32_MAX;
 if (!key.getAsInteger(16, reg))
@@ -2728,9 +2735,15 @@
 
   // the loaded module list can also provides a link map address
   if (addr == LLDB_INVALID_ADDRESS) {
-LoadedModuleInfoList list;
-if (GetLoadedModuleList(list).Success())
-  addr = list.m_link_map;
+llvm::Expected list = GetLoadedModuleList();
+if (!list) {
+  Log *log(ProcessGDBRemoteLog::GetLogIfAllCategoriesSet(GDBR_LOG_PROCESS));
+  LLDB_LOG_ERROR(log, list.takeError(),
+ "ProcessGDBRemote::{1} failed to read module list: {0}",
+ __FUNCTION__);
+} else {
+  addr = list->m_link_map;
+}
   }
 
   return addr;
@@ -4648,28 +4661,29 @@
   return m_register_info.GetNumRegisters() > 0;
 }
 
-Status ProcessGDBRemote::GetLoadedModuleList(LoadedModuleInfoList &list) {
+llvm::Expected ProcessGDBRemote::GetLoadedModuleList() {
   // Make sure LLDB has an XML parser it can use first
   if (!XMLDocument::XMLEnabled())
-return Status(0, ErrorType::eErrorTypeGeneric);
+return llvm::createStringError(llvm::inconvertibleErrorCode(),
+   "XML parsing not available");
 
   Log *log = GetLogIfAnyCategoriesSet(LIBLLDB_LOG_PROCESS);
   if (log)
 log->Printf("ProcessGDBRemote::%s", __FUNCTION__);
 
+  LoadedModuleInfoList list;
   GDBRemoteCommunicationClient &comm = m_gdb_comm;
 
   // check that we have extended feature read support
   if (comm.GetQXferLibrariesSVR4ReadSupported()) {
-list.clear();
-
 // request the loaded library list
 std::string raw;
 lldb_private::Status lldberr;
 
 if (!comm.ReadExtFeature(ConstString("libraries-svr4"), ConstString(""),
  raw, lldberr))
-  return Status(0, ErrorType::eErrorTypeGeneric);
+  return llvm::createStringError(llvm::inconvertibleErrorCode(),
+ "Error in libraries-svr4 packet");
 
 // parse the xml file in memory
 if (log)
@@ -4677,11 +4691,14 @@
 XMLDocument doc;
 
 if (!doc.ParseMemory(raw.c_str(), raw.size(), "noname.xml"))
-  return Status(0, ErrorType::eErrorTypeGeneric);
+  return llvm::createStringError(llvm::inconvertibleErrorCode(),
+ "Error reading noname.xml");
 
 XMLNode root_element = doc.GetRootElement("library-list-svr4");
 if (!root_element)
-  return Status();
+  return llvm::createStringError(
+  llvm::inconve

[Lldb-commits] [PATCH] D64881: [Cmake] Use the modern way to find Python when possible

2019-07-17 Thread Jonas Devlieghere via Phabricator via lldb-commits

JDevlieghere added a comment.

In D64881#1590273 , @stella.stamenova 
wrote:

> Re: Windows CMake: I am not sure, I'd have to do look into it further.
>
> On a separate note: I haven't looked into it yet, but we have a setup to run 
> the LLDB tests on Ubuntu and that started failing somewhat recently with some 
> Swig and Python errors. For example:
>
>   Unable to load lldb extension module.  Possible reasons for this include:
> 1) LLDB was built with LLDB_DISABLE_PYTHON=1
> 2) PYTHONPATH and PYTHONHOME are not set correctly.  PYTHONHOME should 
> refer to
>the version of Python that LLDB built and linked against, and 
> PYTHONPATH
>should contain the Lib directory for the same python distro, as well 
> as the
>location of LLDB's site-packages folder.
> 3) A different version of Python than that which was built against is 
> exported in
>the system's PATH environment variable, causing conflicts.
> 4) The executable '/home/e2admin/vstsdrive/_work/29/b/bin/lldb' could not 
> be found.  Please check 
>that it exists and is executable.
>   Traceback (most recent call last):
> File "/home/e2admin/vstsdrive/_work/29/s/lldb/test/dotest.py", line 7, in 
> 
>   lldbsuite.test.run_suite()
> File 
> "/home/e2admin/vstsdrive/_work/29/s/lldb/packages/Python/lldbsuite/test/dotest.py",
>  line 1268, in run_suite
>   import lldb
>   ImportError: No module named 'lldb'
>
>
> I am  not sure how this change is going to affect that - better or worse?


Yes, this should solve (3). However, this should;ve already been caught at 
configure-time by my change in https://reviews.llvm.org/rL366243.


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D64881



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

[Lldb-commits] [lldb] r366378 - Add support to ProcessMachCore::DoLoadCore to handle an EFI UUID str.

2019-07-17 Thread Jason Molenda via lldb-commits

Author: jmolenda
Date: Wed Jul 17 14:44:05 2019
New Revision: 366378

URL: http://llvm.org/viewvc/llvm-project?rev=366378&view=rev
Log:
Add support to ProcessMachCore::DoLoadCore to handle an EFI UUID str.

If a core file has an EFI version string which includes a UUID
(similar to what it returns for the kdp KDP_KERNELVERSION packet)
in the LC_IDENT or LC_NOTE 'kern ver str' load command.  In that
case, we should try to find the binary and dSYM for the UUID
listed.  The dSYM may have python code which knows how to relocate
the binary to the correct address in lldb's target section load
list and loads other ancillary binaries.

The test case is a little involved,

1. it compiles an inferior hello world apple (a.out),
2. it compiles a program which can create a corefile manually
   with a specific binary's UUID encoded in it,
3. it gets the UUID of the a.out binary,
4. it creates a shell script, dsym-for-uuid.sh, which will
   return the full path to the a.out + a.out.dSYM when called
   with teh correct UUID,
5. it sets the LLDB_APPLE_DSYMFORUUID_EXECUTABLE env var before
   creating the lldb target, to point to this dsym-for-uuid.sh,
6. runs the create-corefile binary we compiled in step #2,
7. loads the corefile from step #6 into lldb,
8. verifies that lldb loaded a.out by reading the LC_NOTE
   load command from the corefile, calling dsym-for-uuid.sh with
   that UUID, got back the path to a.out and loaded it.

whew!




Added:
lldb/trunk/packages/Python/lldbsuite/test/macosx/lc-note/
lldb/trunk/packages/Python/lldbsuite/test/macosx/lc-note/kern-ver-str/

lldb/trunk/packages/Python/lldbsuite/test/macosx/lc-note/kern-ver-str/Makefile

lldb/trunk/packages/Python/lldbsuite/test/macosx/lc-note/kern-ver-str/TestKernVerStrLCNOTE.py

lldb/trunk/packages/Python/lldbsuite/test/macosx/lc-note/kern-ver-str/create-empty-corefile.cpp

lldb/trunk/packages/Python/lldbsuite/test/macosx/lc-note/kern-ver-str/create-empty-corefile.mk
lldb/trunk/packages/Python/lldbsuite/test/macosx/lc-note/kern-ver-str/main.c
Modified:
lldb/trunk/source/Plugins/Process/mach-core/ProcessMachCore.cpp

Added: 
lldb/trunk/packages/Python/lldbsuite/test/macosx/lc-note/kern-ver-str/Makefile
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/macosx/lc-note/kern-ver-str/Makefile?rev=366378&view=auto
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/macosx/lc-note/kern-ver-str/Makefile 
(added)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/macosx/lc-note/kern-ver-str/Makefile 
Wed Jul 17 14:44:05 2019
@@ -0,0 +1,15 @@
+LEVEL = ../../../make
+
+MAKE_DSYM := NO
+
+C_SOURCES := main.c
+
+all: a.out create-empty-corefile
+
+create-empty-corefile:
+   $(MAKE) VPATH=$(VPATH) -f $(SRCDIR)/create-empty-corefile.mk
+
+clean::
+   $(MAKE) -f create-empty-corefile.mk clean
+
+include $(LEVEL)/Makefile.rules

Added: 
lldb/trunk/packages/Python/lldbsuite/test/macosx/lc-note/kern-ver-str/TestKernVerStrLCNOTE.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/macosx/lc-note/kern-ver-str/TestKernVerStrLCNOTE.py?rev=366378&view=auto
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/macosx/lc-note/kern-ver-str/TestKernVerStrLCNOTE.py
 (added)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/macosx/lc-note/kern-ver-str/TestKernVerStrLCNOTE.py
 Wed Jul 17 14:44:05 2019
@@ -0,0 +1,102 @@
+"""Test that corefiles with an LC_NOTE "kern ver str" load command is used."""
+
+from __future__ import print_function
+
+
+import os
+import re
+import subprocess
+import sys
+
+import lldb
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+
+
+class TestKernVerStrLCNOTE(TestBase):
+
+mydir = TestBase.compute_mydir(__file__)
+
+@skipIf(debug_info=no_match(["dsym"]), bugnumber="This test is looking 
explicitly for a dSYM")
+@skipIfDarwinEmbedded
+@skipUnlessDarwin
+def test_lc_note(self):
+self.build()
+self.test_exe = self.getBuildArtifact("a.out")
+self.create_corefile = self.getBuildArtifact("create-empty-corefile")
+self.dsym_for_uuid = self.getBuildArtifact("dsym-for-uuid.sh")
+self.corefile = self.getBuildArtifact("core")
+
+## We can hook in our dsym-for-uuid shell script to lldb with this env
+## var instead of requiring a defaults write.
+os.environ['LLDB_APPLE_DSYMFORUUID_EXECUTABLE'] = self.dsym_for_uuid
+self.addTearDownHook(lambda: 
os.environ.pop('LLDB_APPLE_DSYMFORUUID_EXECUTABLE', None))
+
+dwarfdump_uuid_regex = re.compile(
+'UUID: ([-0-9a-fA-F]+) \(([^\(]+)\) .*')
+dwarfdump_cmd_output = subprocess.check_output(
+('/usr/bin/dwarfdump --uuid "%s"' % self.test_exe), 
shell=True).decode("utf-8")
+aout_uuid

[Lldb-commits] [PATCH] D64881: [Cmake] Use the modern way to find Python when possible

2019-07-17 Thread Adrian McCarthy via Phabricator via lldb-commits

amccarth added a comment.

In D64881#1590252 , @JDevlieghere 
wrote:

> In D64881#1590204 , @amccarth wrote:
>
> > An aside ...
> >
> > I'm still trying to get back to a buildable state the earlier changes, like 
> > the one that tries to enforce version consistency between the libs and the 
> > interpreter.  I'm currently bisecting to figure out what I hope is the 
> > final blocker.
>
>
> Maybe we should just revert D64443 ? This is 
> what broke my setup, and led me to introduce to the consistency check in the 
> first place, which merely diagnoses a real problem.


It wasn't a real problem on Windows, where we've been using Python 3.x for LLDB 
for a long time (predating the patch you propose rolling back).

> 
> 
>> For me, the find_package(PythonInterp) call was always finding the older 
>> interpreter (2.7) even though everything pointed to the newer one (3.6).  
>> That tripped the version compatibility check that was recently added.  The 
>> algorithm used by find_package isn't well documented (as far as I can tell), 
>> so I couldn't even tell you whether it was doing the wrong thing.  I can 
>> tell you that the version check seemed unnecessary, as lldb built and tested 
>> fine when I locally removed that check, despite the fact that the versions 
>> didn't match.
> 
> This is interesting, for me on macOS, it was the other way around. It would 
> always find the 3.7 interpreter because of the LLVM change and never find the 
> corresponding python libs for 3.7 in LLDB. I had to remove every trace of the 
> Python 3 interpreter, for it to only find the 2.7 one. Anyway, I think we all 
> agree (CMake developers included) that the old way of doing things is 
> inherently broken. That's why I want to start adopting the new FindPython.
> 
>> The only way I was able to make things work again was to completely remove 
>> Python 2.7 from my machine.  Oddly, the uninstaller also took make with it, 
>> so then I couldn't run lldb tests.  With make re-installed, I now have a 
>> some crashes during tests to the Python allocator being called without the 
>> GIL being held.  I'm currently bisecting to figure out which change caused 
>> that.  This crash is especially painful, as it leaves an invisible Python 
>> process running and holding files open, which breaks subsequent builds.
>> 
>> To your question ...
>> 
>> Without understanding how either version of find_package finds Python, it's 
>> hard to say whether it solves the problems outlined in Zach's comment at the 
>> top of find_python_libs.  Zach's first two points don't apply anymore, as 
>> we're well past MSVC 2015.  But the third one, regarding a 32-bit CMake 
>> being able to find a 64-bit Python, seems like it would still be a problem.
> 
> Thanks, I guess we'd just need to try it then.

Testing the matrix of 32/64, 64/32, Python 2/3, debug/release, seems like a lot 
of work.  I'd be pretty surprised to learn that CMake did extra, 
Windows-specific work necessary to make find_package do the right thing in the 
face of registry and/or filesystem redirection.


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D64881



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

[Lldb-commits] [lldb] r366381 - Ah, forgot a debug line I left in the dsym-for-uuid.sh script

2019-07-17 Thread Jason Molenda via lldb-commits

Author: jmolenda
Date: Wed Jul 17 14:55:39 2019
New Revision: 366381

URL: http://llvm.org/viewvc/llvm-project?rev=366381&view=rev
Log:
Ah, forgot a debug line I left in the dsym-for-uuid.sh script
to make sure it was correctly being disabled after this test
case completed.

Modified:

lldb/trunk/packages/Python/lldbsuite/test/macosx/lc-note/kern-ver-str/TestKernVerStrLCNOTE.py

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/macosx/lc-note/kern-ver-str/TestKernVerStrLCNOTE.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/macosx/lc-note/kern-ver-str/TestKernVerStrLCNOTE.py?rev=366381&r1=366380&r2=366381&view=diff
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/macosx/lc-note/kern-ver-str/TestKernVerStrLCNOTE.py
 (original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/macosx/lc-note/kern-ver-str/TestKernVerStrLCNOTE.py
 Wed Jul 17 14:55:39 2019
@@ -51,7 +51,6 @@ class TestKernVerStrLCNOTE(TestBase):
 'ret=0',
 'echo ""',
 'echo "http://www.apple.com/DTDs/PropertyList-1.0.dtd\\";>"',
-'date >> /tmp/log',
 'echo ""',
 '',
 '# the last arugment is probably the uuid',


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

[Lldb-commits] [PATCH] D64844: [Target] Remove Target::GetScratchClangASTContext

2019-07-17 Thread Jim Ingham via Phabricator via lldb-commits

jingham added a comment.

The nice thing about the way the ObjCLanguageRuntime::Get was that is was only 
useable where we decided it was legit to use it, in the actual 
ObjCLanguageRuntime plugin or its direct users.  If you want to keep the 
convenience cast function in a header in Plugins/ExpressionParser/Clang, that 
would be fine.


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

https://reviews.llvm.org/D64844



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

[Lldb-commits] [PATCH] D64853: Fix CommandInterpreter for _regex-break with options

2019-07-17 Thread Jason Molenda via Phabricator via lldb-commits

jasonmolenda added a comment.

I know there are a lot of specific notes floating around right now, but two 
quick suggestions.

I see the idiom

  self.runCmd("file " + exe, CURRENT_EXECUTABLE_SET)
  target = self.dbg.CreateTarget(exe)

repeated in several places.  They're doing the same thing, doing the second is 
preferred.

In all? of the test_ methods, you rebuild the test binary.  This can be in the 
setup method, can't it?

It looks like you've changed to creating your own dylib/solib to test module 
setting, instead of trying to use a libc function.  Good change, it will make 
this a lot more portable.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D64853



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

[Lldb-commits] [lldb] r366383 - [NFC] Clarify a Cmake status message regarding Python on LLDBConfig

2019-07-17 Thread Adrian McCarthy via lldb-commits

Author: amccarth
Date: Wed Jul 17 15:36:26 2019
New Revision: 366383

URL: http://llvm.org/viewvc/llvm-project?rev=366383&view=rev
Log:
[NFC] Clarify a Cmake status message regarding Python on LLDBConfig

Modified:
lldb/trunk/cmake/modules/LLDBConfig.cmake

Modified: lldb/trunk/cmake/modules/LLDBConfig.cmake
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/cmake/modules/LLDBConfig.cmake?rev=366383&r1=366382&r2=366383&view=diff
==
--- lldb/trunk/cmake/modules/LLDBConfig.cmake (original)
+++ lldb/trunk/cmake/modules/LLDBConfig.cmake Wed Jul 17 15:36:26 2019
@@ -137,7 +137,7 @@ function(find_python_libs_windows)
  REGEX "^#define[ \t]+PY_VERSION[ \t]+\"[^\"]+\"")
 string(REGEX REPLACE "^#define[ \t]+PY_VERSION[ \t]+\"([^\"+]+)[+]?\".*" 
"\\1"
  PYTHONLIBS_VERSION_STRING "${python_version_str}")
-message(STATUS "Found Python version ${PYTHONLIBS_VERSION_STRING}")
+message(STATUS "Found Python library version ${PYTHONLIBS_VERSION_STRING}")
 string(REGEX REPLACE "([0-9]+)[.]([0-9]+)[.][0-9]+" "python\\1\\2" 
PYTHONLIBS_BASE_NAME "${PYTHONLIBS_VERSION_STRING}")
 set(PYTHONLIBS_VERSION_STRING "${PYTHONLIBS_VERSION_STRING}" PARENT_SCOPE)
 unset(python_version_str)


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

[Lldb-commits] [PATCH] D64806: [CMake] Always build debugserver on Darwin and allow tests to use the system's one

2019-07-17 Thread Stefan Gränitz via Phabricator via lldb-commits

sgraenitz updated this revision to Diff 210448.
sgraenitz marked 9 inline comments as done.
sgraenitz added a comment.

Address Saleem's feedback


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D64806

Files:
  lldb/CMakeLists.txt
  lldb/cmake/modules/AddLLDB.cmake
  lldb/cmake/modules/LLDBConfig.cmake
  lldb/test/CMakeLists.txt
  lldb/tools/debugserver/source/CMakeLists.txt
  lldb/unittests/CMakeLists.txt
  lldb/unittests/tools/lldb-server/CMakeLists.txt

Index: lldb/unittests/tools/lldb-server/CMakeLists.txt
===
--- lldb/unittests/tools/lldb-server/CMakeLists.txt
+++ lldb/unittests/tools/lldb-server/CMakeLists.txt
@@ -13,8 +13,13 @@
 add_lldb_test_executable(thread_inferior inferior/thread_inferior.cpp)
 add_lldb_test_executable(environment_check inferior/environment_check.cpp)
 
-if(DEBUGSERVER_PATH)
-  add_definitions(-DLLDB_SERVER="${DEBUGSERVER_PATH}" -DLLDB_SERVER_IS_DEBUGSERVER=1)
+if(LLDB_CAN_USE_DEBUGSERVER)
+  if(LLDB_USE_SYSTEM_DEBUGSERVER)
+lldb_find_system_debugserver(debugserver_path)
+  else()
+set(debugserver_path $)
+  endif()
+  add_definitions(-DLLDB_SERVER="${debugserver_path}" -DLLDB_SERVER_IS_DEBUGSERVER=1)
 else()
   add_definitions(-DLLDB_SERVER="$" -DLLDB_SERVER_IS_DEBUGSERVER=0)
 endif()
Index: lldb/unittests/CMakeLists.txt
===
--- lldb/unittests/CMakeLists.txt
+++ lldb/unittests/CMakeLists.txt
@@ -78,6 +78,6 @@
 add_subdirectory(UnwindAssembly)
 add_subdirectory(Utility)
 
-if(LLDB_CAN_USE_DEBUGSERVER AND NOT SKIP_TEST_DEBUGSERVER)
+if(LLDB_CAN_USE_DEBUGSERVER AND NOT LLDB_USE_SYSTEM_DEBUGSERVER)
   add_subdirectory(debugserver)
 endif()
Index: lldb/tools/debugserver/source/CMakeLists.txt
===
--- lldb/tools/debugserver/source/CMakeLists.txt
+++ lldb/tools/debugserver/source/CMakeLists.txt
@@ -6,6 +6,58 @@
 
 include_directories(MacOSX)
 
+function(check_certificate identity result_valid)
+  execute_process(
+COMMAND security find-certificate -Z -p -c ${identity} /Library/Keychains/System.keychain
+RESULT_VARIABLE exit_code OUTPUT_QUIET ERROR_QUIET)
+  if(exit_code)
+set(${result_valid} FALSE PARENT_SCOPE)
+  else()
+set(${result_valid} TRUE PARENT_SCOPE)
+  endif()
+endfunction()
+
+function(get_debugserver_codesign_identity result)
+  string(CONCAT not_found_help
+"This will cause failures in the test suite."
+"Pass '-DLLDB_USE_SYSTEM_DEBUGSERVER=ON' to use the system one instead."
+"See 'Code Signing on macOS' in the documentation."
+  )
+
+  # Explicit override: warn if unavailable
+  if(LLDB_CODESIGN_IDENTITY)
+set(${result} ${LLDB_CODESIGN_IDENTITY} PARENT_SCOPE)
+check_certificate(${LLDB_CODESIGN_IDENTITY} available)
+if(NOT available AND NOT LLDB_USE_SYSTEM_DEBUGSERVER)
+  message(WARNING "LLDB_CODESIGN_IDENTITY not found: '${LLDB_CODESIGN_IDENTITY}' ${not_found_help}")
+endif()
+return()
+  endif()
+
+  # Development signing identity: use if available
+  check_certificate(lldb_codesign available)
+  if(available)
+set(${result} lldb_codesign PARENT_SCOPE)
+return()
+  endif()
+
+  if(NOT LLDB_USE_SYSTEM_DEBUGSERVER)
+message(WARNING "Development code sign identiy not found: 'lldb_codesign' ${not_found_help}")
+  endif()
+
+  # LLVM pendant: fallback if available
+  if(LLVM_CODESIGNING_IDENTITY)
+check_certificate(${LLVM_CODESIGNING_IDENTITY} available)
+if(available)
+  set(${result} ${LLVM_CODESIGNING_IDENTITY} PARENT_SCOPE)
+  return()
+endif()
+  endif()
+
+  # Ad-hoc signing: last resort
+  set(${result} "-" PARENT_SCOPE)
+endfunction()
+
 set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -stdlib=libc++ -Wl,-sectcreate,__TEXT,__info_plist,${CMAKE_CURRENT_SOURCE_DIR}/../resources/lldb-debugserver-Info.plist")
 
 check_cxx_compiler_flag("-Wno-gnu-zero-variadic-macro-arguments"
@@ -30,132 +82,17 @@
 
 add_subdirectory(MacOSX)
 
-# LLDB-specific identity, currently used for code signing debugserver.
 set(LLDB_CODESIGN_IDENTITY "" CACHE STRING
-"Override code sign identity for debugserver and for use in tests; falls back to LLVM_CODESIGNING_IDENTITY if set or lldb_codesign otherwise (Darwin only)")
-
-# Determine which identity to use and store it in the separate cache entry.
-# We will query it later for LLDB_TEST_COMMON_ARGS.
-if(LLDB_CODESIGN_IDENTITY)
-  set(LLDB_CODESIGN_IDENTITY_USED ${LLDB_CODESIGN_IDENTITY} CACHE INTERNAL "" FORCE)
-elseif(LLVM_CODESIGNING_IDENTITY)
-  set(LLDB_CODESIGN_IDENTITY_USED ${LLVM_CODESIGNING_IDENTITY} CACHE INTERNAL "" FORCE)
-else()
-  set(LLDB_CODESIGN_IDENTITY_USED lldb_codesign CACHE INTERNAL "" FORCE)
-endif()
+"Identity override for debugserver; see 'Code Signing on macOS' in the documentation (Darwin only)")
 
-# Override locally, so the identity is used fo

[Lldb-commits] [PATCH] D62183: [Windows] Fix race condition between state changes

2019-07-17 Thread Martin Andersson via Phabricator via lldb-commits

martin added a comment.

In D62183#1589937 , @amccarth wrote:

> This change looks fine to me, but I wish there was a reliable way to test it. 
>  Is it a true race condition (e.g., because the unpredictability of thread 
> scheduling), or is there a way to write a test that would always fail without 
> this fix?

My understanding is that this is a race between the call to 
SetPrivateState(eStateRunning) in DoResume and the call to 
SetPrivateState(eStateStopped) in OnDebugException (on line 694). The former is 
supposed to take place before the latter and it often is, but when the latter 
is run first it leads the debugger to wait indefinitely. Because the second 
state change is ignored because the process is already in the stopped state.

I found this issue when I was using Visual Studio Code with the lldb-vscode 
debug adapter. Sometimes when I single stepped I would hit this issue. I could 
reliably trigger it by holding down F10  (step) 
in Visual Studio Code, it would only take a couple of seconds of rapid single 
stepping (roughly between 10 steps and 100 steps) before I hit it. However, I 
cannot trigger it with any code. For example, a simple while loop with an 
integer increment does not trigger it. But if I replace the integer increment 
with a function call I can trigger it within a couple of seconds. However, I am 
not familiar enough with LLDB to know if it would be possible to write a test 
that would reliably trigger it. My hunch is that it would be difficult.

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

https://reviews.llvm.org/D62183

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

[Lldb-commits] [PATCH] D64806: [CMake] Always build debugserver on Darwin and allow tests to use the system's one

2019-07-17 Thread Stefan Gränitz via Phabricator via lldb-commits

sgraenitz added a comment.

Thanks for taking a look.




Comment at: lldb/cmake/modules/AddLLDB.cmake:292
+  else()
+string(STRIP ${xcode_dev_dir} xcode_dev_dir)
+set(subdir "LLDB.framework/Resources/debugserver")

compnerd wrote:
> Can you add a comment explaining that you want to strip leading whitespace?  
> Alternatively, if its trailing whitespace, please use 
> `OUTPUT_STRIP_TRAILING_WHITESPACE` in the `execute_process` on L288 please.
It's been there before and I think it may strip a trailing newline. Went with 
the `execute_process` variant.



Comment at: lldb/unittests/CMakeLists.txt:83
   add_subdirectory(debugserver)
 endif()

compnerd wrote:
> Shouldn't debugserver not be available always?  It doesn't matter if it isn't 
> being used.  Furthermore, elision from the distribution targets will also 
> prevent the unnecessary build so there is no need to worry about the default 
> builds being longer than necessary.
> Shouldn't debugserver not be available always?
This is the directory for debugserver unittests.



Comment at: lldb/unittests/tools/lldb-server/CMakeLists.txt:16
 
-if(DEBUGSERVER_PATH)
-  add_definitions(-DLLDB_SERVER="${DEBUGSERVER_PATH}" 
-DLLDB_SERVER_IS_DEBUGSERVER=1)
+if(LLDB_CAN_USE_DEBUGSERVER)
+  if(LLDB_USE_SYSTEM_DEBUGSERVER)

compnerd wrote:
> Why is this being checked in `lldb-server`?
It sets `LLDB_SERVER_IS_DEBUGSERVER`


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D64806



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

[Lldb-commits] [PATCH] D64806: [CMake] Always build debugserver on Darwin and allow tests to use the system's one

2019-07-17 Thread Stefan Gränitz via Phabricator via lldb-commits

sgraenitz added a comment.

I did some more testing and from my point of view this seems to work. If it 
looks acceptable to you, I would like to land it tomorrow (CEST) before the 9.0 
branch cut.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D64806



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

[Lldb-commits] [PATCH] D64897: Move start-address finding to Target, implement fallback if main executable does not have a start address

2019-07-17 Thread Jason Molenda via Phabricator via lldb-commits

jasonmolenda created this revision.
jasonmolenda added a reviewer: jingham.
Herald added a subscriber: abidh.
Herald added a project: LLDB.

On the upcoming version of macOS, 10.15 or Catalina, there are userlang kernel 
drivers ("DriverKit" processes) and one unique thing about a DriverKit main 
binary is that it has no start address load command in the same way that a 
normal user process binary has.  lldb uses the entry address ("main") as a 
function address that is never called during the normal execution of the 
program, after the process has started, for doing inferior function calls.  It 
creates a fake stack frame with "main" as the return address, puts a breakpoint 
on main, and uses that breakpoint hit to indicate that the function call 
completed successfully.  Because DriverKit processes don't have a traditional 
main, lldb can't do inferior function calls.

Currently this is found in ThreadPlanCallFunction::ConstructorSetup - it finds 
the Target's main executable, asks for its entry address.  This patch moves 
that code into a new Target::GetEntryPointAddress method which tries the main 
executable, but if that executable fails, steps through every other Module 
asking if there is an entry address for that module.  The patch also changes 
ObjectFileMachO to look for the function _dyld_start in the dyld binary -- 
another function that is never called -- and uses that as a backup entry 
address function.

Testing this is a bit difficult - these DriverKit userland drivers are not 
launched like normal processes, we can't run a test DriverKit from the 
testsuite under lldb.  I'm still thinking about this; to test this by hand I 
#if 0'ed out ObjectFileMachO's normal entry address logic (looking at LC_MAIN 
load command etc) so it had to fall back to the _dyld_start one.


Repository:
  rLLDB LLDB

https://reviews.llvm.org/D64897

Files:
  include/lldb/Target/Target.h
  source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
  source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.h
  source/Target/Target.cpp
  source/Target/ThreadPlanCallFunction.cpp

Index: source/Target/ThreadPlanCallFunction.cpp
===
--- source/Target/ThreadPlanCallFunction.cpp
+++ source/Target/ThreadPlanCallFunction.cpp
@@ -65,38 +65,17 @@
 return false;
   }
 
-  Module *exe_module = GetTarget().GetExecutableModulePointer();
+  m_start_addr = GetTarget().GetEntryPointAddress(error);
 
-  if (exe_module == nullptr) {
-m_constructor_errors.Printf(
-"Can't execute code without an executable module.");
-if (log)
-  log->Printf("ThreadPlanCallFunction(%p): %s.", static_cast(this),
-  m_constructor_errors.GetData());
+  if (log && error.Fail()) {
+m_constructor_errors.Printf("%s", error.AsCString());
+log->Printf("ThreadPlanCallFunction(%p): %s.", static_cast(this),
+ m_constructor_errors.GetData());
 return false;
-  } else {
-ObjectFile *objectFile = exe_module->GetObjectFile();
-if (!objectFile) {
-  m_constructor_errors.Printf(
-  "Could not find object file for module \"%s\".",
-  exe_module->GetFileSpec().GetFilename().AsCString());
+  }
 
-  if (log)
-log->Printf("ThreadPlanCallFunction(%p): %s.",
-static_cast(this), m_constructor_errors.GetData());
-  return false;
-}
-
-m_start_addr = objectFile->GetEntryPointAddress();
-if (!m_start_addr.IsValid()) {
-  m_constructor_errors.Printf(
-  "Could not find entry point address for executable module \"%s\".",
-  exe_module->GetFileSpec().GetFilename().AsCString());
-  if (log)
-log->Printf("ThreadPlanCallFunction(%p): %s.",
-static_cast(this), m_constructor_errors.GetData());
-  return false;
-}
+  if (!m_start_addr.IsValid()) {
+return false;
   }
 
   start_load_addr = m_start_addr.GetLoadAddress(&GetTarget());
Index: source/Target/Target.cpp
===
--- source/Target/Target.cpp
+++ source/Target/Target.cpp
@@ -2448,6 +2448,44 @@
   return address;
 }
 
+lldb_private::Address Target::GetEntryPointAddress(Status &err) {
+  err.Clear();
+  Address entry_addr;
+  Module *exe_module = GetExecutableModulePointer();
+
+  if (!exe_module || !exe_module->GetObjectFile()) {
+err.SetErrorStringWithFormat("No primary executable found");
+  } else {
+entry_addr = exe_module->GetObjectFile()->GetEntryPointAddress();
+if (!entry_addr.IsValid()) {
+  err.SetErrorStringWithFormat(
+ "Could not find entry point address for executable module \"%s\".",
+ exe_module->GetFileSpec().GetFilename().AsCString());
+}
+  }
+
+  if (!entry_addr.IsValid()) {
+const ModuleList &modules = GetImages();
+const size_t num_images = modules.GetSize();
+for (size_t idx = 0; idx < num_images; ++idx) {
+  ModuleSP module_sp(modules.GetModuleAtIn

[Lldb-commits] [PATCH] D64897: Move start-address finding to Target, implement fallback if main executable does not have a start address

2019-07-17 Thread Jim Ingham via Phabricator via lldb-commits

jingham added a comment.

I wonder if we ought to allow target properties (target as an example) that are 
only for testing, so they don't print when you do settings list, etc.  But the 
we could have some settings like a "target.testing.dont-read-LC_MAIN" and that 
would make it easy to automate your hand testing.  Kind of like the 
"experimental" decorator, except you have to know they exist to use them...


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D64897



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

[Lldb-commits] [PATCH] D64853: Fix CommandInterpreter for _regex-break with options

2019-07-17 Thread Jim Ingham via Phabricator via lldb-commits

jingham added a comment.

This looks good in general.  I also have a few nits, and you need to fix (and 
probably test) the behavior for files with spaces in their names.

Comment at: 
lldb/packages/Python/lldbsuite/test/functionalities/breakpoint/breakpoint_command/regex_break/TestRegexpBreakCommand.py:81
+def regexp_break_command_line(self):
+"""Test the super consie "b" command with a line number, which is 
analias for _regexp-break."""
+exe = self.getBuildArtifact("a.out")

consie -> concise?  and "an alias"

Also the grammar is a little awkward, it makes it sound like a line number is 
an alias for _regexp-break.

Comment at: 
lldb/packages/Python/lldbsuite/test/functionalities/breakpoint/breakpoint_command/regex_break/TestRegexpBreakCommand.py:95-101
+self.runCmd("run", RUN_SUCCEEDED)
+
+# The stop reason of the thread should be breakpoint.
+self.expect("thread list", STOPPED_DUE_TO_BREAKPOINT,
+substrs=['stopped',
+ 'stop reason = breakpoint'])
+

This doesn't actually check that you stopped at the breakpoint you set.  There 
shouldn't be any other breakpoints, but you never know...  Might be better to 
get the breakpoint from the breakpoint  (key "bpno")in the break_results and 
use lldbutils.run_to_breakpoint_do_run which will do the run and assert that 
you stopped at the correct breakpoint in one go.

Comment at: 
lldb/packages/Python/lldbsuite/test/functionalities/breakpoint/breakpoint_command/regex_break/TestRegexpBreakCommand.py:107
+
+break_results = lldbutil.run_break_set_command(
+self, "b %s:%d" % (self.source, self.line))

JDevlieghere wrote:
> `# Check breakpoint with relative file path.`
Might also check a file name with a - in it, the first character is the 
trickiest - to make sure that doesn't get counted as an option.

Comment at: 
lldb/packages/Python/lldbsuite/test/functionalities/breakpoint/breakpoint_command/regex_break/TestRegexpBreakCommand.py:130
+# The stop reason of the thread should be breakpoint.
+self.expect("thread list", STOPPED_DUE_TO_BREAKPOINT,
+substrs=['stopped',

JDevlieghere wrote:
> Since this is repeated in every function, I'd factor this out into a method. 
Yes, you can just use lldbutils.run_to_breakpoint_do_run.  You could even add a 
version that takes a breakpoint number rather than an SBBreakpoint.

Comment at: lldb/source/Interpreter/CommandInterpreter.cpp:519
   const char *break_regexes[][2] = {
-  {"^(.*[^[:space:]])[[:space:]]*:[[:space:]]*([[:digit:]]+)[[:space:]]*$",
-   "breakpoint set --file '%1' --line %2"},
-  {"^/([^/]+)/$", "breakpoint set --source-pattern-regexp '%1'"},
-  {"^([[:digit:]]+)[[:space:]]*$", "breakpoint set --line %1"},
-  {"^\\*?(0x[[:xdigit:]]+)[[:space:]]*$", "breakpoint set --address %1"},
-  {"^[\"']?([-+]?\\[.*\\])[\"']?[[:space:]]*$",
-   "breakpoint set --name '%1'"},
+  
{"^([^[:space:]]+)[[:space:]]*:[[:space:]]*([[:digit:]]+)(?:$|\\s+)(-.*)*$",
+   "breakpoint set --file '%1' --line %2 %3"},

I think this one will have broken filenames with spaces in the name.  IIUC, 
that's what the initial ".*" was from ^(.*.  It is basically saying 

^(string that ends in a non-space character) some spaces ':' more spaces 
(number)

and you changed that to 

^(bunch of non-space characters) some spaces ':' more spaces (number)

Probably should add a test for files with spaces in the name.

Also, when you are gathering up the options you have:

(-.*)*$

Seems like that should be:

(-.*)?$

since if this starts with a - the .* will eat up the rest of the line, and you 
only want to account for the fact that the options might not be there.

Also it is a little odd that you use \\s whereas the rest of the patterns use 
[[:space:]].  We should probably use the posix one everywhere.

Comment at: lldb/source/Interpreter/CommandInterpreter.cpp:524
+  {"^(0x[[:xdigit:]]+)(?:$|\\s+)(-.*)*$", "breakpoint set --address %1 
%2"},
+  
{"^[\"']?([-+]?\\[[^[:space:]\"']+\\s+[^[:space:]\"']+\\])[\"']?(?:$|\\s+)(-.*)*$",
+   "breakpoint set --name '%1' %2"}, // Objective-C Identifier

again, stick with one of \s or [:space:]...

Greg's original version would support:

b -[NSObject foo: bar: baz:]

whereas yours will only support:

b -[NSObject foo:bar:baz:]

people tend to write selectors jammed together like this, so it isn't a big 
deal.

Comment at: lldb/source/Interpreter/CommandInterpreter.cpp:540
+  "Set a breakpoint using one of several shorthand formats. "
+  "Accepts breakpoint options.",
   "\n"

You should say:

Accepts breakpoint options AFTER the breakpoint specification.

After all:

[Lldb-commits] [PATCH] D64897: Move start-address finding to Target, implement fallback if main executable does not have a start address

2019-07-17 Thread Jason Molenda via Phabricator via lldb-commits

jasonmolenda added a comment.

Hm, that could be really helpful!  I think I'd like to do that as a separate 
piece of work a little bit later, but I'll look at that.


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D64897



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

[Lldb-commits] [PATCH] D64881: [Cmake] Use the modern way to find Python when possible

2019-07-17 Thread Michał Górny via Phabricator via lldb-commits

mgorny added a comment.

That said, I ended up having mixed feelings about this.

On the plus side, it definitely forces matching Python version for me. For 
example, without this patch changing `PYTHON_EXECUTABLE` resulted in mismatch. 
If I wanted to change Python version, I had to either update all vars manually 
or remove them from cache.

On the minus side, I can't seem to find a way to force a particular 
interpreter. Overriding `Python_EXECUTABLE` just doesn't work, and it always 
forces 3.7 for me. The logic is rather complex, and I'm not sure if it's 
possible at all. Maybe we should wait for the code to mature a bit.


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D64881



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

[Lldb-commits] [PATCH] D64881: [Cmake] Use the modern way to find Python when possible

2019-07-17 Thread Michał Górny via Phabricator via lldb-commits

mgorny added a comment.

In D64881#1590330 , @amccarth wrote:

> Testing the matrix of 32/64, 64/32, Python 2/3, debug/release, seems like a 
> lot of work.  I'd be pretty surprised to learn that CMake did extra, 
> Windows-specific work necessary to make find_package do the right thing in 
> the face of registry and/or filesystem redirection.


Well, apparently it has *some* support for registry (see: 
`Python_FIND_REGISTRY`).


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D64881



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

[Lldb-commits] [PATCH] D64881: [Cmake] Use the modern way to find Python when possible

2019-07-17 Thread Michał Górny via Phabricator via lldb-commits

mgorny added a comment.

Filed https://gitlab.kitware.com/cmake/cmake/issues/19492 for that.


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D64881



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

90 matches

Mail list logo