[Lldb-commits] [PATCH] D65646: [lldb] Print better diagnostics for user expressions and modules

2019-09-17 Thread Raphael Isemann via Phabricator via lldb-commits 
teemperor updated this revision to Diff 220439.
teemperor retitled this revision from "[lldb] Print better diagnostics for user 
expressions." to "[lldb] Print better diagnostics for user expressions and 
modules".
teemperor added a comment.
Herald added a subscriber: usaxena95.

- Rebased test.
- Also testing Objective-C modules now (as the ClangModulesDeclVendor provides 
valid SourceLocations, so this patch also improves diagnostics from modules).


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

https://reviews.llvm.org/D65646

Files:
  clang/include/clang/Basic/DiagnosticOptions.def
  clang/lib/Frontend/TextDiagnostic.cpp
  lldb/packages/Python/lldbsuite/test/commands/expression/diagnostics/Makefile
  
lldb/packages/Python/lldbsuite/test/commands/expression/diagnostics/TestExprDiagnostics.py
  lldb/packages/Python/lldbsuite/test/commands/expression/diagnostics/main.cpp
  lldb/packages/Python/lldbsuite/test/lang/objc/foundation/TestObjCMethods.py
  lldb/source/Plugins/ExpressionParser/Clang/ClangDiagnostic.h
  lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
  lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.h
  lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionSourceCode.cpp
  lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionSourceCode.h
  lldb/source/Plugins/ExpressionParser/Clang/ClangPersistentVariables.h
  lldb/source/Plugins/ExpressionParser/Clang/ClangUserExpression.cpp
  lldb/source/Plugins/ExpressionParser/Clang/ClangUserExpression.h

Index: lldb/source/Plugins/ExpressionParser/Clang/ClangUserExpression.h
===
--- lldb/source/Plugins/ExpressionParser/Clang/ClangUserExpression.h
+++ lldb/source/Plugins/ExpressionParser/Clang/ClangUserExpression.h
@@ -15,6 +15,7 @@
 #include "ASTStructExtractor.h"
 #include "ClangExpressionDeclMap.h"
 #include "ClangExpressionHelper.h"
+#include "ClangExpressionSourceCode.h"
 #include "ClangExpressionVariable.h"
 #include "IRForTarget.h"
 
@@ -216,6 +217,10 @@
   /// were not able to calculate this position.
   llvm::Optional m_user_expression_start_pos;
   ResultDelegate m_result_delegate;
+  ClangPersistentVariables *m_clang_state;
+  std::unique_ptr m_source_code;
+  /// File name used for the expression.
+  std::string m_filename;
 
   /// The object (if any) in which context the expression is evaluated.
   /// See the comment to `UserExpression::Evaluate` for details.
Index: lldb/source/Plugins/ExpressionParser/Clang/ClangUserExpression.cpp
===
--- lldb/source/Plugins/ExpressionParser/Clang/ClangUserExpression.cpp
+++ lldb/source/Plugins/ExpressionParser/Clang/ClangUserExpression.cpp
@@ -23,7 +23,6 @@
 #include "ClangDiagnostic.h"
 #include "ClangExpressionDeclMap.h"
 #include "ClangExpressionParser.h"
-#include "ClangExpressionSourceCode.h"
 #include "ClangModulesDeclVendor.h"
 #include "ClangPersistentVariables.h"
 
@@ -332,6 +331,7 @@
 if (PersistentExpressionState *persistent_state =
 target->GetPersistentExpressionStateForLanguage(
 lldb::eLanguageTypeC)) {
+  m_clang_state = llvm::cast(persistent_state);
   m_result_delegate.RegisterPersistentState(persistent_state);
 } else {
   diagnostic_manager.PutString(
@@ -396,18 +396,18 @@
 DiagnosticManager &diagnostic_manager, ExecutionContext &exe_ctx,
 std::vector modules_to_import, bool for_completion) {
 
+  m_filename = m_clang_state->GetNextExprFileName();
   std::string prefix = m_expr_prefix;
 
   if (m_options.GetExecutionPolicy() == eExecutionPolicyTopLevel) {
 m_transformed_text = m_expr_text;
   } else {
-std::unique_ptr source_code(
-ClangExpressionSourceCode::CreateWrapped(prefix.c_str(),
- m_expr_text.c_str()));
+m_source_code.reset(ClangExpressionSourceCode::CreateWrapped(
+m_filename, prefix.c_str(), m_expr_text.c_str()));
 
-if (!source_code->GetText(m_transformed_text, m_expr_lang,
-  m_in_static_method, exe_ctx, !m_ctx_obj,
-  for_completion, modules_to_import)) {
+if (!m_source_code->GetText(m_transformed_text, m_expr_lang,
+m_in_static_method, exe_ctx, !m_ctx_obj,
+for_completion, modules_to_import)) {
   diagnostic_manager.PutString(eDiagnosticSeverityError,
"couldn't construct expression body");
   return;
@@ -417,7 +417,7 @@
 // transformed code. We need this later for the code completion.
 std::size_t original_start;
 std::size_t original_end;
-bool found_bounds = source_code->GetOriginalBodyBounds(
+bool found_bounds = m_source_code->GetOriginalBodyBounds(
 m_transformed_text, m_expr_lang, original_start, original_end);
 if (found_bounds)
   m_user_expre

[Lldb-commits] [lldb] r372077 - Reland "[lldb][NFC] Make ApplyObjcCastHack less scary"

2019-09-17 Thread Raphael Isemann via lldb-commits 
Author: teemperor
Date: Tue Sep 17 00:58:01 2019
New Revision: 372077

URL: http://llvm.org/viewvc/llvm-project?rev=372077&view=rev
Log:
Reland "[lldb][NFC] Make ApplyObjcCastHack less scary"

First version had a typo.

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

Modified: 
lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangUserExpression.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangUserExpression.cpp?rev=372077&r1=372076&r2=372077&view=diff
==
--- lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangUserExpression.cpp 
(original)
+++ lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangUserExpression.cpp 
Tue Sep 17 00:58:01 2019
@@ -313,17 +313,13 @@ void ClangUserExpression::ScanContext(Ex
 // count is not available, [myArray count] returns id, which can't be directly
 // cast to int without causing a clang error.
 static void ApplyObjcCastHack(std::string &expr) {
-#define OBJC_CAST_HACK_FROM "(int)["
-#define OBJC_CAST_HACK_TO "(int)(long long)["
+  const std::string from = "(int)[";
+  const std::string to = "(int)(long long)[";
 
-  size_t from_offset;
+  size_t offset;
 
-  while ((from_offset = expr.find(OBJC_CAST_HACK_FROM)) != expr.npos)
-expr.replace(from_offset, sizeof(OBJC_CAST_HACK_FROM) - 1,
- OBJC_CAST_HACK_TO);
-
-#undef OBJC_CAST_HACK_TO
-#undef OBJC_CAST_HACK_FROM
+  while ((offset = expr.find(from)) != expr.npos)
+expr.replace(offset, from.size(), to);
 }
 
 bool ClangUserExpression::SetupPersistentState(DiagnosticManager 
&diagnostic_manager,


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

[Lldb-commits] [PATCH] D67390: [LLDB][ELF] Load both, .symtab and .dynsym sections

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

@clayborg thank you for this explanation. My patch for minidebuginfo is already 
done in D66791  . But this one here I was 
asked to pull out as a separate patch. For good reasons as we see. I wonder how 
this extra parameter `SymbolMapType` of yours does help. In the end I have to 
identify duplicates. But if no symbol with the same **name** should be added 
then why do I care about where the symbol is coming from?

Please help me understand of follow my thoughts here:

When I'm in the `(lldb)` console and type `b foo` I expect LLDB to set a 
breakpoint on the **function** foo, right? The type of the symbol `foo` is 
deduced as **function**. I ask this question because `Symtab` has no function 
to just search for a symbol by name; instead you always have to pass an 
address, a type or an ID:

  Symbol *FindSymbolByID(lldb::user_id_t uid) const;
  Symbol *FindSymbolWithType(lldb::SymbolType symbol_type,
  size_t FindAllSymbolsWithNameAndType(ConstString name,
  size_t FindAllSymbolsWithNameAndType(ConstString name,
  size_t FindAllSymbolsMatchingRexExAndType(
  Symbol *FindFirstSymbolWithNameAndType(ConstString name,
  Symbol *FindSymbolAtFileAddress(lldb::addr_t file_addr);
  Symbol *FindSymbolContainingFileAddress(lldb::addr_t file_addr);
  size_t FindFunctionSymbols(ConstString name, uint32_t name_type_mask,

So my point of this whole question is: What makes a symbol unique in the sense 
that it shouldn't be added to the symtab if it is already there?

Shouldn't the type of the symbol together with it's name define uniqueness? We 
shouldn't care about where the symbol is coming from nor if it is located at a 
different address. Well, if there's an overloaded function `foo(int)` and 
`foo(char*)` then both symbols are of type **function** and they both share the 
same **name**. When you type `b foo` you DO want 2 breakpoints to be set. 
Hence, niqueness cannot be defined over the name and the type . But wait, the 
**name** is mangled, so it IS unique enough unless I use 
`Symbol::GetNameNoArguments()`; there only the name is returned.

Here's my naive approach to test the admittedly very weird thought process from 
above: 
https://github.com/kwk/llvm-project/commit/5da4559a00c73ebefd8f8199890bd1991c94fa3f


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67390



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

[Lldb-commits] [lldb] r372090 - [lldb] [Process/gdb-remote] Fix defaulting signal to invalid in action list

2019-09-17 Thread Michal Gorny via lldb-commits 
Author: mgorny
Date: Tue Sep 17 02:31:00 2019
New Revision: 372090

URL: http://llvm.org/viewvc/llvm-project?rev=372090&view=rev
Log:
[lldb] [Process/gdb-remote] Fix defaulting signal to invalid in action list

Fix processing of "C" packet with signal for the whole process to
default signal value for action list to LLDB_INVALID_SIGNAL_NUMBER
rather than 0.

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

Modified:

lldb/trunk/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp

Modified: 
lldb/trunk/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp?rev=372090&r1=372089&r2=372090&view=diff
==
--- 
lldb/trunk/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
 (original)
+++ 
lldb/trunk/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
 Tue Sep 17 02:31:00 2019
@@ -1383,7 +1383,8 @@ GDBRemoteCommunicationServerLLGS::Handle
   packet, "unexpected content after $C{signal-number}");
   }
 
-  ResumeActionList resume_actions(StateType::eStateRunning, 0);
+  ResumeActionList resume_actions(StateType::eStateRunning,
+  LLDB_INVALID_SIGNAL_NUMBER);
   Status error;
 
   // We have two branches: what to do if a continue thread is specified (in
@@ -3322,4 +3323,4 @@ std::string GDBRemoteCommunicationServer
 }
   }
   return result;
-}
\ No newline at end of file
+}


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

[Lldb-commits] [PATCH] D67625: [lldb] [Process/gdb-remote] Fix defaulting signal to invalid in action list

2019-09-17 Thread Michał Górny via Phabricator via lldb-commits 
This revision was automatically updated to reflect the committed changes.
Closed by commit rL372090: [lldb] [Process/gdb-remote] Fix defaulting signal to 
invalid in action list (authored by mgorny, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D67625?vs=220349&id=220457#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D67625

Files:
  
lldb/trunk/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp


Index: 
lldb/trunk/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
===
--- 
lldb/trunk/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
+++ 
lldb/trunk/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
@@ -1383,7 +1383,8 @@
   packet, "unexpected content after $C{signal-number}");
   }
 
-  ResumeActionList resume_actions(StateType::eStateRunning, 0);
+  ResumeActionList resume_actions(StateType::eStateRunning,
+  LLDB_INVALID_SIGNAL_NUMBER);
   Status error;
 
   // We have two branches: what to do if a continue thread is specified (in
@@ -3322,4 +3323,4 @@
 }
   }
   return result;
-}
\ No newline at end of file
+}


Index: lldb/trunk/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
===
--- lldb/trunk/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
+++ lldb/trunk/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
@@ -1383,7 +1383,8 @@
   packet, "unexpected content after $C{signal-number}");
   }
 
-  ResumeActionList resume_actions(StateType::eStateRunning, 0);
+  ResumeActionList resume_actions(StateType::eStateRunning,
+  LLDB_INVALID_SIGNAL_NUMBER);
   Status error;
 
   // We have two branches: what to do if a continue thread is specified (in
@@ -3322,4 +3323,4 @@
 }
   }
   return result;
-}
\ No newline at end of file
+}
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D67390: [LLDB][ELF] Load both, .symtab and .dynsym sections

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

In D67390#1672210 , @kwk wrote:

> So my point of this whole question is: What makes a symbol unique in the 
> sense that it shouldn't be added to the symtab if it is already there?


A symbol name is not unique because you can have multiple (static) functions 
with the same (mangled) name in one module. An address is not unique as well 
because you can have symbol aliases, which will have the same address (and we 
want to keep both names to resolve name breakpoints correctly for instance).

The name+address combination (my original suggestion) should be sufficiently 
unique for the purposes we care about. Theoretically, if you want, you could 
include some additional items in the uniqueness "key" like symbol type etc. (to 
rule out the perverse case of somebody setting a "file" symbol to conflict with 
some other function symbol), but I don't think that is really necessary.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67390



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

[Lldb-commits] [PATCH] D67589: Fix crash on SBCommandReturnObject & assignment

2019-09-17 Thread Jan Kratochvil via Phabricator via lldb-commits 
jankratochvil marked 3 inline comments as done.
jankratochvil added a comment.

In D67589#1670966 , @labath wrote:

> I agree that this approach isn't nice, but probably there isn't a nice 
> approach to this at this point. One possibility you could consider is storing 
> a shared_ptr inside SBCommandRO and encoding the ownership into 
> the deleter of the shared_ptr (regular deleter => owned, noop deleter => 
> unowned).


Maybe also possibly cheaper `llvm::PointerIntPair` representing an associated 
`bool` for the deletion.




Comment at: 
lldb/packages/Python/lldbsuite/test/api/command-return-object/main.cpp:18
+result = subcommand(dbg, "help");
+result = result;
+if (!result.Succeeded())

labath wrote:
> Is that intentional? If so, why?
It has no purpose there for this bugfix but when already writing a testcase I 
wanted to test this generally fragile functionality.




Comment at: lldb/source/API/SBCommandInterpreter.cpp:165-172
+SBCommandReturnObject sb_return;
+std::swap(result, SBCommandReturnObject_ref(sb_return));
 SBCommandInterpreter sb_interpreter(&m_interpreter);
 SBDebugger debugger_sb(m_interpreter.GetDebugger().shared_from_this());
 bool ret = m_backend->DoExecute(
 debugger_sb, (char **)command.GetArgumentVector(), sb_return);
+std::swap(result, SBCommandReturnObject_ref(sb_return));

clayborg wrote:
> Could this code just create a local SBCommandReturnObject and then copy the 
> CommandReturnObject back into "result"?
> 
> ```
>  bool DoExecute(Args &command, CommandReturnObject &result) override {
> SBCommandReturnObject sb_return;
> SBCommandInterpreter sb_interpreter(&m_interpreter);
> SBDebugger debugger_sb(m_interpreter.GetDebugger().shared_from_this());
> bool ret = m_backend->DoExecute(
> debugger_sb, (char **)command.GetArgumentVector(), sb_return);
> std::swap(result, sb_return.ref());
> return ret;
> }
> ```
I made it that way first but it breaks the testsuite. For example due to:
```
lldb/source/Commands/CommandObjectCommands.cpp:
1236  bool DoExecute(llvm::StringRef raw_command_line,
1237 CommandReturnObject &result) override {
...
1242result.SetStatus(eReturnStatusInvalid);
 - ctored CommandReturnObject has eReturnStatusStarted.
1244if (!scripter ||
1245!scripter->RunScriptBasedCommand(m_function_name.c_str(),
1246 raw_command_line, m_synchro, 
result,
1247 error, m_exe_ctx)) {
1248  result.AppendError(error.AsCString());
1249  result.SetStatus(eReturnStatusFailed);
1250} else {
1251  // Don't change the status if the command already set it...
1252  if (result.GetStatus() == eReturnStatusInvalid) {
1253if (result.GetOutputData().empty())
1254  result.SetStatus(eReturnStatusSuccessFinishNoResult);
1255else
1256  result.SetStatus(eReturnStatusSuccessFinishResult);
1257  }
1258}
```
So it would be possible but that would require refactorization more of the code 
in callers which I find outside of the scope of this patch.
This patch tries to make this bugfix fully transparent to existing code.



Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D67589



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

[Lldb-commits] [PATCH] D67589: Fix crash on SBCommandReturnObject & assignment

2019-09-17 Thread Jan Kratochvil via Phabricator via lldb-commits 
jankratochvil updated this revision to Diff 220505.

Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D67589

Files:
  lldb/include/lldb/API/SBCommandReturnObject.h
  lldb/packages/Python/lldbsuite/test/api/command-return-object/Makefile
  
lldb/packages/Python/lldbsuite/test/api/command-return-object/TestSBCommandReturnObject.py
  lldb/packages/Python/lldbsuite/test/api/command-return-object/main.cpp
  lldb/scripts/Python/python-wrapper.swig
  lldb/source/API/SBCommandInterpreter.cpp
  lldb/source/API/SBCommandReturnObject.cpp

Index: lldb/source/API/SBCommandReturnObject.cpp
===
--- lldb/source/API/SBCommandReturnObject.cpp
+++ lldb/source/API/SBCommandReturnObject.cpp
@@ -18,6 +18,11 @@
 using namespace lldb;
 using namespace lldb_private;
 
+lldb_private::CommandReturnObject &
+lldb_private::SBCommandReturnObject_ref(SBCommandReturnObject &sb_cmd) {
+  return sb_cmd.ref();
+}
+
 SBCommandReturnObject::SBCommandReturnObject()
 : m_opaque_up(new CommandReturnObject()) {
   LLDB_RECORD_CONSTRUCTOR_NO_ARGS(SBCommandReturnObject);
@@ -31,21 +36,8 @@
   m_opaque_up = clone(rhs.m_opaque_up);
 }
 
-SBCommandReturnObject::SBCommandReturnObject(CommandReturnObject *ptr)
-: m_opaque_up(ptr) {
-  LLDB_RECORD_CONSTRUCTOR(SBCommandReturnObject,
-  (lldb_private::CommandReturnObject *), ptr);
-}
-
 SBCommandReturnObject::~SBCommandReturnObject() = default;
 
-CommandReturnObject *SBCommandReturnObject::Release() {
-  LLDB_RECORD_METHOD_NO_ARGS(lldb_private::CommandReturnObject *,
- SBCommandReturnObject, Release);
-
-  return LLDB_RECORD_RESULT(m_opaque_up.release());
-}
-
 const SBCommandReturnObject &SBCommandReturnObject::
 operator=(const SBCommandReturnObject &rhs) {
   LLDB_RECORD_METHOD(
@@ -338,10 +330,6 @@
   LLDB_REGISTER_CONSTRUCTOR(SBCommandReturnObject, ());
   LLDB_REGISTER_CONSTRUCTOR(SBCommandReturnObject,
 (const lldb::SBCommandReturnObject &));
-  LLDB_REGISTER_CONSTRUCTOR(SBCommandReturnObject,
-(lldb_private::CommandReturnObject *));
-  LLDB_REGISTER_METHOD(lldb_private::CommandReturnObject *,
-   SBCommandReturnObject, Release, ());
   LLDB_REGISTER_METHOD(
   const lldb::SBCommandReturnObject &,
   SBCommandReturnObject, operator=,(const lldb::SBCommandReturnObject &));
Index: lldb/source/API/SBCommandInterpreter.cpp
===
--- lldb/source/API/SBCommandInterpreter.cpp
+++ lldb/source/API/SBCommandInterpreter.cpp
@@ -162,12 +162,13 @@
 
 protected:
   bool DoExecute(Args &command, CommandReturnObject &result) override {
-SBCommandReturnObject sb_return(&result);
+SBCommandReturnObject sb_return;
+std::swap(result, SBCommandReturnObject_ref(sb_return));
 SBCommandInterpreter sb_interpreter(&m_interpreter);
 SBDebugger debugger_sb(m_interpreter.GetDebugger().shared_from_this());
 bool ret = m_backend->DoExecute(
 debugger_sb, (char **)command.GetArgumentVector(), sb_return);
-sb_return.Release();
+std::swap(result, SBCommandReturnObject_ref(sb_return));
 return ret;
   }
   std::shared_ptr m_backend;
Index: lldb/scripts/Python/python-wrapper.swig
===
--- lldb/scripts/Python/python-wrapper.swig
+++ lldb/scripts/Python/python-wrapper.swig
@@ -650,30 +650,6 @@
 return sb_ptr;
 }
 
-// Currently, SBCommandReturnObjectReleaser wraps a unique pointer to an
-// lldb_private::CommandReturnObject. This means that the destructor for the
-// SB object will deallocate its contained CommandReturnObject. Because that
-// object is used as the real return object for Python-based commands, we want
-// it to stay around. Thus, we release the unique pointer before returning from
-// LLDBSwigPythonCallCommand, and to guarantee that the release will occur no
-// matter how we exit from the function, we have a releaser object whose
-// destructor does the right thing for us
-class SBCommandReturnObjectReleaser
-{
-public:
-SBCommandReturnObjectReleaser (lldb::SBCommandReturnObject &obj) :
-m_command_return_object_ref (obj)
-{
-}
-
-~SBCommandReturnObjectReleaser ()
-{
-m_command_return_object_ref.Release();
-}
-private:
-lldb::SBCommandReturnObject &m_command_return_object_ref;
-};
-
 SWIGEXPORT bool
 LLDBSwigPythonCallCommand
 (
@@ -686,8 +662,8 @@
 )
 {
 using namespace lldb_private;
-lldb::SBCommandReturnObject cmd_retobj_sb(&cmd_retobj);
-SBCommandReturnObjectReleaser cmd_retobj_sb_releaser(cmd_retobj_sb);
+lldb::SBCommandReturnObject cmd_retobj_sb;
+std::swap(cmd_retobj, SBCommandReturnObject_ref(cmd_retobj_sb));
 lldb::SBDebugger debugger_sb(debugger);
 lldb::SBExecutionContext exe_ctx_sb(exe_ctx_ref_s

[Lldb-commits] [PATCH] D67589: Fix crash on SBCommandReturnObject & assignment

2019-09-17 Thread Jan Kratochvil via Phabricator via lldb-commits 
jankratochvil marked an inline comment as done.
jankratochvil added inline comments.



Comment at: 
lldb/packages/Python/lldbsuite/test/api/command-return-object/main.cpp:18
+result = subcommand(dbg, "help");
+result = result;
+if (!result.Succeeded())

jankratochvil wrote:
> labath wrote:
> > Is that intentional? If so, why?
> It has no purpose there for this bugfix but when already writing a testcase I 
> wanted to test this generally fragile functionality.
> 
If you mean the line:
```
+ if (!result.Succeeded())
```
That is not really needed for this testcase but I think this is how a real 
world implementation should behave so why not here, just 2 lines of code.



Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D67589



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

[Lldb-commits] [PATCH] D67390: [LLDB][ELF] Load both, .symtab and .dynsym sections

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

In D67390#1672210 , @kwk wrote:

> @clayborg thank you for this explanation. My patch for minidebuginfo is 
> already done in D66791  . But this one here 
> I was asked to pull out as a separate patch. For good reasons as we see. I 
> wonder how this extra parameter `SymbolMapType` of yours does help. In the 
> end I have to identify duplicates. But if no symbol with the same **name** 
> should be added then why do I care about where the symbol is coming from?


The uniqueness is for symbols with the same name and file address and size. You 
can have multiple symbols with the same name, and each on could have a 
different address. We want there to only be one symbol per ObjectFile that has 
the same name + addr + size. That way when we ask for symbols by name, we don't 
have to end up getting more than one symbol for something that is the same 
thing.

> Please help me understand of follow my thoughts here:
> 
> When I'm in the `(lldb)` console and type `b foo` I expect LLDB to set a 
> breakpoint on the **function** foo, right? The type of the symbol `foo` is 
> deduced as **function**.

Breakpoints ask for symbols whose type is lldb::eSymbolTypeCode and that match 
the name. The name matching is much more complex than you would think though. 
"b foo" by default turns into 'set a breakpoint on functions whose "basename" 
matches foo'. This means a C function named 'foo', any C++ method (stand alone 
function or class method) whose basename is 'foo' (bar::foo(int)", "foo(int)", 
"foo(float)", "std::a::b::foo()", many more) and any objective C function whose 
selector is 'foo' ("-[MyClass foo]", "+[AnotherClass foo]", and any other 
basename from any other language.

If you type "b foo::bar" this will end up looking up all functions whose 
basename is "bar" and then making sure any found matches contain "foo::bar".

> I ask this question because `Symtab` has no function to just search for a 
> symbol by name; instead you always have to pass an address, a type or an ID:
> 
>   Symbol *FindSymbolByID(lldb::user_id_t uid) const;
>   Symbol *FindSymbolWithType(lldb::SymbolType symbol_type,
>   size_t FindAllSymbolsWithNameAndType(ConstString name,
>   size_t FindAllSymbolsWithNameAndType(ConstString name,
>   size_t FindAllSymbolsMatchingRexExAndType(
>   Symbol *FindFirstSymbolWithNameAndType(ConstString name,
>   Symbol *FindSymbolAtFileAddress(lldb::addr_t file_addr);
>   Symbol *FindSymbolContainingFileAddress(lldb::addr_t file_addr);
>   size_t FindFunctionSymbols(ConstString name, uint32_t name_type_mask,
>

FindAllSymbolsWithNameAndType() takes a name. The symbol type can be 
lldb::eSymbolTypeAny, so yes there is way to search. So there is a way to 
search for a symbol by name. The main issue is we are still parsing the symbol 
table and we don't want to initialized the name lookup table in the symbol 
table just yet since we are still adding symbols to the complete list. This is 
why an extra map that is used only during parsing of the symbol table makes 
sense.

> So my point of this whole question is: What makes a symbol unique in the 
> sense that it shouldn't be added to the symtab if it is already there?

Symbol  is unique within one representation of an ObjectFile where the symbol 
has the same name, address and size and type.

> Shouldn't the type of the symbol together with it's name define uniqueness? 
> We shouldn't care about where the symbol is coming from nor if it is located 
> at a different address.

We don't care where the symbol comes from as long as it is representing 
information for one ObjectFile. I would contend that if you have an "a.out" 
binary that has a .gnu_debugdata that points to "a.out.gnu_debugdata" that we 
would have one single ObjectFile that represents "a.out" and give the best 
description of what "a.out" contains.

We do care if a symbol has a different address. You can have as many static 
functions called "foo" as you want in a single binary. They are each unique 
since they have different addresses. So if you have 10 source files where 3 of 
those sources have a symbol "foo", we want there to be 3 different symbols with 
the same name, different addresses and possibly different sizes.

> Well, if there's an overloaded function `foo(int)` and `foo(char*)` then both 
> symbols are of type **function** and they both share the same **name**. When 
> you type `b foo` you DO want 2 breakpoints to be set.

Yes we do! One breakpoint in LLDB has N breakpoint locations. A breakpoint of 
any kind (source file and line, function name breakpoint, and more) all 
constantly adding and removing locations as shared libraries get loaded. So if 
you have "foo(int)" and "foo(char *)" and say "b foo" we would end up with one 
breakpoint whose name matches "foo" with two locations.

> Hence, niqueness cannot be defined over the name and the type . But wait, the 
> **name** is mang

[Lldb-commits] [PATCH] D67390: [LLDB][ELF] Load both, .symtab and .dynsym sections

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

In D67390#1672254 , @labath wrote:

> In D67390#1672210 , @kwk wrote:
>
> > So my point of this whole question is: What makes a symbol unique in the 
> > sense that it shouldn't be added to the symtab if it is already there?
>
>
> A symbol name is not unique because you can have multiple (static) functions 
> with the same (mangled) name in one module. An address is not unique as well 
> because you can have symbol aliases, which will have the same address (and we 
> want to keep both names to resolve name breakpoints correctly for instance).
>
> The name+address combination (my original suggestion) should be sufficiently 
> unique for the purposes we care about. Theoretically, if you want, you could 
> include some additional items in the uniqueness "key" like symbol type etc. 
> (to rule out the perverse case of somebody setting a "file" symbol to 
> conflict with some other function symbol), but I don't think that is really 
> necessary.


We could track any extra data we need in the map if needed as Pavel suggests 
above. Not sure if it is needed, but we could do it if necessary.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67390



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

[Lldb-commits] [PATCH] D67589: Fix crash on SBCommandReturnObject & assignment

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



Comment at: lldb/include/lldb/API/SBCommandReturnObject.h:22-27
+namespace lldb_private {
+// Wrap SBCommandReturnObject::ref() so that any LLDB internal function can
+// call it but still no SB API users can call it.
+CommandReturnObject &
+SBCommandReturnObject_ref(lldb::SBCommandReturnObject &sb_cmd);
+} // namespace lldb_private

Easier to just make SBCommandReturnObject::ref() protected and friend any users 
or just make it public?



Comment at: lldb/include/lldb/API/SBCommandReturnObject.h:99-100
   friend class SBOptions;
+  friend lldb_private::CommandReturnObject &
+  lldb_private::SBCommandReturnObject_ref(SBCommandReturnObject &sb_cmd);
 

Remove if we make SBCommandReturnObject::ref() protected and friend any users 
or just make it public?



Comment at: lldb/include/lldb/API/SBCommandReturnObject.h:108
 
   lldb_private::CommandReturnObject &ref() const;
 

Easier to just make SBCommandReturnObject::ref() protected and friend any users 
or just make it public?



Comment at: lldb/source/API/SBCommandReturnObject.cpp:21-24
+lldb_private::CommandReturnObject &
+lldb_private::SBCommandReturnObject_ref(SBCommandReturnObject &sb_cmd) {
+  return sb_cmd.ref();
+}

Easier to just make SBCommandReturnObject::ref() protected and friend any users 
or just make it public?


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D67589



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

[Lldb-commits] [PATCH] D67641: Cache PYTHON_EXECUTABLE for windows

2019-09-17 Thread Jonas Devlieghere via Phabricator via lldb-commits 
JDevlieghere accepted this revision.
JDevlieghere added a comment.
This revision is now accepted and ready to land.

LGTM!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67641



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

[Lldb-commits] [PATCH] D67641: Cache PYTHON_EXECUTABLE for windows

2019-09-17 Thread Haibo Huang via Phabricator via lldb-commits 
hhb updated this revision to Diff 220584.
hhb added a comment.

Turns out I still need to change previous lines to remove PARENT_SCOPE. 
Otherwise local value will still be used even if a different value is set in 
the cache.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67641

Files:
  lldb/cmake/modules/LLDBConfig.cmake


Index: lldb/cmake/modules/LLDBConfig.cmake
===
--- lldb/cmake/modules/LLDBConfig.cmake
+++ lldb/cmake/modules/LLDBConfig.cmake
@@ -250,16 +250,23 @@
   endif()
 
   # Set the same variables as FindPythonInterp and FindPythonLibs.
-  set(PYTHON_EXECUTABLE "${PYTHON_EXECUTABLE}"  PARENT_SCOPE)
-  set(PYTHON_LIBRARY"${PYTHON_LIBRARY}" PARENT_SCOPE)
-  set(PYTHON_DLL"${PYTHON_DLL}" PARENT_SCOPE)
-  set(PYTHON_INCLUDE_DIR"${PYTHON_INCLUDE_DIR}" PARENT_SCOPE)
+  set(PYTHON_EXECUTABLE "${PYTHON_EXECUTABLE}")
+  set(PYTHON_LIBRARY"${PYTHON_LIBRARY}")
+  set(PYTHON_DLL"${PYTHON_DLL}")
+  set(PYTHON_INCLUDE_DIR"${PYTHON_INCLUDE_DIR}")
   set(PYTHONLIBS_VERSION_STRING "${PYTHONLIBS_VERSION_STRING}"  PARENT_SCOPE)
   set(PYTHON_VERSION_STRING "${PYTHON_VERSION_STRING}"  PARENT_SCOPE)
   set(PYTHON_VERSION_MAJOR  "${PYTHON_VERSION_MAJOR}"   PARENT_SCOPE)
   set(PYTHON_VERSION_MINOR  "${PYTHON_VERSION_MINOR}"   PARENT_SCOPE)
   set(PYTHON_VERSION_PATCH  "${PYTHON_VERSION_PATCH}"   PARENT_SCOPE)
 
+  mark_as_advanced(
+PYTHON_EXECUTABLE
+PYTHON_LIBRARY
+PYTHON_DLL
+PYTHON_INCLUDE_DIR
+  )
+
   message(STATUS "LLDB Found PythonExecutable: ${PYTHON_EXECUTABLE} 
(${PYTHON_VERSION_STRING})")
   message(STATUS "LLDB Found PythonLibs: ${PYTHON_LIBRARY} 
(${PYTHONLIBS_VERSION_STRING})")
   message(STATUS "LLDB Found PythonDLL: ${PYTHON_DLL}")


Index: lldb/cmake/modules/LLDBConfig.cmake
===
--- lldb/cmake/modules/LLDBConfig.cmake
+++ lldb/cmake/modules/LLDBConfig.cmake
@@ -250,16 +250,23 @@
   endif()
 
   # Set the same variables as FindPythonInterp and FindPythonLibs.
-  set(PYTHON_EXECUTABLE "${PYTHON_EXECUTABLE}"  PARENT_SCOPE)
-  set(PYTHON_LIBRARY"${PYTHON_LIBRARY}" PARENT_SCOPE)
-  set(PYTHON_DLL"${PYTHON_DLL}" PARENT_SCOPE)
-  set(PYTHON_INCLUDE_DIR"${PYTHON_INCLUDE_DIR}" PARENT_SCOPE)
+  set(PYTHON_EXECUTABLE "${PYTHON_EXECUTABLE}")
+  set(PYTHON_LIBRARY"${PYTHON_LIBRARY}")
+  set(PYTHON_DLL"${PYTHON_DLL}")
+  set(PYTHON_INCLUDE_DIR"${PYTHON_INCLUDE_DIR}")
   set(PYTHONLIBS_VERSION_STRING "${PYTHONLIBS_VERSION_STRING}"  PARENT_SCOPE)
   set(PYTHON_VERSION_STRING "${PYTHON_VERSION_STRING}"  PARENT_SCOPE)
   set(PYTHON_VERSION_MAJOR  "${PYTHON_VERSION_MAJOR}"   PARENT_SCOPE)
   set(PYTHON_VERSION_MINOR  "${PYTHON_VERSION_MINOR}"   PARENT_SCOPE)
   set(PYTHON_VERSION_PATCH  "${PYTHON_VERSION_PATCH}"   PARENT_SCOPE)
 
+  mark_as_advanced(
+PYTHON_EXECUTABLE
+PYTHON_LIBRARY
+PYTHON_DLL
+PYTHON_INCLUDE_DIR
+  )
+
   message(STATUS "LLDB Found PythonExecutable: ${PYTHON_EXECUTABLE} (${PYTHON_VERSION_STRING})")
   message(STATUS "LLDB Found PythonLibs: ${PYTHON_LIBRARY} (${PYTHONLIBS_VERSION_STRING})")
   message(STATUS "LLDB Found PythonDLL: ${PYTHON_DLL}")
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D67685: [ScriptInterpreter] Make sure LLDB's global variables are only available in interactive mode.

2019-09-17 Thread Jonas Devlieghere via Phabricator via lldb-commits 
JDevlieghere created this revision.
JDevlieghere added a reviewer: jingham.

Jim pointed out that the LLDB global variables should only be available in 
interactive mode. When used from a command, their values might be stale or not 
at all what the user expects. Therefore we want to explicitly makes these 
variables unavailable.


https://reviews.llvm.org/D67685

Files:
  lldb/lit/Commands/Inputs/frame.py
  lldb/lit/Commands/command-script-import.test
  lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp


Index: lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
===
--- lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
+++ lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
@@ -2691,12 +2691,12 @@
 StreamString command_stream;
 
 // Before executing Python code, lock the GIL.
-Locker py_lock(
-this,
-Locker::AcquireLock | (init_session ? Locker::InitSession : 0) |
-(init_session ? Locker::InitGlobals : 0) | Locker::NoSTDIN,
-Locker::FreeAcquiredLock |
-(init_session ? Locker::TearDownSession : 0));
+Locker py_lock(this,
+   Locker::AcquireLock |
+   (init_session ? Locker::InitSession : 0) |
+   Locker::NoSTDIN,
+   Locker::FreeAcquiredLock |
+   (init_session ? Locker::TearDownSession : 0));
 namespace fs = llvm::sys::fs;
 fs::file_status st;
 std::error_code ec = status(target_file.GetPath(), st);
Index: lldb/lit/Commands/command-script-import.test
===
--- lldb/lit/Commands/command-script-import.test
+++ lldb/lit/Commands/command-script-import.test
@@ -3,6 +3,10 @@
 # RUN: echo 'command script import %S/Inputs/frame.py' >> %t.in
 
 # RUN: %clang -g -O0 %S/Inputs/main.c -o %t.out
-# RUN: %lldb -b -s %t.in %t.out | FileCheck %s
+# RUN: %lldb -b -s %t.in -o 'script print("script: {}").format(lldb.frame)' 
%t.out | FileCheck %s
 
-# CHECK: frame #0
+# Make sure that we don't have access to lldb.frame from the Python script.
+# CHECK: frame:py: None
+
+# Make sure that we do have access to lldb.frame from the script command.
+# CHECK: script: frame #0
Index: lldb/lit/Commands/Inputs/frame.py
===
--- lldb/lit/Commands/Inputs/frame.py
+++ lldb/lit/Commands/Inputs/frame.py
@@ -1,2 +1,2 @@
 import lldb
-print(lldb.frame)
+print("frame:py: {}".format(lldb.frame))


Index: lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
===
--- lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
+++ lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
@@ -2691,12 +2691,12 @@
 StreamString command_stream;
 
 // Before executing Python code, lock the GIL.
-Locker py_lock(
-this,
-Locker::AcquireLock | (init_session ? Locker::InitSession : 0) |
-(init_session ? Locker::InitGlobals : 0) | Locker::NoSTDIN,
-Locker::FreeAcquiredLock |
-(init_session ? Locker::TearDownSession : 0));
+Locker py_lock(this,
+   Locker::AcquireLock |
+   (init_session ? Locker::InitSession : 0) |
+   Locker::NoSTDIN,
+   Locker::FreeAcquiredLock |
+   (init_session ? Locker::TearDownSession : 0));
 namespace fs = llvm::sys::fs;
 fs::file_status st;
 std::error_code ec = status(target_file.GetPath(), st);
Index: lldb/lit/Commands/command-script-import.test
===
--- lldb/lit/Commands/command-script-import.test
+++ lldb/lit/Commands/command-script-import.test
@@ -3,6 +3,10 @@
 # RUN: echo 'command script import %S/Inputs/frame.py' >> %t.in
 
 # RUN: %clang -g -O0 %S/Inputs/main.c -o %t.out
-# RUN: %lldb -b -s %t.in %t.out | FileCheck %s
+# RUN: %lldb -b -s %t.in -o 'script print("script: {}").format(lldb.frame)' %t.out | FileCheck %s
 
-# CHECK: frame #0
+# Make sure that we don't have access to lldb.frame from the Python script.
+# CHECK: frame:py: None
+
+# Make sure that we do have access to lldb.frame from the script command.
+# CHECK: script: frame #0
Index: lldb/lit/Commands/Inputs/frame.py
===
--- lldb/lit/Commands/Inputs/frame.py
+++ lldb/lit/Commands/Inputs/frame.py
@@ -1,2 +1,2 @@
 import lldb
-print(lldb.frame)
+print("frame:py: {}".format(lldb.frame))
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] r372190 - [ScriptInterpreter] Remove ScriptInterpreterPythonImpl::Clear() (NFC)

2019-09-17 Thread Jonas Devlieghere via lldb-commits 
Author: jdevlieghere
Date: Tue Sep 17 17:01:52 2019
New Revision: 372190

URL: http://llvm.org/viewvc/llvm-project?rev=372190&view=rev
Log:
[ScriptInterpreter] Remove ScriptInterpreterPythonImpl::Clear() (NFC)

This method is never called.

Modified:

lldb/trunk/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp

lldb/trunk/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPythonImpl.h

Modified: 
lldb/trunk/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp?rev=372190&r1=372189&r2=372190&view=diff
==
--- 
lldb/trunk/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp 
(original)
+++ 
lldb/trunk/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp 
Tue Sep 17 17:01:52 2019
@@ -2212,18 +2212,6 @@ bool ScriptInterpreterPythonImpl::GetScr
   return ret_val;
 }
 
-void ScriptInterpreterPythonImpl::Clear() {
-  // Release any global variables that might have strong references to
-  // LLDB objects when clearing the python script interpreter.
-  Locker locker(this, Locker::AcquireLock, Locker::FreeAcquiredLock);
-
-  // This may be called as part of Py_Finalize.  In that case the modules are
-  // destroyed in random order and we can't guarantee that we can access these.
-  if (Py_IsInitialized())
-PyRun_SimpleString("lldb.debugger = None; lldb.target = None; lldb.process 
"
-   "= None; lldb.thread = None; lldb.frame = None");
-}
-
 bool ScriptInterpreterPythonImpl::BreakpointCallbackFunction(
 void *baton, StoppointCallbackContext *context, user_id_t break_id,
 user_id_t break_loc_id) {

Modified: 
lldb/trunk/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPythonImpl.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPythonImpl.h?rev=372190&r1=372189&r2=372190&view=diff
==
--- 
lldb/trunk/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPythonImpl.h
 (original)
+++ 
lldb/trunk/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPythonImpl.h
 Tue Sep 17 17:01:52 2019
@@ -188,8 +188,6 @@ public:
   const TypeSummaryOptions &options,
   std::string &retval) override;
 
-  void Clear() override;
-
   bool GetDocumentationForItem(const char *item, std::string &dest) override;
 
   bool GetShortHelpForCommandObject(StructuredData::GenericSP cmd_obj_sp,


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

[Lldb-commits] [PATCH] D67641: Cache PYTHON_EXECUTABLE for windows

2019-09-17 Thread Haibo Huang via Phabricator via lldb-commits 
hhb updated this revision to Diff 220589.
hhb added a comment.

Add CACHE PATH again. I think this is the only way to go.

With PARENT_SCOPE: Tthe local detected value is always used, even if a 
different value is set in cache.
With no parameter: Always the value in cache is used. If a value is not set in 
cache, empty is used.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67641

Files:
  lldb/cmake/modules/LLDBConfig.cmake


Index: lldb/cmake/modules/LLDBConfig.cmake
===
--- lldb/cmake/modules/LLDBConfig.cmake
+++ lldb/cmake/modules/LLDBConfig.cmake
@@ -250,16 +250,23 @@
   endif()
 
   # Set the same variables as FindPythonInterp and FindPythonLibs.
-  set(PYTHON_EXECUTABLE "${PYTHON_EXECUTABLE}"  PARENT_SCOPE)
-  set(PYTHON_LIBRARY"${PYTHON_LIBRARY}" PARENT_SCOPE)
-  set(PYTHON_DLL"${PYTHON_DLL}" PARENT_SCOPE)
-  set(PYTHON_INCLUDE_DIR"${PYTHON_INCLUDE_DIR}" PARENT_SCOPE)
+  set(PYTHON_EXECUTABLE "${PYTHON_EXECUTABLE}"  CACHE PATH "")
+  set(PYTHON_LIBRARY"${PYTHON_LIBRARY}" CACHE PATH "")
+  set(PYTHON_DLL"${PYTHON_DLL}" CACHE PATH "")
+  set(PYTHON_INCLUDE_DIR"${PYTHON_INCLUDE_DIR}" CACHE PATH "")
   set(PYTHONLIBS_VERSION_STRING "${PYTHONLIBS_VERSION_STRING}"  PARENT_SCOPE)
   set(PYTHON_VERSION_STRING "${PYTHON_VERSION_STRING}"  PARENT_SCOPE)
   set(PYTHON_VERSION_MAJOR  "${PYTHON_VERSION_MAJOR}"   PARENT_SCOPE)
   set(PYTHON_VERSION_MINOR  "${PYTHON_VERSION_MINOR}"   PARENT_SCOPE)
   set(PYTHON_VERSION_PATCH  "${PYTHON_VERSION_PATCH}"   PARENT_SCOPE)
 
+  mark_as_advanced(
+PYTHON_EXECUTABLE
+PYTHON_LIBRARY
+PYTHON_DLL
+PYTHON_INCLUDE_DIR
+  )
+
   message(STATUS "LLDB Found PythonExecutable: ${PYTHON_EXECUTABLE} 
(${PYTHON_VERSION_STRING})")
   message(STATUS "LLDB Found PythonLibs: ${PYTHON_LIBRARY} 
(${PYTHONLIBS_VERSION_STRING})")
   message(STATUS "LLDB Found PythonDLL: ${PYTHON_DLL}")


Index: lldb/cmake/modules/LLDBConfig.cmake
===
--- lldb/cmake/modules/LLDBConfig.cmake
+++ lldb/cmake/modules/LLDBConfig.cmake
@@ -250,16 +250,23 @@
   endif()
 
   # Set the same variables as FindPythonInterp and FindPythonLibs.
-  set(PYTHON_EXECUTABLE "${PYTHON_EXECUTABLE}"  PARENT_SCOPE)
-  set(PYTHON_LIBRARY"${PYTHON_LIBRARY}" PARENT_SCOPE)
-  set(PYTHON_DLL"${PYTHON_DLL}" PARENT_SCOPE)
-  set(PYTHON_INCLUDE_DIR"${PYTHON_INCLUDE_DIR}" PARENT_SCOPE)
+  set(PYTHON_EXECUTABLE "${PYTHON_EXECUTABLE}"  CACHE PATH "")
+  set(PYTHON_LIBRARY"${PYTHON_LIBRARY}" CACHE PATH "")
+  set(PYTHON_DLL"${PYTHON_DLL}" CACHE PATH "")
+  set(PYTHON_INCLUDE_DIR"${PYTHON_INCLUDE_DIR}" CACHE PATH "")
   set(PYTHONLIBS_VERSION_STRING "${PYTHONLIBS_VERSION_STRING}"  PARENT_SCOPE)
   set(PYTHON_VERSION_STRING "${PYTHON_VERSION_STRING}"  PARENT_SCOPE)
   set(PYTHON_VERSION_MAJOR  "${PYTHON_VERSION_MAJOR}"   PARENT_SCOPE)
   set(PYTHON_VERSION_MINOR  "${PYTHON_VERSION_MINOR}"   PARENT_SCOPE)
   set(PYTHON_VERSION_PATCH  "${PYTHON_VERSION_PATCH}"   PARENT_SCOPE)
 
+  mark_as_advanced(
+PYTHON_EXECUTABLE
+PYTHON_LIBRARY
+PYTHON_DLL
+PYTHON_INCLUDE_DIR
+  )
+
   message(STATUS "LLDB Found PythonExecutable: ${PYTHON_EXECUTABLE} (${PYTHON_VERSION_STRING})")
   message(STATUS "LLDB Found PythonLibs: ${PYTHON_LIBRARY} (${PYTHONLIBS_VERSION_STRING})")
   message(STATUS "LLDB Found PythonDLL: ${PYTHON_DLL}")
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D67685: [ScriptInterpreter] Make sure LLDB's global variables are only available in interactive mode.

2019-09-17 Thread Jonas Devlieghere via Phabricator via lldb-commits 
JDevlieghere updated this revision to Diff 220588.

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

https://reviews.llvm.org/D67685

Files:
  lldb/lit/Commands/Inputs/frame.py
  lldb/lit/Commands/command-script-import.test
  lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp


Index: lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
===
--- lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
+++ lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
@@ -616,6 +616,10 @@
   if (log)
 log->PutCString("ScriptInterpreterPythonImpl::LeaveSession()");
 
+  // Unset the LLDB global variables.
+  PyRun_SimpleString("lldb.debugger = None; lldb.target = None; lldb.process "
+  "= None; lldb.thread = None; lldb.frame = None");
+
   // checking that we have a valid thread state - since we use our own
   // threading and locking in some (rare) cases during cleanup Python may end
   // up believing we have no thread state and PyImport_AddModule will crash if
@@ -2687,12 +2691,12 @@
 StreamString command_stream;
 
 // Before executing Python code, lock the GIL.
-Locker py_lock(
-this,
-Locker::AcquireLock | (init_session ? Locker::InitSession : 0) |
-(init_session ? Locker::InitGlobals : 0) | Locker::NoSTDIN,
-Locker::FreeAcquiredLock |
-(init_session ? Locker::TearDownSession : 0));
+Locker py_lock(this,
+   Locker::AcquireLock |
+   (init_session ? Locker::InitSession : 0) |
+   Locker::NoSTDIN,
+   Locker::FreeAcquiredLock |
+   (init_session ? Locker::TearDownSession : 0));
 namespace fs = llvm::sys::fs;
 fs::file_status st;
 std::error_code ec = status(target_file.GetPath(), st);
Index: lldb/lit/Commands/command-script-import.test
===
--- lldb/lit/Commands/command-script-import.test
+++ lldb/lit/Commands/command-script-import.test
@@ -3,6 +3,10 @@
 # RUN: echo 'command script import %S/Inputs/frame.py' >> %t.in
 
 # RUN: %clang -g -O0 %S/Inputs/main.c -o %t.out
-# RUN: %lldb -b -s %t.in %t.out | FileCheck %s
+# RUN: %lldb -b -s %t.in -o 'script print("script: {}").format(lldb.frame)' 
%t.out | FileCheck %s
 
-# CHECK: frame #0
+# Make sure that we don't have access to lldb.frame from the Python script.
+# CHECK: frame:py: None
+
+# Make sure that we do have access to lldb.frame from the script command.
+# CHECK: script: frame #0
Index: lldb/lit/Commands/Inputs/frame.py
===
--- lldb/lit/Commands/Inputs/frame.py
+++ lldb/lit/Commands/Inputs/frame.py
@@ -1,2 +1,2 @@
 import lldb
-print(lldb.frame)
+print("frame:py: {}".format(lldb.frame))


Index: lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
===
--- lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
+++ lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
@@ -616,6 +616,10 @@
   if (log)
 log->PutCString("ScriptInterpreterPythonImpl::LeaveSession()");
 
+  // Unset the LLDB global variables.
+  PyRun_SimpleString("lldb.debugger = None; lldb.target = None; lldb.process "
+  "= None; lldb.thread = None; lldb.frame = None");
+
   // checking that we have a valid thread state - since we use our own
   // threading and locking in some (rare) cases during cleanup Python may end
   // up believing we have no thread state and PyImport_AddModule will crash if
@@ -2687,12 +2691,12 @@
 StreamString command_stream;
 
 // Before executing Python code, lock the GIL.
-Locker py_lock(
-this,
-Locker::AcquireLock | (init_session ? Locker::InitSession : 0) |
-(init_session ? Locker::InitGlobals : 0) | Locker::NoSTDIN,
-Locker::FreeAcquiredLock |
-(init_session ? Locker::TearDownSession : 0));
+Locker py_lock(this,
+   Locker::AcquireLock |
+   (init_session ? Locker::InitSession : 0) |
+   Locker::NoSTDIN,
+   Locker::FreeAcquiredLock |
+   (init_session ? Locker::TearDownSession : 0));
 namespace fs = llvm::sys::fs;
 fs::file_status st;
 std::error_code ec = status(target_file.GetPath(), st);
Index: lldb/lit/Commands/command-script-import.test
===
--- lldb/lit/Commands/command-script-import.test
+++ lldb/lit/Commands/command-script-import.test
@@ -3,6 +3,10 @@
 # RUN: echo 'command script import %S/Inputs/frame.py' >> %t.in
 
 # RUN: %clang -g -O0 %S/Inputs/main.c -o %t.out
-# RUN: %lldb -b -s %t.in %t.out | FileCheck %s
+# RU

[Lldb-commits] [PATCH] D67685: [ScriptInterpreter] Make sure LLDB's global variables are only available in interactive mode.

2019-09-17 Thread Jim Ingham via Phabricator via lldb-commits 
jingham accepted this revision.
jingham added a comment.
This revision is now accepted and ready to land.

This looks right.

EnterSession always initializes lldb.debugger, even when it isn't going to set 
the other globals.  That's because one debugger owns one ScriptInterpreter and 
lldb.debugger always has a unique, valid value.  So it isn't strictly necessary 
to None out lldb.debugger.  But since EnterSession always sets it, I don't 
think it matters one way or the other.


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

https://reviews.llvm.org/D67685



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

[Lldb-commits] [lldb] r372192 - [ScriptInterpreter] Limit LLDB's globals to interactive mode.

2019-09-17 Thread Jonas Devlieghere via lldb-commits 
Author: jdevlieghere
Date: Tue Sep 17 17:30:01 2019
New Revision: 372192

URL: http://llvm.org/viewvc/llvm-project?rev=372192&view=rev
Log:
[ScriptInterpreter] Limit LLDB's globals to interactive mode.

Jim pointed out that the LLDB global variables should only be available
in interactive mode. When used from a command for example, their values
might be stale or not at all what the user expects. Therefore we want to
explicitly make these variables unavailable.

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

Modified:
lldb/trunk/lit/Commands/Inputs/frame.py
lldb/trunk/lit/Commands/command-script-import.test

lldb/trunk/packages/Python/lldbsuite/test/commands/frame/recognizer/recognizer.py

lldb/trunk/packages/Python/lldbsuite/test/python_api/sbvalue_const_addrof/main.cpp

lldb/trunk/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp

Modified: lldb/trunk/lit/Commands/Inputs/frame.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/lit/Commands/Inputs/frame.py?rev=372192&r1=372191&r2=372192&view=diff
==
--- lldb/trunk/lit/Commands/Inputs/frame.py (original)
+++ lldb/trunk/lit/Commands/Inputs/frame.py Tue Sep 17 17:30:01 2019
@@ -1,2 +1,2 @@
 import lldb
-print(lldb.frame)
+print("frame:py: {}".format(lldb.frame))

Modified: lldb/trunk/lit/Commands/command-script-import.test
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/lit/Commands/command-script-import.test?rev=372192&r1=372191&r2=372192&view=diff
==
--- lldb/trunk/lit/Commands/command-script-import.test (original)
+++ lldb/trunk/lit/Commands/command-script-import.test Tue Sep 17 17:30:01 2019
@@ -3,6 +3,10 @@
 # RUN: echo 'command script import %S/Inputs/frame.py' >> %t.in
 
 # RUN: %clang -g -O0 %S/Inputs/main.c -o %t.out
-# RUN: %lldb -b -s %t.in %t.out | FileCheck %s
+# RUN: %lldb -b -s %t.in -o 'script print("script: {}").format(lldb.frame)' 
%t.out | FileCheck %s
 
-# CHECK: frame #0
+# Make sure that we don't have access to lldb.frame from the Python script.
+# CHECK: frame:py: None
+
+# Make sure that we do have access to lldb.frame from the script command.
+# CHECK: script: frame #0

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/commands/frame/recognizer/recognizer.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/commands/frame/recognizer/recognizer.py?rev=372192&r1=372191&r2=372192&view=diff
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/commands/frame/recognizer/recognizer.py
 (original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/commands/frame/recognizer/recognizer.py
 Tue Sep 17 17:30:01 2019
@@ -7,12 +7,12 @@ class MyFrameRecognizer(object):
 if frame.name == "foo":
 arg1 = frame.EvaluateExpression("$arg1").signed
 arg2 = frame.EvaluateExpression("$arg2").signed
-val1 = lldb.target.CreateValueFromExpression("a", "%d" % arg1)
-val2 = lldb.target.CreateValueFromExpression("b", "%d" % arg2)
+val1 = 
frame.GetThread().GetProcess().GetTarget().CreateValueFromExpression("a", "%d" 
% arg1)
+val2 = 
frame.GetThread().GetProcess().GetTarget().CreateValueFromExpression("b", "%d" 
% arg2)
 return [val1, val2]
 elif frame.name == "bar":
 arg1 = frame.EvaluateExpression("$arg1").signed
-val1 = lldb.target.CreateValueFromExpression("a", "(int *)%d" % 
arg1)
+val1 = 
frame.GetThread().GetProcess().GetTarget().CreateValueFromExpression("a", "(int 
*)%d" % arg1)
 return [val1]
 return []
 

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/python_api/sbvalue_const_addrof/main.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/python_api/sbvalue_const_addrof/main.cpp?rev=372192&r1=372191&r2=372192&view=diff
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/python_api/sbvalue_const_addrof/main.cpp
 (original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/python_api/sbvalue_const_addrof/main.cpp
 Tue Sep 17 17:30:01 2019
@@ -28,7 +28,7 @@ ThreadInfo *g_thread_list_ptr = &g_threa
 int main (int argc, char const *argv[], char const *envp[])
 {
 printf ("g_thread_list is %p\n", g_thread_list_ptr);
-return 0; //% v = lldb.target.FindFirstGlobalVariable('g_thread_list_ptr')
+return 0; //% v = 
self.dbg.GetSelectedTarget().FindFirstGlobalVariable('g_thread_list_ptr')
 //% v_gla = v.GetChildMemberWithName('regs').GetLoadAddress()
 //% v_aof = 
v.GetChildMemberWithName('regs').AddressOf().GetValueAsUnsigned(lldb.LLDB_INVALID_ADDRESS)
 //% expr = '(%s)0x%x' % (v.GetType().GetName(), v.GetValueAsUnsigned(0))

Modified: 
lldb/trunk/source/Plugins/Scrip

[Lldb-commits] [PATCH] D67685: [ScriptInterpreter] Make sure LLDB's global variables are only available in interactive mode.

2019-09-17 Thread Jonas Devlieghere via Phabricator via lldb-commits 
This revision was automatically updated to reflect the committed changes.
Closed by commit rL372192: [ScriptInterpreter] Limit LLDB's globals to 
interactive mode. (authored by JDevlieghere, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D67685?vs=220588&id=220592#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D67685

Files:
  lldb/trunk/lit/Commands/Inputs/frame.py
  lldb/trunk/lit/Commands/command-script-import.test
  
lldb/trunk/packages/Python/lldbsuite/test/commands/frame/recognizer/recognizer.py
  
lldb/trunk/packages/Python/lldbsuite/test/python_api/sbvalue_const_addrof/main.cpp
  lldb/trunk/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp


Index: 
lldb/trunk/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
===
--- 
lldb/trunk/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
+++ 
lldb/trunk/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
@@ -616,6 +616,10 @@
   if (log)
 log->PutCString("ScriptInterpreterPythonImpl::LeaveSession()");
 
+  // Unset the LLDB global variables.
+  PyRun_SimpleString("lldb.debugger = None; lldb.target = None; lldb.process "
+ "= None; lldb.thread = None; lldb.frame = None");
+
   // checking that we have a valid thread state - since we use our own
   // threading and locking in some (rare) cases during cleanup Python may end
   // up believing we have no thread state and PyImport_AddModule will crash if
@@ -2687,12 +2691,12 @@
 StreamString command_stream;
 
 // Before executing Python code, lock the GIL.
-Locker py_lock(
-this,
-Locker::AcquireLock | (init_session ? Locker::InitSession : 0) |
-(init_session ? Locker::InitGlobals : 0) | Locker::NoSTDIN,
-Locker::FreeAcquiredLock |
-(init_session ? Locker::TearDownSession : 0));
+Locker py_lock(this,
+   Locker::AcquireLock |
+   (init_session ? Locker::InitSession : 0) |
+   Locker::NoSTDIN,
+   Locker::FreeAcquiredLock |
+   (init_session ? Locker::TearDownSession : 0));
 namespace fs = llvm::sys::fs;
 fs::file_status st;
 std::error_code ec = status(target_file.GetPath(), st);
Index: lldb/trunk/lit/Commands/command-script-import.test
===
--- lldb/trunk/lit/Commands/command-script-import.test
+++ lldb/trunk/lit/Commands/command-script-import.test
@@ -3,6 +3,10 @@
 # RUN: echo 'command script import %S/Inputs/frame.py' >> %t.in
 
 # RUN: %clang -g -O0 %S/Inputs/main.c -o %t.out
-# RUN: %lldb -b -s %t.in %t.out | FileCheck %s
+# RUN: %lldb -b -s %t.in -o 'script print("script: {}").format(lldb.frame)' 
%t.out | FileCheck %s
 
-# CHECK: frame #0
+# Make sure that we don't have access to lldb.frame from the Python script.
+# CHECK: frame:py: None
+
+# Make sure that we do have access to lldb.frame from the script command.
+# CHECK: script: frame #0
Index: lldb/trunk/lit/Commands/Inputs/frame.py
===
--- lldb/trunk/lit/Commands/Inputs/frame.py
+++ lldb/trunk/lit/Commands/Inputs/frame.py
@@ -1,2 +1,2 @@
 import lldb
-print(lldb.frame)
+print("frame:py: {}".format(lldb.frame))
Index: 
lldb/trunk/packages/Python/lldbsuite/test/python_api/sbvalue_const_addrof/main.cpp
===
--- 
lldb/trunk/packages/Python/lldbsuite/test/python_api/sbvalue_const_addrof/main.cpp
+++ 
lldb/trunk/packages/Python/lldbsuite/test/python_api/sbvalue_const_addrof/main.cpp
@@ -28,7 +28,7 @@
 int main (int argc, char const *argv[], char const *envp[])
 {
 printf ("g_thread_list is %p\n", g_thread_list_ptr);
-return 0; //% v = lldb.target.FindFirstGlobalVariable('g_thread_list_ptr')
+return 0; //% v = 
self.dbg.GetSelectedTarget().FindFirstGlobalVariable('g_thread_list_ptr')
 //% v_gla = v.GetChildMemberWithName('regs').GetLoadAddress()
 //% v_aof = 
v.GetChildMemberWithName('regs').AddressOf().GetValueAsUnsigned(lldb.LLDB_INVALID_ADDRESS)
 //% expr = '(%s)0x%x' % (v.GetType().GetName(), v.GetValueAsUnsigned(0))
Index: 
lldb/trunk/packages/Python/lldbsuite/test/commands/frame/recognizer/recognizer.py
===
--- 
lldb/trunk/packages/Python/lldbsuite/test/commands/frame/recognizer/recognizer.py
+++ 
lldb/trunk/packages/Python/lldbsuite/test/commands/frame/recognizer/recognizer.py
@@ -7,12 +7,12 @@
 if frame.name == "foo":
 arg1 = frame.EvaluateExpression("$arg1").signed
 arg2 = frame.EvaluateExpression("$arg2").signed
-val1 = lldb.target.CreateValueFromExpre

[Lldb-commits] [lldb] r372193 - TestFoundationDisassembly.py is not dependent on debug information.

2019-09-17 Thread Jim Ingham via lldb-commits 
Author: jingham
Date: Tue Sep 17 17:40:49 2019
New Revision: 372193

URL: http://llvm.org/viewvc/llvm-project?rev=372193&view=rev
Log:
TestFoundationDisassembly.py is not dependent on debug information.

This test is about disassembling symbols in a framework without debug 
information.
So we don't need to run it once per debug info flavor.

Modified:

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

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/lang/objc/foundation/TestFoundationDisassembly.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/lang/objc/foundation/TestFoundationDisassembly.py?rev=372193&r1=372192&r2=372193&view=diff
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/lang/objc/foundation/TestFoundationDisassembly.py
 (original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/lang/objc/foundation/TestFoundationDisassembly.py
 Tue Sep 17 17:40:49 2019
@@ -15,6 +15,8 @@ class FoundationDisassembleTestCase(Test
 
 mydir = TestBase.compute_mydir(__file__)
 
+NO_DEBUG_INFO_TESTCASE = True
+
 def test_foundation_disasm(self):
 """Do 'disassemble -n func' on each and every 'Code' symbol entry from 
the Foundation.framework."""
 self.build()


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

[Lldb-commits] [PATCH] D67641: Cache PYTHON_EXECUTABLE for windows

2019-09-17 Thread Jonas Devlieghere via Phabricator via lldb-commits 
JDevlieghere accepted this revision.
JDevlieghere added a comment.

Hmm, that's unfortunately but I guess it makes sense. Let's remove the 
`mark_as_advanced` as it doesn't really serve a purpose anymore. Apologies 
about the churn!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67641



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

[Lldb-commits] [PATCH] D67583: Fix swig python package path

2019-09-17 Thread Hal Gentz via Phabricator via lldb-commits 
ZeGentzy reopened this revision.
ZeGentzy added a comment.
This revision is now accepted and ready to land.

Hello folks,

These changes break running `ninja install` when building with `-D 
LLVM_LIBDIR_SUFFIX=32`.

  [...]
  -- Up-to-date: 
/build/llvm-git-gentz/pkg/lib32-llvm-git-gentz/opt/llvm32/include
  -- Up-to-date: 
/build/llvm-git-gentz/pkg/lib32-llvm-git-gentz/opt/llvm32/include/lldb
  -- Up-to-date: 
/build/llvm-git-gentz/pkg/lib32-llvm-git-gentz/opt/llvm32/include/lldb/Host
  -- Installing: 
/build/llvm-git-gentz/pkg/lib32-llvm-git-gentz/opt/llvm32/include/lldb/Host/Config.h
  CMake Error at tools/lldb/scripts/cmake_install.cmake:41 (file):
file INSTALL cannot find
"/build/llvm-git-gentz/src/_build32_final/./lib/python3.7".
  Call Stack (most recent call first):
tools/lldb/cmake_install.cmake:50 (include)
tools/cmake_install.cmake:50 (include)
cmake_install.cmake:68 (include)
  
  
  FAILED: CMakeFiles/install.util 
  cd /build/llvm-git-gentz/src/_build32_final && /usr/bin/cmake -P 
cmake_install.cmake
  ninja: build stopped: subcommand failed.

After some investigation, I found that there is no 
`/build/llvm-git-gentz/src/_build32_final/./lib/python3.7` but there is an 
`/build/llvm-git-gentz/src/_build32_final/./lib32/python3.7`.

I've temporary solved this problem by applying the following patch:

  diff --git a/lldb/scripts/CMakeLists.txt b/lldb/scripts/CMakeLists.txt
  index 9de96ef5565..7d346deee7f 100644
  --- a/lldb/scripts/CMakeLists.txt
  +++ b/lldb/scripts/CMakeLists.txt
  @@ -47,7 +47,7 @@ if(NOT LLDB_BUILD_FRAMEWORK)
 if(CMAKE_HOST_SYSTEM_NAME MATCHES "Windows")
   set(swig_python_subdir Lib/site-packages)
 else()
  -set(swig_python_subdir 
lib/python${PYTHON_VERSION_MAJOR}.${PYTHON_VERSION_MINOR})
  +set(swig_python_subdir 
lib${LLVM_LIBDIR_SUFFIX}/python${PYTHON_VERSION_MAJOR}.${PYTHON_VERSION_MINOR})
 endif()
   
 set(SWIG_PYTHON_DIR 
${CMAKE_BINARY_DIR}/${CMAKE_CFG_INTDIR}/${swig_python_subdir})

I believe solving this problem correctly would also involve updating 
https://github.com/python/cpython/blob/3.8/Lib/distutils/sysconfig.py#L150 to 
account for `${LLVM_LIBDIR_SUFFIX}`, however, I've never having used the script 
before and am unfamiliar with it's purpose.

@hhb Could you please revisit this revision so that it doesn't break builds 
with a modified `LLVM_LIBDIR_SUFFIX` and revert this revision until then?


Repository:
  rL LLVM

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

https://reviews.llvm.org/D67583



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

[Lldb-commits] [PATCH] D67641: Cache PYTHON_EXECUTABLE for windows

2019-09-17 Thread Haibo Huang via Phabricator via lldb-commits 
hhb updated this revision to Diff 220594.
hhb added a comment.

Fix comment


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67641

Files:
  lldb/cmake/modules/LLDBConfig.cmake


Index: lldb/cmake/modules/LLDBConfig.cmake
===
--- lldb/cmake/modules/LLDBConfig.cmake
+++ lldb/cmake/modules/LLDBConfig.cmake
@@ -250,10 +250,10 @@
   endif()
 
   # Set the same variables as FindPythonInterp and FindPythonLibs.
-  set(PYTHON_EXECUTABLE "${PYTHON_EXECUTABLE}"  PARENT_SCOPE)
-  set(PYTHON_LIBRARY"${PYTHON_LIBRARY}" PARENT_SCOPE)
-  set(PYTHON_DLL"${PYTHON_DLL}" PARENT_SCOPE)
-  set(PYTHON_INCLUDE_DIR"${PYTHON_INCLUDE_DIR}" PARENT_SCOPE)
+  set(PYTHON_EXECUTABLE "${PYTHON_EXECUTABLE}"  CACHE PATH "")
+  set(PYTHON_LIBRARY"${PYTHON_LIBRARY}" CACHE PATH "")
+  set(PYTHON_DLL"${PYTHON_DLL}" CACHE PATH "")
+  set(PYTHON_INCLUDE_DIR"${PYTHON_INCLUDE_DIR}" CACHE PATH "")
   set(PYTHONLIBS_VERSION_STRING "${PYTHONLIBS_VERSION_STRING}"  PARENT_SCOPE)
   set(PYTHON_VERSION_STRING "${PYTHON_VERSION_STRING}"  PARENT_SCOPE)
   set(PYTHON_VERSION_MAJOR  "${PYTHON_VERSION_MAJOR}"   PARENT_SCOPE)


Index: lldb/cmake/modules/LLDBConfig.cmake
===
--- lldb/cmake/modules/LLDBConfig.cmake
+++ lldb/cmake/modules/LLDBConfig.cmake
@@ -250,10 +250,10 @@
   endif()
 
   # Set the same variables as FindPythonInterp and FindPythonLibs.
-  set(PYTHON_EXECUTABLE "${PYTHON_EXECUTABLE}"  PARENT_SCOPE)
-  set(PYTHON_LIBRARY"${PYTHON_LIBRARY}" PARENT_SCOPE)
-  set(PYTHON_DLL"${PYTHON_DLL}" PARENT_SCOPE)
-  set(PYTHON_INCLUDE_DIR"${PYTHON_INCLUDE_DIR}" PARENT_SCOPE)
+  set(PYTHON_EXECUTABLE "${PYTHON_EXECUTABLE}"  CACHE PATH "")
+  set(PYTHON_LIBRARY"${PYTHON_LIBRARY}" CACHE PATH "")
+  set(PYTHON_DLL"${PYTHON_DLL}" CACHE PATH "")
+  set(PYTHON_INCLUDE_DIR"${PYTHON_INCLUDE_DIR}" CACHE PATH "")
   set(PYTHONLIBS_VERSION_STRING "${PYTHONLIBS_VERSION_STRING}"  PARENT_SCOPE)
   set(PYTHON_VERSION_STRING "${PYTHON_VERSION_STRING}"  PARENT_SCOPE)
   set(PYTHON_VERSION_MAJOR  "${PYTHON_VERSION_MAJOR}"   PARENT_SCOPE)
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D67641: Cache PYTHON_EXECUTABLE for windows

2019-09-17 Thread Haibo Huang via Phabricator via lldb-commits 
This revision was automatically updated to reflect the committed changes.
Closed by commit rL372194: Cache PYTHON_EXECUTABLE for windows (authored by 
hhb, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D67641?vs=220594&id=220596#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D67641

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


Index: lldb/trunk/cmake/modules/LLDBConfig.cmake
===
--- lldb/trunk/cmake/modules/LLDBConfig.cmake
+++ lldb/trunk/cmake/modules/LLDBConfig.cmake
@@ -250,10 +250,10 @@
   endif()
 
   # Set the same variables as FindPythonInterp and FindPythonLibs.
-  set(PYTHON_EXECUTABLE "${PYTHON_EXECUTABLE}"  PARENT_SCOPE)
-  set(PYTHON_LIBRARY"${PYTHON_LIBRARY}" PARENT_SCOPE)
-  set(PYTHON_DLL"${PYTHON_DLL}" PARENT_SCOPE)
-  set(PYTHON_INCLUDE_DIR"${PYTHON_INCLUDE_DIR}" PARENT_SCOPE)
+  set(PYTHON_EXECUTABLE "${PYTHON_EXECUTABLE}"  CACHE PATH "")
+  set(PYTHON_LIBRARY"${PYTHON_LIBRARY}" CACHE PATH "")
+  set(PYTHON_DLL"${PYTHON_DLL}" CACHE PATH "")
+  set(PYTHON_INCLUDE_DIR"${PYTHON_INCLUDE_DIR}" CACHE PATH "")
   set(PYTHONLIBS_VERSION_STRING "${PYTHONLIBS_VERSION_STRING}"  PARENT_SCOPE)
   set(PYTHON_VERSION_STRING "${PYTHON_VERSION_STRING}"  PARENT_SCOPE)
   set(PYTHON_VERSION_MAJOR  "${PYTHON_VERSION_MAJOR}"   PARENT_SCOPE)


Index: lldb/trunk/cmake/modules/LLDBConfig.cmake
===
--- lldb/trunk/cmake/modules/LLDBConfig.cmake
+++ lldb/trunk/cmake/modules/LLDBConfig.cmake
@@ -250,10 +250,10 @@
   endif()
 
   # Set the same variables as FindPythonInterp and FindPythonLibs.
-  set(PYTHON_EXECUTABLE "${PYTHON_EXECUTABLE}"  PARENT_SCOPE)
-  set(PYTHON_LIBRARY"${PYTHON_LIBRARY}" PARENT_SCOPE)
-  set(PYTHON_DLL"${PYTHON_DLL}" PARENT_SCOPE)
-  set(PYTHON_INCLUDE_DIR"${PYTHON_INCLUDE_DIR}" PARENT_SCOPE)
+  set(PYTHON_EXECUTABLE "${PYTHON_EXECUTABLE}"  CACHE PATH "")
+  set(PYTHON_LIBRARY"${PYTHON_LIBRARY}" CACHE PATH "")
+  set(PYTHON_DLL"${PYTHON_DLL}" CACHE PATH "")
+  set(PYTHON_INCLUDE_DIR"${PYTHON_INCLUDE_DIR}" CACHE PATH "")
   set(PYTHONLIBS_VERSION_STRING "${PYTHONLIBS_VERSION_STRING}"  PARENT_SCOPE)
   set(PYTHON_VERSION_STRING "${PYTHON_VERSION_STRING}"  PARENT_SCOPE)
   set(PYTHON_VERSION_MAJOR  "${PYTHON_VERSION_MAJOR}"   PARENT_SCOPE)
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] r372196 - Clean up this test.

2019-09-17 Thread Jim Ingham via lldb-commits 
Author: jingham
Date: Tue Sep 17 18:53:52 2019
New Revision: 372196

URL: http://llvm.org/viewvc/llvm-project?rev=372196&view=rev
Log:
Clean up this test.

I don't know what the intent of parts of this test were.  We set a
bunch of breakpoints and ran from one to the other, doing "self.runCmd("thread 
backtrace")"
then continuing to the next one.  We didn't actually verify the contents of the 
backtrace,
nor that we hit the breakpoints we set in any particular order.  The only 
actual test was
to run sel_getName at two of these stops.

So I reduced the test to just stopping at the places where we were actually 
going to run
an expression, and tested the expression.

Modified:

lldb/trunk/packages/Python/lldbsuite/test/lang/objc/foundation/TestObjCMethods2.py

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/lang/objc/foundation/TestObjCMethods2.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/lang/objc/foundation/TestObjCMethods2.py?rev=372196&r1=372195&r2=372196&view=diff
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/lang/objc/foundation/TestObjCMethods2.py
 (original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/lang/objc/foundation/TestObjCMethods2.py
 Tue Sep 17 18:53:52 2019
@@ -16,61 +16,26 @@ class FoundationTestCase2(TestBase):
 
 mydir = TestBase.compute_mydir(__file__)
 
+NO_DEBUG_INFO_TESTCASE = True
+
 def test_expr_commands(self):
 """More expression commands for objective-c."""
 self.build()
-exe = self.getBuildArtifact("a.out")
-self.runCmd("file " + exe, CURRENT_EXECUTABLE_SET)
-
-lines = []
-lines.append(
-line_number(
-'main.m',
-'// Break here for selector: tests'))
-lines.append(
-line_number(
-'main.m',
-'// Break here for NSArray tests'))
-lines.append(
-line_number(
-'main.m',
-'// Break here for NSString tests'))
-lines.append(
-line_number(
-'main.m',
-'// Break here for description test'))
-lines.append(
-line_number(
-'main.m',
-'// Set break point at this line'))
-
-# Create a bunch of breakpoints.
-for line in lines:
-lldbutil.run_break_set_by_file_and_line(
-self, "main.m", line, num_expected_locations=1, loc_exact=True)
-
-self.runCmd("run", RUN_SUCCEEDED)
+main_spec = lldb.SBFileSpec("main.m")
 
+(target, process, thread, bp) = lldbutil.run_to_source_breakpoint(
+self, "Break here for selector: tests", main_spec)
+
 # Test_Selector:
-self.runCmd("thread backtrace")
 self.expect("expression (char *)sel_getName(sel)",
 substrs=["(char *)",
  "length"])
 
-self.runCmd("process continue")
-
-# Test_NSArray:
-self.runCmd("thread backtrace")
-self.runCmd("process continue")
-
-# Test_NSString:
-self.runCmd("thread backtrace")
-self.runCmd("process continue")
-
-# Test_MyString:
-self.runCmd("thread backtrace")
+desc_bkpt = target.BreakpointCreateBySourceRegex("Break here for 
description test",
+  main_spec)
+self.assertEqual(desc_bkpt.GetNumLocations(), 1, "description 
breakpoint has a location")
+lldbutil.continue_to_breakpoint(process, desc_bkpt)
+
 self.expect("expression (char *)sel_getName(_cmd)",
 substrs=["(char *)",
  "description"])
-
-self.runCmd("process continue")


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