[Lldb-commits] [PATCH] D61687: Update Python tests for lldb-server on Windows

[Pavel Labath via Phabricator via lldb-commits]

labath added inline comments.
Herald added a subscriber: dexonsmith.



Comment at: 
packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemoteKill.py:17-23
+reg_expr = r"^\$X[0-9a-fA-F]+([^#]*)#[0-9A-Fa-f]{2}"
+triple = self.dbg.GetSelectedPlatform().GetTriple()
+
+# No signal support on Windwos. Only W* response is sent.
+if re.match(".*-.*-windows", triple):
+reg_expr = r"^\$W[0-9a-fA-F]+([^#]*)#[0-9A-Fa-f]{2}"
+

If I understand correctly, the regexes differ only in the first letter. If 
that's the case, then you could just factor out the rest of the regex and just 
compute the letter differently:
```
stop_type = 'W' if windows else 'X'
reg_expr = r"^\${}...".format(stop_type)
```



Comment at: 
packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemoteModuleInfo.py:24-27
+# Replace path separators in the json string either with "" or "/" 
on Windows.
+triple = self.dbg.GetSelectedPlatform().GetTriple()
+if re.match(".*-.*-windows", triple):
+module_path = module_path.replace(os.path.sep, '/')

It sounds like you could just unconditionally replace all backslashes with 
double-backslashes here. That would result in us also correctly handling posix 
paths that happen to contain a backslash.



Comment at: 
packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemoteProcessInfo.py:178-191
 @skipUnlessPlatform(["linux"])
 @llgs_test
 def test_qProcessInfo_contains_triple_llgs_linux(self):
 self.init_llgs_test()
 self.build()
 self.qProcessInfo_contains_keys(set(['triple']))
 

I'm not sure why the original test was made linux-specific, but I think you can 
just drop the os name from the test and have a single test which checks for 
both the presence of `parent-pid` and `triple`. No `@skipUnless` needed as all 
platforms that currently have a working lldb-server should support these fields.



Comment at: 
packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemoteThreadsInStopReply.py:208-212
+# In current implementation of llgs on Windows, as a response to '\x03' 
packet, the debugger
+# of the native process will trigger a call to DebugBreakProcess that will 
create a new thread
+# to handle the exception debug event. So one more stop thread will be 
notified to the
+# delegate, e.g. llgs.  So tests below to assert the stop threads number 
will all fail.
+@expectedFailureAll(oslist=["windows"])

Is this something that we consider to be a bug, or is it just how debugging is 
supposed to work on windows? If it's a bug then fine, but if not then we might 
consider adjusting the expectations in the test (or just skipping it).



Comment at: 
packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemote_qThreadStopInfo.py:146-153
 # All but one thread should report no stop reason.
-self.assertEqual(no_stop_reason_count, thread_count - 1)
+triple = self.dbg.GetSelectedPlatform().GetTriple()
+
+# Consider one more thread created by calling DebugBreakProcess.
+if re.match(".*-.*-windows", triple):
+self.assertGreaterEqual(no_stop_reason_count, thread_count - 1)
+else:

I think this assertion should just be deleted. If the assertion below (that one 
thread has a stop reason) is true, then it trivially true that the rest of the 
threads don't have one. Whether or not a platforms spawns an extra thread does 
not seem to be relevant for this test.



Comment at: 
packages/Python/lldbsuite/test/tools/lldb-server/inferior-crash/TestGdbRemoteAbort.py:40
 
+@skipIfWindows # For now the signo in T* packet is always 0.
 @llgs_test

Do you have any plans for changing this? Given that windows does not support 
signals, maybe it should stay 0...


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D61687



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

[Lldb-commits] [PATCH] D61686: Enable lldb-server on Windows

[Pavel Labath via Phabricator via lldb-commits]

labath added inline comments.



Comment at: include/lldb/Host/windows/PosixApi.h:106-109
+inline pid_t waitpid(pid_t pid, int *status, int options) {
+  // To be implemented.
+  return pid_t(-1);
+}

As discussed in the review where this was forked from, we shouldn't be mocking 
posix apis. Instead we should provide platform-independent abstractions that 
each platform can implement in it's own way. Waitpid is right now used in only 
one place. Implementing it here (even just as a stub) just encourages others to 
add more uses of it.

Given that (I think) you don't care about the "server" mode of lldb-platform at 
the moment, and the fact that the piece of code calling this is already broken 
because the use of fork, I think that for now we should just #ifdef-out the 
block of code calling fork and waitpid (it's already structured in a way that's 
easy to #ifdef. This would enable you to even provide a friendly error message 
explaining that the requested feature is not available.



Comment at: 
source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerCommon.cpp:1188-1198
+#if defined(_WIN32)
+  response.Printf("pid:%" PRIx64 ";parent-pid:%" PRIx64 ";",
+  proc_info.GetProcessID(), proc_info.GetParentProcessID());
+#else
   response.Printf("pid:%" PRIx64 ";parent-pid:%" PRIx64
   
";real-uid:%x;real-gid:%x;effective-uid:%x;effective-gid:%x;",
   proc_info.GetProcessID(), proc_info.GetParentProcessID(),

ProcessInstanceInfo already has the ability to say whether some fields are 
present/valid or not. So I think you should just replace this #ifdef with 
something like:
```
if (proc_info.UserIDIsValid())
  response.Printf(";real-uid:%x", proc_info.GetUserID()));
if(proc_info.GroupIDIsValid())
  ...
```



Comment at: tools/lldb-server/lldb-platform.cpp:72
 // Watch for signals
 static void signal_handler(int signo) {
+#if !defined(_WIN32)

It looks like this function will be unused after you disable the `signal` line 
below, so you might as well ifdef-out the entire function instead of just its 
body.


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

https://reviews.llvm.org/D61686



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

[Lldb-commits] [PATCH] D60153: Re-enable most lldb-vscode tests on Linux.

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

In D60153#1495725 , @stella.stamenova 
wrote:

> A couple of the tests from TestVSCode_attach.py (test_by_pid and 
> test_by_name) are failing for us on Ubuntu because they are failing to 
> attach: `AssertionError: False is not True : attach failed (Operation not 
> permitted)`. It looks like attaching by pid or by name requires elevation - 
> if I rerun the same tests with sudo, they pass reliably. How did you run the 
> tests when they passed for you?
>
> Incidentally, AFAIK there is no Ubuntu lldb bot...


You probably have YAMA enabled on those machines. In the rest of our attach 
tests, we have the inferiors disable YAMA so that the debugger can attach, but 
it looks like the vscode tests are not making use of that feature. The fix 
should be as simple as adding `lldb_enable_attach()` at the start of the 
inferior main function.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D60153



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

[Lldb-commits] [PATCH] D61713: [lldb] build.py: fix behavior when passing --compiler=/path/to/compiler

[Pavel Labath via Phabricator via lldb-commits]

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

Sounds reasonable.


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D61713



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

[Lldb-commits] [PATCH] D61713: [lldb] build.py: fix behavior when passing --compiler=/path/to/compiler

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

BTW, there's some existing tests for build.py in `lit/BuildScript`. Could you 
check if it's feasible to make an analogous test for the fix you're making here?


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D61713



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

[Lldb-commits] [PATCH] D61611: [JITLoaderGDB] Set eTypeJIT for objects read from JIT descriptors

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

Thanks for adding the test. It looks like it was much easier than I feared. I 
do wonder if the test couldn't be made to run on more platforms. It sounds like 
it is generic enough for that, and given that this is our first and only jit 
test, it would be great if that were the case.




Comment at: lldb/lit/Breakpoint/jitbp_elf.test:1
+# REQUIRES: target-x86_64, system-linux, native
+

sgraenitz wrote:
> The test only works with ELF on Linux. Is the `REQUIRES` sufficient?
Yes, but what is the reason for that? It looks like the test is generic enough 
that it should run on any system where lli is able to jit code. In particular 
I'd expect this to also work on macOS if you set `plugin-jit-loader.gdb.enable` 
to `on`.



Comment at: lldb/lit/Breakpoint/jitbp_elf.test:3
+
+# RUN: %clang -g -S -emit-llvm -o %t.ll %p/Inputs/jitbp.cpp
+# RUN: %lldb -b -o 'b jitbp' -o 'run -jit-kind=mcjit %t.ll' lli | FileCheck %s

sgraenitz wrote:
> With these args, clang shouldn't optimize away `jitbp()`
Is that a question? If it is I'm pretty sure the answer is "it shouldn't", 
because a lot of our tests depend on -O0 not doing anything funny.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D61611



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

[Lldb-commits] [PATCH] D61732: FuncUnwinders: Add a new "SymbolFile" unwind plan

[Pavel Labath via Phabricator via lldb-commits]

labath created this revision.
labath added reviewers: jasonmolenda, clayborg.

some unwind formats are specific to a single symbol file and so it does
not make sense for their parsing code live in the general Symbol library
(as is the case with eh_frame for instance). This is the case for the
unwind information in breakpad files, but the same will probably be true
for PDB unwind info (once we are able to parse that).

This patch adds the ability to fetch an unwind plan provided by a symbol
file plugin, as discussed in the RFC at
http://lists.llvm.org/pipermail/lldb-dev/2019-February/014703.html.
I've kept the set of changes to a minimum, as there is no way to test
them until we have a symbol file which implements this API -- that is
comming in a follow-up patch, which will also implicitly test this
change.

The interesting part here is the introduction of the
"RegisterInfoResolver" interface. The reason for this is that breakpad
needs to be able to resolve register names (which are present as strings
in the file) into register enums so that it can construct the unwind
plan. This is normally done via the RegisterContext class, handing this
over to the SymbolFile plugin would mean that it has full access to the
debugged process, which is not something we want it to have. So instead,
I create a facade, which only provides the ability to query register
names, and hide the RegisterContext behind the facade.

Also note that this only adds the ability to dump the unwind plan
created by the symbol file plugin -- the plan is not used for unwinding
yet -- this will be added in a third patch, which will add additional
tests which makes sure the unwinding works as a whole.


https://reviews.llvm.org/D61732

Files:
  include/lldb/Symbol/FuncUnwinders.h
  include/lldb/Symbol/SymbolFile.h
  include/lldb/Symbol/UnwindTable.h
  source/Commands/CommandObjectTarget.cpp
  source/Symbol/FuncUnwinders.cpp
  source/Symbol/SymbolFile.cpp
  source/Symbol/UnwindTable.cpp

Index: source/Symbol/UnwindTable.cpp
===
--- source/Symbol/UnwindTable.cpp
+++ source/Symbol/UnwindTable.cpp
@@ -18,6 +18,7 @@
 #include "lldb/Symbol/FuncUnwinders.h"
 #include "lldb/Symbol/ObjectFile.h"
 #include "lldb/Symbol/SymbolContext.h"
+#include "lldb/Symbol/SymbolVendor.h"
 
 // There is one UnwindTable object per ObjectFile. It contains a list of Unwind
 // objects -- one per function, populated lazily -- for the ObjectFile. Each
@@ -181,6 +182,12 @@
   return m_arm_unwind_up.get();
 }
 
+SymbolFile *UnwindTable::GetSymbolFile() {
+  if (SymbolVendor *vendor = m_module.GetSymbolVendor())
+return vendor->GetSymbolFile();
+  return nullptr;
+}
+
 ArchSpec UnwindTable::GetArchitecture() { return m_module.GetArchitecture(); }
 
 bool UnwindTable::GetAllowAssemblyEmulationUnwindPlans() {
Index: source/Symbol/SymbolFile.cpp
===
--- source/Symbol/SymbolFile.cpp
+++ source/Symbol/SymbolFile.cpp
@@ -168,3 +168,5 @@
  "Module is not locked");
 #endif
 }
+
+SymbolFile::RegisterInfoResolver::~RegisterInfoResolver() = default;
Index: source/Symbol/FuncUnwinders.cpp
===
--- source/Symbol/FuncUnwinders.cpp
+++ source/Symbol/FuncUnwinders.cpp
@@ -13,11 +13,13 @@
 #include "lldb/Symbol/CompactUnwindInfo.h"
 #include "lldb/Symbol/DWARFCallFrameInfo.h"
 #include "lldb/Symbol/ObjectFile.h"
+#include "lldb/Symbol/SymbolFile.h"
 #include "lldb/Symbol/UnwindPlan.h"
 #include "lldb/Symbol/UnwindTable.h"
 #include "lldb/Target/ABI.h"
 #include "lldb/Target/ExecutionContext.h"
 #include "lldb/Target/Process.h"
+#include "lldb/Target/RegisterContext.h"
 #include "lldb/Target/RegisterNumber.h"
 #include "lldb/Target/Target.h"
 #include "lldb/Target/Thread.h"
@@ -42,7 +44,8 @@
   m_tried_unwind_plan_eh_frame_augmented(false),
   m_tried_unwind_plan_debug_frame_augmented(false),
   m_tried_unwind_plan_compact_unwind(false),
-  m_tried_unwind_plan_arm_unwind(false), m_tried_unwind_fast(false),
+  m_tried_unwind_plan_arm_unwind(false),
+  m_tried_unwind_plan_symbol_file(false), m_tried_unwind_fast(false),
   m_tried_unwind_arch_default(false),
   m_tried_unwind_arch_default_at_func_entry(false),
   m_first_non_prologue_insn() {}
@@ -147,6 +150,38 @@
   return m_unwind_plan_arm_unwind_sp;
 }
 
+namespace {
+class RegisterContextToInfo: public SymbolFile::RegisterInfoResolver {
+public:
+  RegisterContextToInfo(RegisterContext &ctx) : m_ctx(ctx) {}
+
+  const RegisterInfo *ResolveName(llvm::StringRef name) const {
+return m_ctx.GetRegisterInfoByName(name);
+  }
+  const RegisterInfo *ResolveNumber(lldb::RegisterKind kind,
+uint32_t number) const {
+return m_ctx.GetRegisterInfo(kind, number);
+  }
+
+private:
+  RegisterContext &m_ctx;
+};
+} // namespace
+
+UnwindPlanSP FuncUnwinders::GetSymbolFileUnwindPlan(

[Lldb-commits] [PATCH] D61733: Breakpad: Generate unwind plans from STACK CFI records

[Pavel Labath via Phabricator via lldb-commits]

labath created this revision.
labath added reviewers: amccarth, clayborg, markmentovai.
Herald added a subscriber: aprantl.

This patch implements the GetUnwindPlan interface (added in the previous
patch) for SymbolFileBreakpad, and uses it to generate unwind plans from
STACK CFI records in breakpad files.

We first perform a light-weight parse of the breakpad in order to build
up a map of regions covered by the unwind info so that we can later jump
to the right record when we need to unwind a specific function.

The actual parsing is relatively straight-forward, as the STACK CFI records
are just another (text) form of the eh_frame unwind instructions, and
the same goes for lldb's UnwindPlans. The newly-introduced
PostfixExpression API is used to convert the breakpad postfix
expressions into DWARF. The generated dwarf expressions are stored in a
BumpPtrAllocator, as the UnwindPlan does not take ownership of the
expression data it references (usually this is static data in an object
file, so special ownership is needed).

At this moment the generated unwind plans aren't used in the actual
unwind machinery (only in the image show-unwind command), but that is
coming in a separate patch.


https://reviews.llvm.org/D61733

Files:
  lit/SymbolFile/Breakpad/Inputs/stack-cfi-parsing.dmp
  lit/SymbolFile/Breakpad/Inputs/stack-cfi-parsing.syms
  lit/SymbolFile/Breakpad/stack-cfi-parsing.test
  source/Plugins/SymbolFile/Breakpad/SymbolFileBreakpad.cpp
  source/Plugins/SymbolFile/Breakpad/SymbolFileBreakpad.h

Index: source/Plugins/SymbolFile/Breakpad/SymbolFileBreakpad.h
===
--- source/Plugins/SymbolFile/Breakpad/SymbolFileBreakpad.h
+++ source/Plugins/SymbolFile/Breakpad/SymbolFileBreakpad.h
@@ -13,6 +13,7 @@
 #include "lldb/Core/FileSpecList.h"
 #include "lldb/Symbol/LineTable.h"
 #include "lldb/Symbol/SymbolFile.h"
+#include "lldb/Symbol/UnwindPlan.h"
 
 namespace lldb_private {
 
@@ -133,6 +134,10 @@
 
   void AddSymbols(Symtab &symtab) override;
 
+  lldb::UnwindPlanSP
+  GetUnwindPlan(const Address &address,
+const RegisterInfoResolver &resolver) override;
+
   ConstString GetPluginName() override { return GetPluginNameStatic(); }
   uint32_t GetPluginVersion() override { return 1; }
 
@@ -144,6 +149,11 @@
   struct Bookmark {
 uint32_t section;
 size_t offset;
+
+friend bool operator<(const Bookmark &lhs, const Bookmark &rhs) {
+  return std::tie(lhs.section, lhs.offset) <
+ std::tie(rhs.section, rhs.offset);
+}
   };
 
   // At iterator class for simplifying algorithms reading data from the breakpad
@@ -177,8 +187,7 @@
   return *this;
 }
 friend bool operator<(const CompUnitData &lhs, const CompUnitData &rhs) {
-  return std::tie(lhs.bookmark.section, lhs.bookmark.offset) <
- std::tie(rhs.bookmark.section, rhs.bookmark.offset);
+  return lhs.bookmark < rhs.bookmark;
 }
 
 Bookmark bookmark;
@@ -192,11 +201,19 @@
   void ParseFileRecords();
   void ParseCUData();
   void ParseLineTableAndSupportFiles(CompileUnit &cu, CompUnitData &data);
+  void ParseUnwindData();
+  bool ParseUnwindRow(llvm::StringRef unwind_rules,
+  const RegisterInfoResolver &resolver,
+  UnwindPlan::Row &row);
 
   using CompUnitMap = RangeDataVector;
 
   llvm::Optional> m_files;
   llvm::Optional m_cu_data;
+
+  using UnwindMap = RangeDataVector;
+  llvm::Optional m_unwind_data;
+  llvm::BumpPtrAllocator m_allocator;
 };
 
 } // namespace breakpad
Index: source/Plugins/SymbolFile/Breakpad/SymbolFileBreakpad.cpp
===
--- source/Plugins/SymbolFile/Breakpad/SymbolFileBreakpad.cpp
+++ source/Plugins/SymbolFile/Breakpad/SymbolFileBreakpad.cpp
@@ -15,9 +15,11 @@
 #include "lldb/Host/FileSystem.h"
 #include "lldb/Symbol/CompileUnit.h"
 #include "lldb/Symbol/ObjectFile.h"
+#include "lldb/Symbol/PostfixExpression.h"
 #include "lldb/Symbol/SymbolVendor.h"
 #include "lldb/Symbol/TypeMap.h"
 #include "lldb/Utility/Log.h"
+#include "lldb/Utility/StreamString.h"
 #include "llvm/ADT/StringExtras.h"
 
 using namespace lldb;
@@ -370,6 +372,153 @@
   symtab.CalculateSymbolSizes();
 }
 
+static llvm::Optional>
+GetRule(llvm::StringRef &unwind_rules) {
+  // Unwind rules are of the form
+  //   register1: expression1 register2: expression2 ...
+  // We assume none of the tokens in expression end with a colon.
+
+  llvm::StringRef lhs;
+  std::tie(lhs, unwind_rules) = getToken(unwind_rules);
+  if (!lhs.consume_back(":"))
+return llvm::None;
+
+  // Seek forward to the next register: expression pair
+  llvm::StringRef::size_type pos = unwind_rules.find(": ");
+  if (pos == llvm::StringRef::npos) {
+// No pair found, this means the rest of the string is a single expression.
+llvm::StringRef rhs = unwind_rules;
+unwind_rules = llvm::StringRef();
+return std::make_pair(lhs, rhs);
+  }
+
+ 

[Lldb-commits] [PATCH] D61438: [ASTImporter] Use llvm::Expected and Error in the importer API

[Gabor Marton via Phabricator via lldb-commits]

martong marked 8 inline comments as done.
martong added inline comments.



Comment at: clang/lib/AST/ASTImporter.cpp:5039
+  if (!ToOrErr)
+// FIXME: return the error?
+consumeError(ToOrErr.takeError());

aprantl wrote:
> We don't typically commit FIXME's into LLVM code. Why not just deal with the 
> error properly from the start?
Ok, changed that to return with the error.



Comment at: lldb/source/Symbol/ClangASTImporter.cpp:68
+  return *ret_or_error;
+} else {
+  Log *log =

sgraenitz wrote:
> aprantl wrote:
> > The `else` is redundant.
> Here it's necessary for the scope of `ret_or_error`. That's a bit 
> unfortunate. Maybe invert the condition?
Ok, I have inverted the condition and this way the else  became redundant, so I 
removed it.



Comment at: lldb/source/Symbol/ClangASTImporter.cpp:139
+
+  llvm::consumeError(result.takeError());
+

aprantl wrote:
> Can you convert this to an early return instead?
Okay, I have added
```
  if (!delegate_sp)
return nullptr;
```
But we can't get rid of `consumeError` because otherwise the error object 
remains unchecked and will cause run-time assert.
`LLDB_LOG_ERROR` calls `consumeError` too plus logs the error msg, so I changed 
to use that.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D61438



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

[Lldb-commits] [PATCH] D61438: [ASTImporter] Use llvm::Expected and Error in the importer API

[Gabor Marton via Phabricator via lldb-commits]

martong updated this revision to Diff 198822.
martong marked 3 inline comments as done.
martong added a comment.

- Remove FIXME and return the error
- Use early return where possible and remove redundant else


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D61438

Files:
  clang/include/clang/AST/ASTImporter.h
  clang/lib/AST/ASTImporter.cpp
  clang/lib/AST/ExternalASTMerger.cpp
  clang/lib/CrossTU/CrossTranslationUnit.cpp
  clang/lib/Frontend/ASTMerge.cpp
  clang/unittests/AST/ASTImporterTest.cpp
  lldb/source/Plugins/ExpressionParser/Clang/ClangASTSource.cpp
  lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionDeclMap.cpp
  lldb/source/Symbol/ClangASTContext.cpp
  lldb/source/Symbol/ClangASTImporter.cpp
  lldb/source/Symbol/CxxModuleHandler.cpp

Index: lldb/source/Symbol/CxxModuleHandler.cpp
===
--- lldb/source/Symbol/CxxModuleHandler.cpp
+++ lldb/source/Symbol/CxxModuleHandler.cpp
@@ -9,6 +9,7 @@
 #include "lldb/Symbol/CxxModuleHandler.h"
 
 #include "lldb/Symbol/ClangASTContext.h"
+#include "lldb/Utility/Log.h"
 #include "clang/Sema/Lookup.h"
 #include "llvm/Support/Error.h"
 
@@ -214,13 +215,15 @@
   // Import the foreign template arguments.
   llvm::SmallVector imported_args;
 
+  Log *log = lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_EXPRESSIONS);
+
   // If this logic is changed, also update templateArgsAreSupported.
   for (const TemplateArgument &arg : foreign_args.asArray()) {
 switch (arg.getKind()) {
 case TemplateArgument::Type: {
-  llvm::Expected type = m_importer->Import_New(arg.getAsType());
+  llvm::Expected type = m_importer->Import(arg.getAsType());
   if (!type) {
-llvm::consumeError(type.takeError());
+LLDB_LOG_ERROR(log, type.takeError(), "Couldn't import type: {0}");
 return {};
   }
   imported_args.push_back(TemplateArgument(*type));
@@ -229,9 +232,9 @@
 case TemplateArgument::Integral: {
   llvm::APSInt integral = arg.getAsIntegral();
   llvm::Expected type =
-  m_importer->Import_New(arg.getIntegralType());
+  m_importer->Import(arg.getIntegralType());
   if (!type) {
-llvm::consumeError(type.takeError());
+LLDB_LOG_ERROR(log, type.takeError(), "Couldn't import type: {0}");
 return {};
   }
   imported_args.push_back(
Index: lldb/source/Symbol/ClangASTImporter.cpp
===
--- lldb/source/Symbol/ClangASTImporter.cpp
+++ lldb/source/Symbol/ClangASTImporter.cpp
@@ -62,10 +62,18 @@
 
   ASTImporterDelegate::CxxModuleScope std_scope(*delegate_sp, dst_ast);
 
-  if (delegate_sp)
-return delegate_sp->Import(type);
-
-  return QualType();
+  if (!delegate_sp)
+return QualType();
+
+  llvm::Expected ret_or_error = delegate_sp->Import(type);
+  if (!ret_or_error) {
+Log *log =
+  lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_EXPRESSIONS);
+LLDB_LOG_ERROR(log, ret_or_error.takeError(),
+"Couldn't import type: {0}");
+return QualType();
+  }
+  return *ret_or_error;
 }
 
 lldb::opaque_compiler_type_t
@@ -105,34 +113,33 @@
 
   ASTImporterDelegate::CxxModuleScope std_scope(*delegate_sp, dst_ast);
 
-  if (delegate_sp) {
-clang::Decl *result = delegate_sp->Import(decl);
-
-if (!result) {
-  Log *log(lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_EXPRESSIONS));
+  if (!delegate_sp)
+return nullptr;
 
-  if (log) {
-lldb::user_id_t user_id = LLDB_INVALID_UID;
-ClangASTMetadata *metadata = GetDeclMetadata(decl);
-if (metadata)
-  user_id = metadata->GetUserID();
-
-if (NamedDecl *named_decl = dyn_cast(decl))
-  log->Printf("  [ClangASTImporter] WARNING: Failed to import a %s "
-  "'%s', metadata 0x%" PRIx64,
-  decl->getDeclKindName(),
-  named_decl->getNameAsString().c_str(), user_id);
-else
-  log->Printf("  [ClangASTImporter] WARNING: Failed to import a %s, "
-  "metadata 0x%" PRIx64,
-  decl->getDeclKindName(), user_id);
-  }
+  llvm::Expected result = delegate_sp->Import(decl);
+  if (!result) {
+Log *log(lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_EXPRESSIONS));
+LLDB_LOG_ERROR(log, result.takeError(), "Couldn't import decl: {0}");
+if (log) {
+  lldb::user_id_t user_id = LLDB_INVALID_UID;
+  ClangASTMetadata *metadata = GetDeclMetadata(decl);
+  if (metadata)
+user_id = metadata->GetUserID();
+
+  if (NamedDecl *named_decl = dyn_cast(decl))
+log->Printf("  [ClangASTImporter] WARNING: Failed to import a %s "
+"'%s', metadata 0x%" PRIx64,
+decl->getDeclKindName(),
+named_decl->getNameAsString().c_str(), user_id);
+  els

[Lldb-commits] [PATCH] D61733: Breakpad: Generate unwind plans from STACK CFI records

[Greg Clayton via Phabricator via lldb-commits]

clayborg added inline comments.



Comment at: source/Plugins/SymbolFile/Breakpad/SymbolFileBreakpad.cpp:378
+  // Unwind rules are of the form
+  //   register1: expression1 register2: expression2 ...
+  // We assume none of the tokens in expression end with a colon.

This format seems a bit challenging to parse



Comment at: source/Plugins/SymbolFile/Breakpad/SymbolFileBreakpad.cpp:418
+  if (name == ".ra")
+return resolver.ResolveNumber(eRegisterKindGeneric, 
LLDB_REGNUM_GENERIC_PC);
+  return ResolveRegister(resolver, name);

LLDB_REGNUM_GENERIC_RA? Do we want the PC here or do we want the link register?



Comment at: source/Plugins/SymbolFile/Breakpad/SymbolFileBreakpad.cpp:491-492
+  llvm::Optional init_record = StackCFIRecord::parse(*It);
+  assert(init_record.hasValue());
+  assert(init_record->Size.hasValue());
+

will this code be ok if the assertions are compiled out?


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

https://reviews.llvm.org/D61733



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

[Lldb-commits] [PATCH] D61611: [JITLoaderGDB] Set eTypeJIT for objects read from JIT descriptors

[Stefan Gränitz via Phabricator via lldb-commits]

sgraenitz updated this revision to Diff 198823.
sgraenitz marked 2 inline comments as done.
sgraenitz added a comment.

Generalize lit test


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D61611

Files:
  lldb/lit/Breakpoint/Inputs/jitbp.cpp
  lldb/lit/Breakpoint/jitbp_elf.test
  lldb/lit/helper/toolchain.py
  lldb/source/Plugins/JITLoader/GDB/JITLoaderGDB.cpp
  lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp


Index: lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
===
--- lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
+++ lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
@@ -1865,7 +1865,7 @@
 return;
 
   m_sections_up = llvm::make_unique();
-  VMAddressProvider address_provider(CalculateType());
+  VMAddressProvider address_provider(GetType());
 
   size_t LoadID = 0;
   for (const auto &EnumPHdr : llvm::enumerate(ProgramHeaders())) {
Index: lldb/source/Plugins/JITLoader/GDB/JITLoaderGDB.cpp
===
--- lldb/source/Plugins/JITLoader/GDB/JITLoaderGDB.cpp
+++ lldb/source/Plugins/JITLoader/GDB/JITLoaderGDB.cpp
@@ -327,6 +327,10 @@
   FileSpec(jit_name), symbolfile_addr, symbolfile_size);
 
   if (module_sp && module_sp->GetObjectFile()) {
+// Object formats (like ELF) have no representation for a JIT type.
+// We will get it wrong, if we deduce it from the header.
+module_sp->GetObjectFile()->SetType(ObjectFile::eTypeJIT);
+
 // load the symbol table right away
 module_sp->GetObjectFile()->GetSymtab();
 
Index: lldb/lit/helper/toolchain.py
===
--- lldb/lit/helper/toolchain.py
+++ lldb/lit/helper/toolchain.py
@@ -134,6 +134,6 @@
 
 support_tools = ['yaml2obj', 'obj2yaml', 'llvm-pdbutil',
  'llvm-mc', 'llvm-readobj', 'llvm-objdump',
- 'llvm-objcopy']
+ 'llvm-objcopy', 'lli']
 additional_tool_dirs += [config.lldb_tools_dir, config.llvm_tools_dir]
 llvm_config.add_tool_substitutions(support_tools, additional_tool_dirs)
Index: lldb/lit/Breakpoint/jitbp_elf.test
===
--- /dev/null
+++ lldb/lit/Breakpoint/jitbp_elf.test
@@ -0,0 +1,11 @@
+# REQUIRES: target-x86_64, native
+
+# RUN: %clang -g -S -emit-llvm --target=x86_64-unknown-unknown-elf -o %t.ll 
%p/Inputs/jitbp.cpp
+# RUN: %lldb -b -o 'settings set plugin.jit-loader.gdb.enable on' -o 'b jitbp' 
-o 'run -jit-kind=mcjit %t.ll' lli | FileCheck %s
+
+# CHECK: Breakpoint 1: no locations (pending).
+# CHECK: (lldb) run -jit-kind=mcjit {{.*}}/jitbp_elf.test.tmp.ll
+# CHECK: 1 location added to breakpoint 1
+# CHECK: Process {{.*}} stopped
+# CHECK: JIT(0x{{.*}})`jitbp:
+# CHECK: Process {{.*}} launched: {{.*}}
Index: lldb/lit/Breakpoint/Inputs/jitbp.cpp
===
--- /dev/null
+++ lldb/lit/Breakpoint/Inputs/jitbp.cpp
@@ -0,0 +1,2 @@
+int jitbp() { return 0; }
+int main() { return jitbp(); }


Index: lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
===
--- lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
+++ lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
@@ -1865,7 +1865,7 @@
 return;
 
   m_sections_up = llvm::make_unique();
-  VMAddressProvider address_provider(CalculateType());
+  VMAddressProvider address_provider(GetType());
 
   size_t LoadID = 0;
   for (const auto &EnumPHdr : llvm::enumerate(ProgramHeaders())) {
Index: lldb/source/Plugins/JITLoader/GDB/JITLoaderGDB.cpp
===
--- lldb/source/Plugins/JITLoader/GDB/JITLoaderGDB.cpp
+++ lldb/source/Plugins/JITLoader/GDB/JITLoaderGDB.cpp
@@ -327,6 +327,10 @@
   FileSpec(jit_name), symbolfile_addr, symbolfile_size);
 
   if (module_sp && module_sp->GetObjectFile()) {
+// Object formats (like ELF) have no representation for a JIT type.
+// We will get it wrong, if we deduce it from the header.
+module_sp->GetObjectFile()->SetType(ObjectFile::eTypeJIT);
+
 // load the symbol table right away
 module_sp->GetObjectFile()->GetSymtab();
 
Index: lldb/lit/helper/toolchain.py
===
--- lldb/lit/helper/toolchain.py
+++ lldb/lit/helper/toolchain.py
@@ -134,6 +134,6 @@
 
 support_tools = ['yaml2obj', 'obj2yaml', 'llvm-pdbutil',
  'llvm-mc', 'llvm-readobj', 'llvm-objdump',
- 'llvm-objcopy']
+ 'llvm-objcopy', 'lli']
 additional_tool_dirs += [config.lldb_tools_dir, config.llvm_tools_dir]
 llvm_config.add_tool_substitutions(support_tools, additional_tool_dirs)
Index: lldb/lit/

[Lldb-commits] [PATCH] D61438: [ASTImporter] Use llvm::Expected and Error in the importer API

[Gabor Marton via Phabricator via lldb-commits]

martong updated this revision to Diff 198824.
martong added a comment.

- Remove remaining FIXMEs


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D61438

Files:
  clang/include/clang/AST/ASTImporter.h
  clang/lib/AST/ASTImporter.cpp
  clang/lib/AST/ExternalASTMerger.cpp
  clang/lib/CrossTU/CrossTranslationUnit.cpp
  clang/lib/Frontend/ASTMerge.cpp
  clang/unittests/AST/ASTImporterTest.cpp
  lldb/source/Plugins/ExpressionParser/Clang/ClangASTSource.cpp
  lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionDeclMap.cpp
  lldb/source/Symbol/ClangASTContext.cpp
  lldb/source/Symbol/ClangASTImporter.cpp
  lldb/source/Symbol/CxxModuleHandler.cpp

Index: lldb/source/Symbol/CxxModuleHandler.cpp
===
--- lldb/source/Symbol/CxxModuleHandler.cpp
+++ lldb/source/Symbol/CxxModuleHandler.cpp
@@ -9,6 +9,7 @@
 #include "lldb/Symbol/CxxModuleHandler.h"
 
 #include "lldb/Symbol/ClangASTContext.h"
+#include "lldb/Utility/Log.h"
 #include "clang/Sema/Lookup.h"
 #include "llvm/Support/Error.h"
 
@@ -214,13 +215,15 @@
   // Import the foreign template arguments.
   llvm::SmallVector imported_args;
 
+  Log *log = lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_EXPRESSIONS);
+
   // If this logic is changed, also update templateArgsAreSupported.
   for (const TemplateArgument &arg : foreign_args.asArray()) {
 switch (arg.getKind()) {
 case TemplateArgument::Type: {
-  llvm::Expected type = m_importer->Import_New(arg.getAsType());
+  llvm::Expected type = m_importer->Import(arg.getAsType());
   if (!type) {
-llvm::consumeError(type.takeError());
+LLDB_LOG_ERROR(log, type.takeError(), "Couldn't import type: {0}");
 return {};
   }
   imported_args.push_back(TemplateArgument(*type));
@@ -229,9 +232,9 @@
 case TemplateArgument::Integral: {
   llvm::APSInt integral = arg.getAsIntegral();
   llvm::Expected type =
-  m_importer->Import_New(arg.getIntegralType());
+  m_importer->Import(arg.getIntegralType());
   if (!type) {
-llvm::consumeError(type.takeError());
+LLDB_LOG_ERROR(log, type.takeError(), "Couldn't import type: {0}");
 return {};
   }
   imported_args.push_back(
Index: lldb/source/Symbol/ClangASTImporter.cpp
===
--- lldb/source/Symbol/ClangASTImporter.cpp
+++ lldb/source/Symbol/ClangASTImporter.cpp
@@ -62,10 +62,18 @@
 
   ASTImporterDelegate::CxxModuleScope std_scope(*delegate_sp, dst_ast);
 
-  if (delegate_sp)
-return delegate_sp->Import(type);
-
-  return QualType();
+  if (!delegate_sp)
+return QualType();
+
+  llvm::Expected ret_or_error = delegate_sp->Import(type);
+  if (!ret_or_error) {
+Log *log =
+  lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_EXPRESSIONS);
+LLDB_LOG_ERROR(log, ret_or_error.takeError(),
+"Couldn't import type: {0}");
+return QualType();
+  }
+  return *ret_or_error;
 }
 
 lldb::opaque_compiler_type_t
@@ -105,34 +113,33 @@
 
   ASTImporterDelegate::CxxModuleScope std_scope(*delegate_sp, dst_ast);
 
-  if (delegate_sp) {
-clang::Decl *result = delegate_sp->Import(decl);
-
-if (!result) {
-  Log *log(lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_EXPRESSIONS));
+  if (!delegate_sp)
+return nullptr;
 
-  if (log) {
-lldb::user_id_t user_id = LLDB_INVALID_UID;
-ClangASTMetadata *metadata = GetDeclMetadata(decl);
-if (metadata)
-  user_id = metadata->GetUserID();
-
-if (NamedDecl *named_decl = dyn_cast(decl))
-  log->Printf("  [ClangASTImporter] WARNING: Failed to import a %s "
-  "'%s', metadata 0x%" PRIx64,
-  decl->getDeclKindName(),
-  named_decl->getNameAsString().c_str(), user_id);
-else
-  log->Printf("  [ClangASTImporter] WARNING: Failed to import a %s, "
-  "metadata 0x%" PRIx64,
-  decl->getDeclKindName(), user_id);
-  }
+  llvm::Expected result = delegate_sp->Import(decl);
+  if (!result) {
+Log *log(lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_EXPRESSIONS));
+LLDB_LOG_ERROR(log, result.takeError(), "Couldn't import decl: {0}");
+if (log) {
+  lldb::user_id_t user_id = LLDB_INVALID_UID;
+  ClangASTMetadata *metadata = GetDeclMetadata(decl);
+  if (metadata)
+user_id = metadata->GetUserID();
+
+  if (NamedDecl *named_decl = dyn_cast(decl))
+log->Printf("  [ClangASTImporter] WARNING: Failed to import a %s "
+"'%s', metadata 0x%" PRIx64,
+decl->getDeclKindName(),
+named_decl->getNameAsString().c_str(), user_id);
+  else
+log->Printf("  [ClangASTImporter] WARNING: Failed to import a %s, "
+"metadata 0x

[Lldb-commits] [PATCH] D61732: FuncUnwinders: Add a new "SymbolFile" unwind plan

[Greg Clayton via Phabricator via lldb-commits]

clayborg added a comment.

Looks good except the inline comment about all the unwind plans we have now. 
Would love to simplify this so that EH frame, compact unwind, ARM unwind, 
breakpad unwind all come from the symbol file or object files. Also be nice to 
have a register resolver that works without having a process so we can dump 
unwind info without needing a process.




Comment at: include/lldb/Symbol/FuncUnwinders.h:123-124
 
   std::vector m_unwind_plan_compact_unwind;
   lldb::UnwindPlanSP m_unwind_plan_arm_unwind_sp;
+  lldb::UnwindPlanSP m_unwind_plan_symbol_file_sp;

Seems like the compact unwind should move into the ObjectFileMachO and ARM 
unwind should move into ObjectFileELF as part of this? We have so many unwind 
plans here, the logic is already too complex around the selection process. 
Seems like m_unwind_plan_compact_unwind, m_unwind_plan_arm_unwind_sp, and 
possibly even m_unwind_plan_eh_frame_augmented_sp and 
m_unwind_plan_debug_frame_augmented_sp should all be moved into the ObjectFile 
classes so they can be accessed by the symbol file. This will allow say 
ObjectFileMachO to determine which is the best to use for a given address, and 
also ObjectFileELF.


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

https://reviews.llvm.org/D61732



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

[Lldb-commits] [PATCH] D61611: [JITLoaderGDB] Set eTypeJIT for objects read from JIT descriptors

[Stefan Gränitz via Phabricator via lldb-commits]

sgraenitz marked 2 inline comments as done.
sgraenitz added a comment.

@stella.stamenova Can you have a look at the lit test please? It works on macOS 
and Linux, but I didn't test Windows. Should I add something like `# REQUIRES: 
nowindows` or is it fine like this?




Comment at: lldb/lit/Breakpoint/jitbp_elf.test:1
+# REQUIRES: target-x86_64, system-linux, native
+

labath wrote:
> sgraenitz wrote:
> > The test only works with ELF on Linux. Is the `REQUIRES` sufficient?
> Yes, but what is the reason for that? It looks like the test is generic 
> enough that it should run on any system where lli is able to jit code. In 
> particular I'd expect this to also work on macOS if you set 
> `plugin-jit-loader.gdb.enable` to `on`.
Indeed, since https://reviews.llvm.org/D57689 it does work on macOS with ELF.



Comment at: lldb/lit/Breakpoint/jitbp_elf.test:3
+
+# RUN: %clang -g -S -emit-llvm -o %t.ll %p/Inputs/jitbp.cpp
+# RUN: %lldb -b -o 'b jitbp' -o 'run -jit-kind=mcjit %t.ll' lli | FileCheck %s

labath wrote:
> sgraenitz wrote:
> > With these args, clang shouldn't optimize away `jitbp()`
> Is that a question? If it is I'm pretty sure the answer is "it shouldn't", 
> because a lot of our tests depend on -O0 not doing anything funny.
Yes, I didn't know whether `-g` is enough or I better pass something like `-O0` 
explicitly?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D61611



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

[Lldb-commits] [PATCH] D61423: MinidumpYAML: add support for the ThreadList stream

[James Henderson via Phabricator via lldb-commits]

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

LGTM, with the suggested fixes.




Comment at: test/tools/obj2yaml/basic-minidump.yaml:47-49
+  - Thread Id:   0x5C5D5E5F
+Priority Class:  0x60616263
+Environment Block: 0x6465666768696A6B

labath wrote:
> jhenderson wrote:
> > It would be nice if these were padded so that they all line up. Ditto in 
> > the Stack block below.
> The microsoft structure definition calls this field just "teb" (for Thread 
> Environment Block), but I've found that too opaque, so I expanded the acronym 
> (sans "thread", because it is obvious we are talking about threads here). I 
> could shorten this further to "environment" (the word "block" probably 
> doesn't add that much value) , or even to "teb" for consistency with 
> microsoft headers. Let me know what you think.
Environment Block is fine. I was actually referring to the number of spaces 
between the attribute name and value, i.e. I'd prefer this:

```
  - Thread Id: 0x5C5D5E5F
Priority Class:0x60616263
Environment Block: 0x6465666768696A6B
```



Comment at: test/tools/obj2yaml/basic-minidump.yaml:51
+Stack:   
+  Start of Memory Range: 0x6C6D6E6F70717273
+  Content: 7475767778797A7B

labath wrote:
> jhenderson wrote:
> > I don't have a concrete suggestion, but it might be nice to have a shorter 
> > field name than "Start of Memory Range", but that's less of a concern if 
> > that's the actual minidump field name.
> That's how the field is called in the official microsoft documentation 
> (https://docs.microsoft.com/en-us/windows/desktop/api/minidumpapiset/ns-minidumpapiset-minidump_memory_descriptor),
>  which is probably the closest thing to a "spec" for this thing. It's a bit 
> verbose, and probably "Address" would just suffice here, but otoh it's nice 
> for this to match the official name. 
Let's leave it as is, since it matches the Microsoft document.



Comment at: test/tools/obj2yaml/basic-minidump.yaml:105
+# CHECK-NEXT:   Start of Memory Range: 0x6C6D6E6F70717273
+# CHECK-NEXT:   Content: 7475767778797A7B
+# CHECK-NEXT: Context: 7C7D7E7F80818283

Similar comment here about whitespace. Make the values of attributes within a 
block line up.



Comment at: test/tools/obj2yaml/basic-minidump.yaml:106
+# CHECK-NEXT:   Content: 7475767778797A7B
+# CHECK-NEXT: Context: 7C7D7E7F80818283
 # CHECK-NEXT: ...

Move this to be above the Stack block for readability.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D61423



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

[Lldb-commits] [PATCH] D61611: [JITLoaderGDB] Set eTypeJIT for objects read from JIT descriptors

[Greg Clayton via Phabricator via lldb-commits]

clayborg accepted this revision.
clayborg added a comment.

lgtm.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D61611



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

[Lldb-commits] [PATCH] D61611: [JITLoaderGDB] Set eTypeJIT for objects read from JIT descriptors

[Pavel Labath via Phabricator via lldb-commits]

labath accepted this revision.
labath added a comment.

In D61611#1496580 , @sgraenitz wrote:

> @stella.stamenova Can you have a look at the lit test please? It works on 
> macOS and Linux, but I didn't test Windows. Should I add something like `# 
> REQUIRES: nowindows` or is it fine like this?


Maybe I'm pessimistic, but I'd guess that this will fail on windows because 
some of the features this needs is not implemented there (but I'm not sure 
which one). You can just add `XFAIL: system-windows` and then you'll get an 
email if the guess is wrong.




Comment at: lldb/lit/Breakpoint/jitbp_elf.test:1
+# REQUIRES: target-x86_64, system-linux, native
+

sgraenitz wrote:
> labath wrote:
> > sgraenitz wrote:
> > > The test only works with ELF on Linux. Is the `REQUIRES` sufficient?
> > Yes, but what is the reason for that? It looks like the test is generic 
> > enough that it should run on any system where lli is able to jit code. In 
> > particular I'd expect this to also work on macOS if you set 
> > `plugin-jit-loader.gdb.enable` to `on`.
> Indeed, since https://reviews.llvm.org/D57689 it does work on macOS with ELF.
Cool. I think you can also drop the `target-x86_64` part, as I don't see a 
reason why this shouldn't work on arm for instance (though we don't have any 
arm bots around to verify that). I am not sure why you're using the `--target` 
argument to clang -- I think you should be able to just drop that and make 
clang generate IR for the host. (the `native` feature ensures that "host" is 
the default target for clang).



Comment at: lldb/lit/Breakpoint/jitbp_elf.test:3
+
+# RUN: %clang -g -S -emit-llvm -o %t.ll %p/Inputs/jitbp.cpp
+# RUN: %lldb -b -o 'b jitbp' -o 'run -jit-kind=mcjit %t.ll' lli | FileCheck %s

sgraenitz wrote:
> labath wrote:
> > sgraenitz wrote:
> > > With these args, clang shouldn't optimize away `jitbp()`
> > Is that a question? If it is I'm pretty sure the answer is "it shouldn't", 
> > because a lot of our tests depend on -O0 not doing anything funny.
> Yes, I didn't know whether `-g` is enough or I better pass something like 
> `-O0` explicitly?
I'm pretty sure -O0 will always be the default opt level for clang (and -g as a 
matter of principle has no impact on codegen decisions like inlining).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D61611



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

[Lldb-commits] [PATCH] D61423: MinidumpYAML: add support for the ThreadList stream

[Pavel Labath via Phabricator via lldb-commits]

labath marked 6 inline comments as done.
labath added a comment.

Thanks for the review.




Comment at: test/tools/obj2yaml/basic-minidump.yaml:47-49
+  - Thread Id:   0x5C5D5E5F
+Priority Class:  0x60616263
+Environment Block: 0x6465666768696A6B

jhenderson wrote:
> labath wrote:
> > jhenderson wrote:
> > > It would be nice if these were padded so that they all line up. Ditto in 
> > > the Stack block below.
> > The microsoft structure definition calls this field just "teb" (for Thread 
> > Environment Block), but I've found that too opaque, so I expanded the 
> > acronym (sans "thread", because it is obvious we are talking about threads 
> > here). I could shorten this further to "environment" (the word "block" 
> > probably doesn't add that much value) , or even to "teb" for consistency 
> > with microsoft headers. Let me know what you think.
> Environment Block is fine. I was actually referring to the number of spaces 
> between the attribute name and value, i.e. I'd prefer this:
> 
> ```
>   - Thread Id: 0x5C5D5E5F
> Priority Class:0x60616263
> Environment Block: 0x6465666768696A6B
> ```
Ok, I see. I can do that manually here, but that won't prevent the actual 
output from obj2yaml from being misaligned (which is why i was trying to come 
up with a shorter name).


Repository:
  rL LLVM

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

https://reviews.llvm.org/D61423



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

[Lldb-commits] [PATCH] D61611: [JITLoaderGDB] Set eTypeJIT for objects read from JIT descriptors

[Paul Robinson via Phabricator via lldb-commits]

probinson added a comment.

In D61611#1496580 , @sgraenitz wrote:

> @stella.stamenova Can you have a look at the lit test please? It works on 
> macOS and Linux, but I didn't test Windows. Should I add something like `# 
> REQUIRES: nowindows` or is it fine like this?


Sorry for the drive-by... what is this `REQUIRES: nowindows`?  I don't see 
where lit generates this property.  I grepped all of llvm-project.git and I see 
it used in two tests, but not where it's produced. Which suggests that those 
tests don't actually run *anywhere*.
I think maybe you want `UNSUPPORTED: system-windows` instead?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D61611



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

[Lldb-commits] [PATCH] D61611: [JITLoaderGDB] Set eTypeJIT for objects read from JIT descriptors

[Stefan Gränitz via Phabricator via lldb-commits]

sgraenitz updated this revision to Diff 198834.
sgraenitz marked an inline comment as done.
sgraenitz added a comment.

1. XFAIL: system-windows


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D61611

Files:
  lldb/lit/Breakpoint/Inputs/jitbp.cpp
  lldb/lit/Breakpoint/jitbp_elf.test
  lldb/lit/helper/toolchain.py
  lldb/source/Plugins/JITLoader/GDB/JITLoaderGDB.cpp
  lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp


Index: lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
===
--- lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
+++ lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
@@ -1865,7 +1865,7 @@
 return;
 
   m_sections_up = llvm::make_unique();
-  VMAddressProvider address_provider(CalculateType());
+  VMAddressProvider address_provider(GetType());
 
   size_t LoadID = 0;
   for (const auto &EnumPHdr : llvm::enumerate(ProgramHeaders())) {
Index: lldb/source/Plugins/JITLoader/GDB/JITLoaderGDB.cpp
===
--- lldb/source/Plugins/JITLoader/GDB/JITLoaderGDB.cpp
+++ lldb/source/Plugins/JITLoader/GDB/JITLoaderGDB.cpp
@@ -327,6 +327,10 @@
   FileSpec(jit_name), symbolfile_addr, symbolfile_size);
 
   if (module_sp && module_sp->GetObjectFile()) {
+// Object formats (like ELF) have no representation for a JIT type.
+// We will get it wrong, if we deduce it from the header.
+module_sp->GetObjectFile()->SetType(ObjectFile::eTypeJIT);
+
 // load the symbol table right away
 module_sp->GetObjectFile()->GetSymtab();
 
Index: lldb/lit/helper/toolchain.py
===
--- lldb/lit/helper/toolchain.py
+++ lldb/lit/helper/toolchain.py
@@ -134,6 +134,6 @@
 
 support_tools = ['yaml2obj', 'obj2yaml', 'llvm-pdbutil',
  'llvm-mc', 'llvm-readobj', 'llvm-objdump',
- 'llvm-objcopy']
+ 'llvm-objcopy', 'lli']
 additional_tool_dirs += [config.lldb_tools_dir, config.llvm_tools_dir]
 llvm_config.add_tool_substitutions(support_tools, additional_tool_dirs)
Index: lldb/lit/Breakpoint/jitbp_elf.test
===
--- /dev/null
+++ lldb/lit/Breakpoint/jitbp_elf.test
@@ -0,0 +1,11 @@
+# XFAIL: system-windows
+
+# RUN: %clang -g -S -emit-llvm --target=x86_64-unknown-unknown-elf -o %t.ll 
%p/Inputs/jitbp.cpp
+# RUN: %lldb -b -o 'settings set plugin.jit-loader.gdb.enable on' -o 'b jitbp' 
-o 'run -jit-kind=mcjit %t.ll' lli | FileCheck %s
+
+# CHECK: Breakpoint 1: no locations (pending).
+# CHECK: (lldb) run -jit-kind=mcjit {{.*}}/jitbp_elf.test.tmp.ll
+# CHECK: 1 location added to breakpoint 1
+# CHECK: Process {{.*}} stopped
+# CHECK: JIT(0x{{.*}})`jitbp:
+# CHECK: Process {{.*}} launched: {{.*}}
Index: lldb/lit/Breakpoint/Inputs/jitbp.cpp
===
--- /dev/null
+++ lldb/lit/Breakpoint/Inputs/jitbp.cpp
@@ -0,0 +1,2 @@
+int jitbp() { return 0; }
+int main() { return jitbp(); }


Index: lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
===
--- lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
+++ lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
@@ -1865,7 +1865,7 @@
 return;
 
   m_sections_up = llvm::make_unique();
-  VMAddressProvider address_provider(CalculateType());
+  VMAddressProvider address_provider(GetType());
 
   size_t LoadID = 0;
   for (const auto &EnumPHdr : llvm::enumerate(ProgramHeaders())) {
Index: lldb/source/Plugins/JITLoader/GDB/JITLoaderGDB.cpp
===
--- lldb/source/Plugins/JITLoader/GDB/JITLoaderGDB.cpp
+++ lldb/source/Plugins/JITLoader/GDB/JITLoaderGDB.cpp
@@ -327,6 +327,10 @@
   FileSpec(jit_name), symbolfile_addr, symbolfile_size);
 
   if (module_sp && module_sp->GetObjectFile()) {
+// Object formats (like ELF) have no representation for a JIT type.
+// We will get it wrong, if we deduce it from the header.
+module_sp->GetObjectFile()->SetType(ObjectFile::eTypeJIT);
+
 // load the symbol table right away
 module_sp->GetObjectFile()->GetSymtab();
 
Index: lldb/lit/helper/toolchain.py
===
--- lldb/lit/helper/toolchain.py
+++ lldb/lit/helper/toolchain.py
@@ -134,6 +134,6 @@
 
 support_tools = ['yaml2obj', 'obj2yaml', 'llvm-pdbutil',
  'llvm-mc', 'llvm-readobj', 'llvm-objdump',
- 'llvm-objcopy']
+ 'llvm-objcopy', 'lli']
 additional_tool_dirs += [config.lldb_tools_dir, config.llvm_tools_dir]
 llvm_config.add_tool_substitutions(support_tools, additional_tool_dirs)
Index: lldb/lit/Break

[Lldb-commits] [PATCH] D61687: Update Python tests for lldb-server on Windows

[Greg Clayton via Phabricator via lldb-commits]

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



Comment at: 
packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemoteKill.py:17
 def attach_commandline_kill_after_initial_stop(self):
+reg_expr = r"^\$X[0-9a-fA-F]+([^#]*)#[0-9A-Fa-f]{2}"
+triple = self.dbg.GetSelectedPlatform().GetTriple()

labath wrote:
> If I understand correctly, the regexes differ only in the first letter. If 
> that's the case, then you could just factor out the rest of the regex and 
> just compute the letter differently:
> ```
> stop_type = 'W' if windows else 'X'
> reg_expr = r"^\${}...".format(stop_type)
> ```
Just make one if there can be two letters?:

reg_expr = r"^\$[XW][0-9a-fA-F]+([^#]*)#[0-9A-Fa-f]{2}"




Comment at: 
packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemoteKill.py:20-23
+# No signal support on Windwos. Only W* response is sent.
+if re.match(".*-.*-windows", triple):
+reg_expr = r"^\$W[0-9a-fA-F]+([^#]*)#[0-9A-Fa-f]{2}"
+

Remove



Comment at: 
packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemoteModuleInfo.py:22
 
+module_path = lldbutil.append_to_process_working_directory(self, 
"a.out")
+

Use json.dumps:
```
module_path = json.dumps(lldbutil.append_to_process_working_directory(self, 
"a.out"))
```



Comment at: 
packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemoteModuleInfo.py:24-27
+# Replace path separators in the json string either with "" or "/" 
on Windows.
+triple = self.dbg.GetSelectedPlatform().GetTriple()
+if re.match(".*-.*-windows", triple):
+module_path = module_path.replace(os.path.sep, '/')

labath wrote:
> It sounds like you could just unconditionally replace all backslashes with 
> double-backslashes here. That would result in us also correctly handling 
> posix paths that happen to contain a backslash.
Remove



Comment at: 
packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemoteSingleStep.py:23
 
+@skipIfWindows # No pty support to test any inferior std -i/e/o
 @llgs_test

We probably don't need pty support just to support STDIO redirection to a child 
process we spawn. That is how it is done for linux, but doens't need to be how 
it is done on windows. Be great if we can fix this.



Comment at: 
packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemote_qThreadStopInfo.py:59-61
+# On Windows, there could be more threads spawned. For example, 
DebugBreakProcess will
+# create a new thread from the debugged process to handle an exception 
event. So here we
+# assert 'GreaterEqual' condition.

Will this always be "thread_count+1" for window? Or can there be more threads.

This leads to a higher level question: Does the user ever want to see the 
"DebugBreakProcess" thread in the IDE? Should we just never report this thread 
from lldb-server and avoid these mismatch issues? We should be consistent with 
what other windows debuggers do (show DebugBreakProcess or not).



Comment at: 
packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemote_vCont.py:108
 
+@skipIfWindows # No pty support to test O* & I* notification packets.
 @llgs_test

We probably don't need pty support just to support STDIO redirection to a child 
process we spawn. That is how it is done for linux, but doens't need to be how 
it is done on windows. Be great if we can fix this.


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D61687



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

[Lldb-commits] [PATCH] D61611: [JITLoaderGDB] Set eTypeJIT for objects read from JIT descriptors

[Stefan Gränitz via Phabricator via lldb-commits]

sgraenitz added a comment.

In D61611#1496644 , @probinson wrote:

> Sorry for the drive-by... what is this `REQUIRES: nowindows`?  I don't see 
> where lit generates this property.  I grepped all of llvm-project.git and I 
> see it used in two tests, but not where it's produced. Which suggests that 
> those tests don't actually run *anywhere*.


Thanks for the heads-up. I also just grepped. The history says that Stella will 
know more about it. I went with `XFAIL` for now.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D61611



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

[Lldb-commits] [PATCH] D61611: [JITLoaderGDB] Set eTypeJIT for objects read from JIT descriptors

[Stefan Gränitz via Phabricator via lldb-commits]

sgraenitz marked 3 inline comments as done.
sgraenitz added inline comments.



Comment at: lldb/lit/Breakpoint/jitbp_elf.test:1
+# REQUIRES: target-x86_64, system-linux, native
+

labath wrote:
> sgraenitz wrote:
> > labath wrote:
> > > sgraenitz wrote:
> > > > The test only works with ELF on Linux. Is the `REQUIRES` sufficient?
> > > Yes, but what is the reason for that? It looks like the test is generic 
> > > enough that it should run on any system where lli is able to jit code. In 
> > > particular I'd expect this to also work on macOS if you set 
> > > `plugin-jit-loader.gdb.enable` to `on`.
> > Indeed, since https://reviews.llvm.org/D57689 it does work on macOS with 
> > ELF.
> Cool. I think you can also drop the `target-x86_64` part, as I don't see a 
> reason why this shouldn't work on arm for instance (though we don't have any 
> arm bots around to verify that). I am not sure why you're using the 
> `--target` argument to clang -- I think you should be able to just drop that 
> and make clang generate IR for the host. (the `native` feature ensures that 
> "host" is the default target for clang).
Without `--target` we emit MachO, which is not implemented on the JIT side and 
LLDB doesn't even get a JIT descriptor:
```
$ bin/lldb
(lldb) target create bin/lli
Current executable set to 'bin/lli' (x86_64).
(lldb) b getObjectForDebug
Breakpoint 1: 3 locations.
(lldb) run -jit-kind=mcjit 
tools/lldb/lit/Breakpoint/Output/jitbp_elf.test.tmp.ll
Process 40151 launched: /path/to/llvm-build/bin/lli' (x86_64)
Process 40151 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.3
frame #0: 0x000100f3ddb3 lli`(anonymous 
namespace)::LoadedMachOObjectInfo::getObjectForDebug(this=0x000105c03540, 
Obj=0x000105c03880) const at RuntimeDyldMachO.cpp:38:12
   35   
   36 OwningBinary
   37 getObjectForDebug(const ObjectFile &Obj) const override {
-> 38   return OwningBinary();
   39 }
   40   };
   41
```


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D61611



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

[Lldb-commits] [PATCH] D61611: [JITLoaderGDB] Set eTypeJIT for objects read from JIT descriptors

[Pavel Labath via Phabricator via lldb-commits]

labath added inline comments.



Comment at: lldb/lit/Breakpoint/jitbp_elf.test:1
+# REQUIRES: target-x86_64, system-linux, native
+

sgraenitz wrote:
> labath wrote:
> > sgraenitz wrote:
> > > labath wrote:
> > > > sgraenitz wrote:
> > > > > The test only works with ELF on Linux. Is the `REQUIRES` sufficient?
> > > > Yes, but what is the reason for that? It looks like the test is generic 
> > > > enough that it should run on any system where lli is able to jit code. 
> > > > In particular I'd expect this to also work on macOS if you set 
> > > > `plugin-jit-loader.gdb.enable` to `on`.
> > > Indeed, since https://reviews.llvm.org/D57689 it does work on macOS with 
> > > ELF.
> > Cool. I think you can also drop the `target-x86_64` part, as I don't see a 
> > reason why this shouldn't work on arm for instance (though we don't have 
> > any arm bots around to verify that). I am not sure why you're using the 
> > `--target` argument to clang -- I think you should be able to just drop 
> > that and make clang generate IR for the host. (the `native` feature ensures 
> > that "host" is the default target for clang).
> Without `--target` we emit MachO, which is not implemented on the JIT side 
> and LLDB doesn't even get a JIT descriptor:
> ```
> $ bin/lldb
> (lldb) target create bin/lli
> Current executable set to 'bin/lli' (x86_64).
> (lldb) b getObjectForDebug
> Breakpoint 1: 3 locations.
> (lldb) run -jit-kind=mcjit 
> tools/lldb/lit/Breakpoint/Output/jitbp_elf.test.tmp.ll
> Process 40151 launched: /path/to/llvm-build/bin/lli' (x86_64)
> Process 40151 stopped
> * thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.3
> frame #0: 0x000100f3ddb3 lli`(anonymous 
> namespace)::LoadedMachOObjectInfo::getObjectForDebug(this=0x000105c03540, 
> Obj=0x000105c03880) const at RuntimeDyldMachO.cpp:38:12
>35 
>36   OwningBinary
>37   getObjectForDebug(const ObjectFile &Obj) const override {
> -> 38 return OwningBinary();
>39   }
>40 };
>41
> ```
Ah, interesting. That's unfortunate, cause that makes running the test on other 
architectures trickier (but I guess it doesn't matter that much as we'll always 
have x86 bots around to check that.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D61611



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

[Lldb-commits] [PATCH] D61423: MinidumpYAML: add support for the ThreadList stream

[Pavel Labath via Phabricator via lldb-commits]

This revision was automatically updated to reflect the committed changes.
labath marked an inline comment as done.
Closed by commit rL360350: MinidumpYAML: add support for the ThreadList stream 
(authored by labath, committed by ).

Changed prior to commit:
  https://reviews.llvm.org/D61423?vs=198653&id=198830#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D61423

Files:
  llvm/trunk/include/llvm/ObjectYAML/MinidumpYAML.h
  llvm/trunk/lib/ObjectYAML/MinidumpYAML.cpp
  llvm/trunk/test/tools/obj2yaml/basic-minidump.yaml

Index: llvm/trunk/include/llvm/ObjectYAML/MinidumpYAML.h
===
--- llvm/trunk/include/llvm/ObjectYAML/MinidumpYAML.h
+++ llvm/trunk/include/llvm/ObjectYAML/MinidumpYAML.h
@@ -30,6 +30,7 @@
 RawContent,
 SystemInfo,
 TextContent,
+ThreadList,
   };
 
   Stream(StreamKind Kind, minidump::StreamType Type) : Kind(Kind), Type(Type) {}
@@ -50,30 +51,46 @@
  const object::MinidumpFile &File);
 };
 
-/// A stream representing the list of modules loaded in the process. On disk, it
-/// is represented as a sequence of minidump::Module structures. These contain
-/// pointers to other data structures, like the module's name and CodeView
-/// record. In memory, we represent these as the ParsedModule struct, which
-/// groups minidump::Module with all of its dependant structures in a single
-/// entity.
-struct ModuleListStream : public Stream {
-  struct ParsedModule {
-minidump::Module Module;
-std::string Name;
-yaml::BinaryRef CvRecord;
-yaml::BinaryRef MiscRecord;
-  };
-  std::vector Modules;
+namespace detail {
+/// A stream representing a list of abstract entries in a minidump stream. Its
+/// instantiations can be used to represent the ModuleList stream and other
+/// streams with a similar structure.
+template  struct ListStream : public Stream {
+  using entry_type = EntryT;
 
-  ModuleListStream(std::vector Modules = {})
-  : Stream(StreamKind::ModuleList, minidump::StreamType::ModuleList),
-Modules(std::move(Modules)) {}
+  std::vector Entries;
 
-  static bool classof(const Stream *S) {
-return S->Kind == StreamKind::ModuleList;
-  }
+  explicit ListStream(std::vector Entries = {})
+  : Stream(EntryT::Kind, EntryT::Type), Entries(std::move(Entries)) {}
+
+  static bool classof(const Stream *S) { return S->Kind == EntryT::Kind; }
 };
 
+/// A structure containing all data belonging to a single minidump module.
+struct ParsedModule {
+  static constexpr Stream::StreamKind Kind = Stream::StreamKind::ModuleList;
+  static constexpr minidump::StreamType Type = minidump::StreamType::ModuleList;
+
+  minidump::Module Entry;
+  std::string Name;
+  yaml::BinaryRef CvRecord;
+  yaml::BinaryRef MiscRecord;
+};
+
+/// A structure containing all data belonging to a single minidump thread.
+struct ParsedThread {
+  static constexpr Stream::StreamKind Kind = Stream::StreamKind::ThreadList;
+  static constexpr minidump::StreamType Type = minidump::StreamType::ThreadList;
+
+  minidump::Thread Entry;
+  yaml::BinaryRef Stack;
+  yaml::BinaryRef Context;
+};
+} // namespace detail
+
+using ModuleListStream = detail::ListStream;
+using ThreadListStream = detail::ListStream;
+
 /// A minidump stream represented as a sequence of hex bytes. This is used as a
 /// fallback when no other stream kind is suitable.
 struct RawContentStream : public Stream {
@@ -176,6 +193,11 @@
   static StringRef validate(IO &IO, std::unique_ptr &S);
 };
 
+template <> struct MappingContextTraits {
+  static void mapping(IO &IO, minidump::MemoryDescriptor &Memory,
+  BinaryRef &Content);
+};
+
 } // namespace yaml
 
 } // namespace llvm
@@ -188,11 +210,15 @@
 LLVM_YAML_DECLARE_MAPPING_TRAITS(llvm::minidump::CPUInfo::OtherInfo)
 LLVM_YAML_DECLARE_MAPPING_TRAITS(llvm::minidump::CPUInfo::X86Info)
 LLVM_YAML_DECLARE_MAPPING_TRAITS(llvm::minidump::VSFixedFileInfo)
+
+LLVM_YAML_DECLARE_MAPPING_TRAITS(
+llvm::MinidumpYAML::ModuleListStream::entry_type)
 LLVM_YAML_DECLARE_MAPPING_TRAITS(
-llvm::MinidumpYAML::ModuleListStream::ParsedModule)
+llvm::MinidumpYAML::ThreadListStream::entry_type)
 
 LLVM_YAML_IS_SEQUENCE_VECTOR(std::unique_ptr)
-LLVM_YAML_IS_SEQUENCE_VECTOR(llvm::MinidumpYAML::ModuleListStream::ParsedModule)
+LLVM_YAML_IS_SEQUENCE_VECTOR(llvm::MinidumpYAML::ModuleListStream::entry_type)
+LLVM_YAML_IS_SEQUENCE_VECTOR(llvm::MinidumpYAML::ThreadListStream::entry_type)
 
 LLVM_YAML_DECLARE_MAPPING_TRAITS(llvm::MinidumpYAML::Object)
 
Index: llvm/trunk/test/tools/obj2yaml/basic-minidump.yaml
===
--- llvm/trunk/test/tools/obj2yaml/basic-minidump.yaml
+++ llvm/trunk/test/tools/obj2yaml/basic-minidump.yaml
@@ -1,12 +1,12 @@
 # RUN: yaml2obj %s | obj2yaml - | FileCheck %s
 
 --- !minidump
-Streams: 
+Streams:
   - Type:SystemInfo
 

[Lldb-commits] [PATCH] D61737: [lldb] add -ex CLI option as alias to --one-line

[Konrad Wilhelm Kleine via Phabricator via lldb-commits]

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

To ease the adoption of LLDB for users coming from GDB, I've added the
command line option `-ex` to the `lldb` binary. It is an alias the the
`--one-line` option which

> Tells the debugger to execute this one-line lldb command after any
>  file provided on the command line has been loaded.

This is probably as close as we can get to `gdb`'s `-ex` option which
had this documentation:

> -ex command
> 
>   Execute given GDB command.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D61737

Files:
  lldb/tools/driver/Options.td


Index: lldb/tools/driver/Options.td
===
--- lldb/tools/driver/Options.td
+++ lldb/tools/driver/Options.td
@@ -159,6 +159,10 @@
   Alias,
   HelpText<"Alias for --one-line">,
   Group;
+def: Separate<["-"], "ex">,
+  Alias,
+  HelpText<"Alias for --one-line. This exists just to ease adoption of LLDB 
for GDB users.">,
+  Group;
 
 def one_line_before_file: Separate<["--", "-"], "one-line-before-file">,
   MetaVarName<"">,


Index: lldb/tools/driver/Options.td
===
--- lldb/tools/driver/Options.td
+++ lldb/tools/driver/Options.td
@@ -159,6 +159,10 @@
   Alias,
   HelpText<"Alias for --one-line">,
   Group;
+def: Separate<["-"], "ex">,
+  Alias,
+  HelpText<"Alias for --one-line. This exists just to ease adoption of LLDB for GDB users.">,
+  Group;
 
 def one_line_before_file: Separate<["--", "-"], "one-line-before-file">,
   MetaVarName<"">,
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D61611: [JITLoaderGDB] Set eTypeJIT for objects read from JIT descriptors

[Stefan Gränitz via Phabricator via lldb-commits]

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

Add back test requirement target-x86_64


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D61611

Files:
  lldb/lit/Breakpoint/Inputs/jitbp.cpp
  lldb/lit/Breakpoint/jitbp_elf.test
  lldb/lit/helper/toolchain.py
  lldb/source/Plugins/JITLoader/GDB/JITLoaderGDB.cpp
  lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp


Index: lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
===
--- lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
+++ lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
@@ -1865,7 +1865,7 @@
 return;
 
   m_sections_up = llvm::make_unique();
-  VMAddressProvider address_provider(CalculateType());
+  VMAddressProvider address_provider(GetType());
 
   size_t LoadID = 0;
   for (const auto &EnumPHdr : llvm::enumerate(ProgramHeaders())) {
Index: lldb/source/Plugins/JITLoader/GDB/JITLoaderGDB.cpp
===
--- lldb/source/Plugins/JITLoader/GDB/JITLoaderGDB.cpp
+++ lldb/source/Plugins/JITLoader/GDB/JITLoaderGDB.cpp
@@ -327,6 +327,10 @@
   FileSpec(jit_name), symbolfile_addr, symbolfile_size);
 
   if (module_sp && module_sp->GetObjectFile()) {
+// Object formats (like ELF) have no representation for a JIT type.
+// We will get it wrong, if we deduce it from the header.
+module_sp->GetObjectFile()->SetType(ObjectFile::eTypeJIT);
+
 // load the symbol table right away
 module_sp->GetObjectFile()->GetSymtab();
 
Index: lldb/lit/helper/toolchain.py
===
--- lldb/lit/helper/toolchain.py
+++ lldb/lit/helper/toolchain.py
@@ -134,6 +134,6 @@
 
 support_tools = ['yaml2obj', 'obj2yaml', 'llvm-pdbutil',
  'llvm-mc', 'llvm-readobj', 'llvm-objdump',
- 'llvm-objcopy']
+ 'llvm-objcopy', 'lli']
 additional_tool_dirs += [config.lldb_tools_dir, config.llvm_tools_dir]
 llvm_config.add_tool_substitutions(support_tools, additional_tool_dirs)
Index: lldb/lit/Breakpoint/jitbp_elf.test
===
--- /dev/null
+++ lldb/lit/Breakpoint/jitbp_elf.test
@@ -0,0 +1,12 @@
+# REQUIRES: target-x86_64
+# XFAIL: system-windows
+
+# RUN: %clang -g -S -emit-llvm --target=x86_64-unknown-unknown-elf -o %t.ll 
%p/Inputs/jitbp.cpp
+# RUN: %lldb -b -o 'settings set plugin.jit-loader.gdb.enable on' -o 'b jitbp' 
-o 'run -jit-kind=mcjit %t.ll' lli | FileCheck %s
+
+# CHECK: Breakpoint 1: no locations (pending).
+# CHECK: (lldb) run -jit-kind=mcjit {{.*}}/jitbp_elf.test.tmp.ll
+# CHECK: 1 location added to breakpoint 1
+# CHECK: Process {{.*}} stopped
+# CHECK: JIT(0x{{.*}})`jitbp:
+# CHECK: Process {{.*}} launched: {{.*}}
Index: lldb/lit/Breakpoint/Inputs/jitbp.cpp
===
--- /dev/null
+++ lldb/lit/Breakpoint/Inputs/jitbp.cpp
@@ -0,0 +1,2 @@
+int jitbp() { return 0; }
+int main() { return jitbp(); }


Index: lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
===
--- lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
+++ lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
@@ -1865,7 +1865,7 @@
 return;
 
   m_sections_up = llvm::make_unique();
-  VMAddressProvider address_provider(CalculateType());
+  VMAddressProvider address_provider(GetType());
 
   size_t LoadID = 0;
   for (const auto &EnumPHdr : llvm::enumerate(ProgramHeaders())) {
Index: lldb/source/Plugins/JITLoader/GDB/JITLoaderGDB.cpp
===
--- lldb/source/Plugins/JITLoader/GDB/JITLoaderGDB.cpp
+++ lldb/source/Plugins/JITLoader/GDB/JITLoaderGDB.cpp
@@ -327,6 +327,10 @@
   FileSpec(jit_name), symbolfile_addr, symbolfile_size);
 
   if (module_sp && module_sp->GetObjectFile()) {
+// Object formats (like ELF) have no representation for a JIT type.
+// We will get it wrong, if we deduce it from the header.
+module_sp->GetObjectFile()->SetType(ObjectFile::eTypeJIT);
+
 // load the symbol table right away
 module_sp->GetObjectFile()->GetSymtab();
 
Index: lldb/lit/helper/toolchain.py
===
--- lldb/lit/helper/toolchain.py
+++ lldb/lit/helper/toolchain.py
@@ -134,6 +134,6 @@
 
 support_tools = ['yaml2obj', 'obj2yaml', 'llvm-pdbutil',
  'llvm-mc', 'llvm-readobj', 'llvm-objdump',
- 'llvm-objcopy']
+ 'llvm-objcopy', 'lli']
 additional_tool_dirs += [config.lldb_tools_dir, config.llvm_tools_dir]
 llvm_config.add_tool_substitutions(support_tools, additional_tool_dirs)
Index: lldb/lit/Breakpo

[Lldb-commits] [PATCH] D61611: [JITLoaderGDB] Set eTypeJIT for objects read from JIT descriptors

[Stella Stamenova via Phabricator via lldb-commits]

stella.stamenova added a comment.

In D61611#1496681 , @sgraenitz wrote:

> In D61611#1496644 , @probinson wrote:
>
> > Sorry for the drive-by... what is this `REQUIRES: nowindows`?  I don't see 
> > where lit generates this property.  I grepped all of llvm-project.git and I 
> > see it used in two tests, but not where it's produced. Which suggests that 
> > those tests don't actually run *anywhere*.
>
>
> Thanks for the heads-up. I also just grepped. The history says that Stella 
> will know more about it. I went with `XFAIL` for now.


The syntax is supposed to be different: XFAIL means that the test is expected 
to fail no that platform, but it will still run. This makes sense for tests 
that should eventually pass on that platform, but don't yet. REQUIRES: noX 
means that the test won't run unless the requirement is satisfied. In the case 
of REQUIRES: nowindows this means that the test does not even support windows 
and it should never pass there. There are currently a couple of tests in LLVM 
and LLDB marked with REQUIRES: nowindows because they are not expected to run 
there at all.

The "feature" nowindows is supposed to be added to the available features in 
lit/llvm/config.py, but it looks like it's not at the moment, so I am wondering 
if the two tests that are marked as nowindows run on any platform right now. 
I'll update config.py to create the right features, so you can assume that 
nosystem-windows will be a "feature" that is set on non-windows platforms 
(since we use system-X now).

For your tests, I think they are expected to *eventually* pass on Windows even 
if they don't today, correct? If that's the case, then you should use XFAIL. 
Otherwise, you should use REQUIRES: nosystem-windows.

I can apply your patch locally tomorrowish and run the tests to see how they 
behave on Windows.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D61611



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

[Lldb-commits] [PATCH] D61438: [ASTImporter] Use llvm::Expected and Error in the importer API

[Adrian Prantl via Phabricator via lldb-commits]

aprantl added inline comments.



Comment at: clang/include/clang/AST/ASTImporter.h:203
 /// context, or the import error.
-llvm::Expected Import_New(TypeSourceInfo *FromTSI);
-// FIXME: Remove this version.
-TypeSourceInfo *Import(TypeSourceInfo *FromTSI);
+llvm::Expected Import(TypeSourceInfo *FromTSI);
 

Wouldn't it make more sense to return `Expected`?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D61438



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

[Lldb-commits] [PATCH] D61732: FuncUnwinders: Add a new "SymbolFile" unwind plan

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

In D61732#1496575 , @clayborg wrote:

> Looks good except the inline comment about all the unwind plans we have now. 
> Would love to simplify this so that EH frame, compact unwind, ARM unwind, 
> breakpad unwind all come from the symbol file or object files. Also be nice 
> to have a register resolver that works without having a process so we can 
> dump unwind info without needing a process.


I was also considering that (making unwind plan providers more pluggable), but 
I gave up after a day or two of experimenting. As I recall, the main problem 
was that there are places in code that go straight for a specific unwind plan 
instead of just asking for a "(non)call site unwind plan". Some of those use 
cases are relatively reasonable: e.g. one can ask for an eh_frame unwind plan 
even if he does know the exact symbol and it's boundaries where he's stopped 
at, but that is definitely not the case for the "instruction emulation" plan.

It wasn't clear to me how to reconcile these requirements, so I just went with 
the approach that preserves status quo. Given that most of these unwind plans 
are not tied to a specific object/symbol file format (I didn't realize that 
compact unwind is specific to mach-o), encapsulating them inside a plugin did 
not seem to be that important.

The thing that could help with the readability here is to avoid having a 
separate shared_ptr for the plan, and a bool flag for whether we attempted to 
create the plan. Encapsulating that into a single entity would go a long way 
towards making this class more readable, but it would also increase the size of 
this class (i'm not sure how much we care about that). There are also ways to 
do that without increasing the size (or even with decreasing it), but they 
would all be more or less magical, which I wasn't sure whether is worth it.

I definitely plan to look into making unwind plan computation possible without 
a running process but that will require us to get a different source of truth 
for the register eh/dwarf numbers (right now we get those from the remote 
stub), which is not going to be an easy task.


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

https://reviews.llvm.org/D61732



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

[Lldb-commits] [lldb] r360354 - [JITLoaderGDB] Set eTypeJIT for objects read from JIT descriptors

[Stefan Granitz via lldb-commits]

Author: stefan.graenitz
Date: Thu May  9 09:40:57 2019
New Revision: 360354

URL: http://llvm.org/viewvc/llvm-project?rev=360354&view=rev
Log:
[JITLoaderGDB] Set eTypeJIT for objects read from JIT descriptors

Summary:
First part of a fix for JITed code debugging. This has been a regression from 
5.0 to 6.0 and it's is still reproducible on current master: 
https://bugs.llvm.org/show_bug.cgi?id=36209

The address of the breakpoint site is corrupt: the 0x4 value we end up with, 
looks like an offset on a zero base address. When we parse the ELF section 
headers from the JIT descriptor, the load address for the text section we find 
in `header.sh_addr` is correct.

The bug manifests in `VMAddressProvider::GetVMRange(const ELFSectionHeader &)` 
(follow it from `ObjectFileELF::CreateSections()`). Here we think the object 
type was `eTypeObjectFile` and unleash some extra logic [1] which essentially 
overwrites the address with a zero value.

The object type is deduced from the ELF header's `e_type` in 
`ObjectFileELF::CalculateType()`. It never returns `eTypeJIT`, because the ELF 
header has no representation for it [2]. Instead the in-memory ELF object 
states `ET_REL`, which leads to `eTypeObjectFile`. This is what we get from 
`lli` at least since 3.x. (Might it be better to write `ET_EXEC` on the JIT 
side instead? In fact, relocations were already applied at this point, so 
"Relocatable" is not quite exact.)

So, this patch proposes to set `eTypeJIT` explicitly whenever we read from a 
JIT descriptor. In `ObjectFileELF::CreateSections()` we can then call 
`GetType()`, which returns the explicit value or otherwise falls back to 
`CalculateType()`.

LLDB then sets the breakpoint successfully. Next step: debug info.
```
Process 1056 stopped
* thread #1, name = 'lli', stop reason = breakpoint 1.2
frame #0: 0x77ff7000 JIT(0x3ba2030)`jitbp()
JIT(0x3ba2030)`jitbp:
->  0x77ff7000 <+0>:  pushq  %rbp
0x77ff7001 <+1>:  movq   %rsp, %rbp
0x77ff7004 <+4>:  movabsq $0x77ff6000, %rdi ; imm = 
0x77FF6000
0x77ff700e <+14>: movabsq $0x76697e80, %rcx ; imm = 
0x76697E80
```

[1] It was first introduced with 
https://reviews.llvm.org/D38142#change-lF6csxV8HdlL, which has also been the 
original breaking change. The code has changed a lot since then.

[2] ELF object types: 
https://github.com/llvm/llvm-project/blob/2d2277f5/llvm/include/llvm/BinaryFormat/ELF.h#L110

Reviewers: labath, JDevlieghere, bkoropoff, clayborg, espindola, alexshap, 
stella.stamenova

Reviewed By: labath, clayborg

Subscribers: probinson, emaste, aprantl, arichardson, MaskRay, AlexDenisov, 
yurydelendik, lldb-commits

Tags: #lldb

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

Added:
lldb/trunk/lit/Breakpoint/Inputs/jitbp.cpp
lldb/trunk/lit/Breakpoint/jitbp_elf.test
Modified:
lldb/trunk/lit/helper/toolchain.py
lldb/trunk/source/Plugins/JITLoader/GDB/JITLoaderGDB.cpp
lldb/trunk/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp

Added: lldb/trunk/lit/Breakpoint/Inputs/jitbp.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/lit/Breakpoint/Inputs/jitbp.cpp?rev=360354&view=auto
==
--- lldb/trunk/lit/Breakpoint/Inputs/jitbp.cpp (added)
+++ lldb/trunk/lit/Breakpoint/Inputs/jitbp.cpp Thu May  9 09:40:57 2019
@@ -0,0 +1,2 @@
+int jitbp() { return 0; }
+int main() { return jitbp(); }

Added: lldb/trunk/lit/Breakpoint/jitbp_elf.test
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/lit/Breakpoint/jitbp_elf.test?rev=360354&view=auto
==
--- lldb/trunk/lit/Breakpoint/jitbp_elf.test (added)
+++ lldb/trunk/lit/Breakpoint/jitbp_elf.test Thu May  9 09:40:57 2019
@@ -0,0 +1,12 @@
+# REQUIRES: target-x86_64
+# XFAIL: system-windows
+
+# RUN: %clang -g -S -emit-llvm --target=x86_64-unknown-unknown-elf -o %t.ll 
%p/Inputs/jitbp.cpp
+# RUN: %lldb -b -o 'settings set plugin.jit-loader.gdb.enable on' -o 'b jitbp' 
-o 'run -jit-kind=mcjit %t.ll' lli | FileCheck %s
+
+# CHECK: Breakpoint 1: no locations (pending).
+# CHECK: (lldb) run -jit-kind=mcjit {{.*}}/jitbp_elf.test.tmp.ll
+# CHECK: 1 location added to breakpoint 1
+# CHECK: Process {{.*}} stopped
+# CHECK: JIT(0x{{.*}})`jitbp:
+# CHECK: Process {{.*}} launched: {{.*}}

Modified: lldb/trunk/lit/helper/toolchain.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/lit/helper/toolchain.py?rev=360354&r1=360353&r2=360354&view=diff
==
--- lldb/trunk/lit/helper/toolchain.py (original)
+++ lldb/trunk/lit/helper/toolchain.py Thu May  9 09:40:57 2019
@@ -134,6 +134,6 @@ def use_support_substitutions(config):
 
 support_tools = ['yaml2obj', 'obj2yaml', 'llvm-pdbutil',
  'llvm-mc', 'llvm-readobj', 'llvm-objdump',
- 'llvm-objcopy']
+ 'llvm-objcop

[Lldb-commits] [PATCH] D61713: [lldb] build.py: fix behavior when passing --compiler=/path/to/compiler

[Jorge Gorbe Moya via Phabricator via lldb-commits]

jgorbe updated this revision to Diff 198853.
jgorbe added a comment.

Added a new test that checks that, when a full path to a compiler is specified:

- That compiler is used in build commands
- The flag style used in build commands matches the toolchain type autodetected 
from the compiler executable name


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

https://reviews.llvm.org/D61713

Files:
  lldb/lit/BuildScript/compiler-full-path.test
  lldb/lit/helper/build.py


Index: lldb/lit/helper/build.py
===
--- lldb/lit/helper/build.py
+++ lldb/lit/helper/build.py
@@ -207,16 +207,16 @@
 file = os.path.basename(compiler)
 name, ext = os.path.splitext(file)
 if file.lower() == 'cl.exe':
-return 'msvc'
+return ('msvc', compiler)
 if name == 'clang-cl':
-return 'clang-cl'
+return ('clang-cl', compiler)
 if name.startswith('clang'):
-return 'clang'
+return ('clang', compiler)
 if name.startswith('gcc') or name.startswith('g++'):
-return 'gcc'
+return ('gcc', compiler)
 if name == 'cc' or name == 'c++':
-return 'generic'
-return 'unknown'
+return ('generic', compiler)
+return ('unknown', compiler)
 
 class Builder(object):
 def __init__(self, toolchain_type, args, obj_ext):
Index: lldb/lit/BuildScript/compiler-full-path.test
===
--- /dev/null
+++ lldb/lit/BuildScript/compiler-full-path.test
@@ -0,0 +1,12 @@
+RUN: %build -n --verbose --arch=64 --compiler=/path/to/my/clang -o foo \
+RUN:foobar.c | FileCheck %s --check-prefix=CHECK-CLANG
+RUN: %build -n --verbose --arch=64 --compiler=/path/to/my/x64/cl.exe -o foo \
+RUN:foobar.c | FileCheck %s --check-prefix=CHECK-MSVC
+
+CHECK-CLANG: Command Line: /path/to/my/clang
+CHECK-SAME: -o
+
+CHECK-MSVC: Command Line: /path/to/my/x64/cl.exe
+CHECK-SAME: /Fo
+
+


Index: lldb/lit/helper/build.py
===
--- lldb/lit/helper/build.py
+++ lldb/lit/helper/build.py
@@ -207,16 +207,16 @@
 file = os.path.basename(compiler)
 name, ext = os.path.splitext(file)
 if file.lower() == 'cl.exe':
-return 'msvc'
+return ('msvc', compiler)
 if name == 'clang-cl':
-return 'clang-cl'
+return ('clang-cl', compiler)
 if name.startswith('clang'):
-return 'clang'
+return ('clang', compiler)
 if name.startswith('gcc') or name.startswith('g++'):
-return 'gcc'
+return ('gcc', compiler)
 if name == 'cc' or name == 'c++':
-return 'generic'
-return 'unknown'
+return ('generic', compiler)
+return ('unknown', compiler)
 
 class Builder(object):
 def __init__(self, toolchain_type, args, obj_ext):
Index: lldb/lit/BuildScript/compiler-full-path.test
===
--- /dev/null
+++ lldb/lit/BuildScript/compiler-full-path.test
@@ -0,0 +1,12 @@
+RUN: %build -n --verbose --arch=64 --compiler=/path/to/my/clang -o foo \
+RUN:foobar.c | FileCheck %s --check-prefix=CHECK-CLANG
+RUN: %build -n --verbose --arch=64 --compiler=/path/to/my/x64/cl.exe -o foo \
+RUN:foobar.c | FileCheck %s --check-prefix=CHECK-MSVC
+
+CHECK-CLANG: Command Line: /path/to/my/clang
+CHECK-SAME: -o
+
+CHECK-MSVC: Command Line: /path/to/my/x64/cl.exe
+CHECK-SAME: /Fo
+
+
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D61611: [JITLoaderGDB] Set eTypeJIT for objects read from JIT descriptors

[Stefan Gränitz via Phabricator via lldb-commits]

sgraenitz added a comment.

In D61611#1496782 , @stella.stamenova 
wrote:

> I can update config.py to create the right features, but we can also use 
> UNSUPPORTED: system-windows, so I'll look into the best way to do this.


Perfect, thanks

> For your tests, I think they are expected to *eventually* pass on Windows 
> even if they don't today, correct? If that's the case, then you should use 
> XFAIL. Otherwise, you should use REQUIRES: nosystem-windows.

Ok, should be fine to keep `XFAIL` then.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D61611



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

[Lldb-commits] [PATCH] D61611: [JITLoaderGDB] Set eTypeJIT for objects read from JIT descriptors

[Phabricator via Phabricator via lldb-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL360354: [JITLoaderGDB] Set eTypeJIT for objects read from 
JIT descriptors (authored by stefan.graenitz, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D61611?vs=198843&id=198854#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D61611

Files:
  lldb/trunk/lit/Breakpoint/Inputs/jitbp.cpp
  lldb/trunk/lit/Breakpoint/jitbp_elf.test
  lldb/trunk/lit/helper/toolchain.py
  lldb/trunk/source/Plugins/JITLoader/GDB/JITLoaderGDB.cpp
  lldb/trunk/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp


Index: lldb/trunk/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
===
--- lldb/trunk/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
+++ lldb/trunk/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
@@ -1865,7 +1865,7 @@
 return;
 
   m_sections_up = llvm::make_unique();
-  VMAddressProvider address_provider(CalculateType());
+  VMAddressProvider address_provider(GetType());
 
   size_t LoadID = 0;
   for (const auto &EnumPHdr : llvm::enumerate(ProgramHeaders())) {
Index: lldb/trunk/source/Plugins/JITLoader/GDB/JITLoaderGDB.cpp
===
--- lldb/trunk/source/Plugins/JITLoader/GDB/JITLoaderGDB.cpp
+++ lldb/trunk/source/Plugins/JITLoader/GDB/JITLoaderGDB.cpp
@@ -327,6 +327,10 @@
   FileSpec(jit_name), symbolfile_addr, symbolfile_size);
 
   if (module_sp && module_sp->GetObjectFile()) {
+// Object formats (like ELF) have no representation for a JIT type.
+// We will get it wrong, if we deduce it from the header.
+module_sp->GetObjectFile()->SetType(ObjectFile::eTypeJIT);
+
 // load the symbol table right away
 module_sp->GetObjectFile()->GetSymtab();
 
Index: lldb/trunk/lit/Breakpoint/Inputs/jitbp.cpp
===
--- lldb/trunk/lit/Breakpoint/Inputs/jitbp.cpp
+++ lldb/trunk/lit/Breakpoint/Inputs/jitbp.cpp
@@ -0,0 +1,2 @@
+int jitbp() { return 0; }
+int main() { return jitbp(); }
Index: lldb/trunk/lit/Breakpoint/jitbp_elf.test
===
--- lldb/trunk/lit/Breakpoint/jitbp_elf.test
+++ lldb/trunk/lit/Breakpoint/jitbp_elf.test
@@ -0,0 +1,12 @@
+# REQUIRES: target-x86_64
+# XFAIL: system-windows
+
+# RUN: %clang -g -S -emit-llvm --target=x86_64-unknown-unknown-elf -o %t.ll 
%p/Inputs/jitbp.cpp
+# RUN: %lldb -b -o 'settings set plugin.jit-loader.gdb.enable on' -o 'b jitbp' 
-o 'run -jit-kind=mcjit %t.ll' lli | FileCheck %s
+
+# CHECK: Breakpoint 1: no locations (pending).
+# CHECK: (lldb) run -jit-kind=mcjit {{.*}}/jitbp_elf.test.tmp.ll
+# CHECK: 1 location added to breakpoint 1
+# CHECK: Process {{.*}} stopped
+# CHECK: JIT(0x{{.*}})`jitbp:
+# CHECK: Process {{.*}} launched: {{.*}}
Index: lldb/trunk/lit/helper/toolchain.py
===
--- lldb/trunk/lit/helper/toolchain.py
+++ lldb/trunk/lit/helper/toolchain.py
@@ -134,6 +134,6 @@
 
 support_tools = ['yaml2obj', 'obj2yaml', 'llvm-pdbutil',
  'llvm-mc', 'llvm-readobj', 'llvm-objdump',
- 'llvm-objcopy']
+ 'llvm-objcopy', 'lli']
 additional_tool_dirs += [config.lldb_tools_dir, config.llvm_tools_dir]
 llvm_config.add_tool_substitutions(support_tools, additional_tool_dirs)


Index: lldb/trunk/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
===
--- lldb/trunk/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
+++ lldb/trunk/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
@@ -1865,7 +1865,7 @@
 return;
 
   m_sections_up = llvm::make_unique();
-  VMAddressProvider address_provider(CalculateType());
+  VMAddressProvider address_provider(GetType());
 
   size_t LoadID = 0;
   for (const auto &EnumPHdr : llvm::enumerate(ProgramHeaders())) {
Index: lldb/trunk/source/Plugins/JITLoader/GDB/JITLoaderGDB.cpp
===
--- lldb/trunk/source/Plugins/JITLoader/GDB/JITLoaderGDB.cpp
+++ lldb/trunk/source/Plugins/JITLoader/GDB/JITLoaderGDB.cpp
@@ -327,6 +327,10 @@
   FileSpec(jit_name), symbolfile_addr, symbolfile_size);
 
   if (module_sp && module_sp->GetObjectFile()) {
+// Object formats (like ELF) have no representation for a JIT type.
+// We will get it wrong, if we deduce it from the header.
+module_sp->GetObjectFile()->SetType(ObjectFile::eTypeJIT);
+
 // load the symbol table right away
 module_sp->GetObjectFile()->GetSymtab();
 
Index: lldb/trunk/lit/Breakpoint/Inputs/jitbp.cpp
===
--- lldb/trunk/l

[Lldb-commits] [PATCH] D61713: [lldb] build.py: fix behavior when passing --compiler=/path/to/compiler

[Pavel Labath via Phabricator via lldb-commits]

labath accepted this revision.
labath added a comment.

Awesome, thanks!


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

https://reviews.llvm.org/D61713



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

[Lldb-commits] [lldb] r360355 - [lldb] build.py: fix behavior when passing --compiler=/path/to/compiler

[Jorge Gorbe Moya via lldb-commits]

Author: jgorbe
Date: Thu May  9 09:47:07 2019
New Revision: 360355

URL: http://llvm.org/viewvc/llvm-project?rev=360355&view=rev
Log:
[lldb] build.py: fix behavior when passing --compiler=/path/to/compiler

All the other paths in the find_toolchain function return a tuple
(detected_toolchain_type, compiler_path), but when the parameter to
--compiler is not one of the predefined names it only returns the
detected toolchain type, which causes an error when trying to unpack the
result.

This patch changes it to return also the compiler path passed as a
parameter.

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

Added:
lldb/trunk/lit/BuildScript/compiler-full-path.test
Modified:
lldb/trunk/lit/helper/build.py

Added: lldb/trunk/lit/BuildScript/compiler-full-path.test
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/lit/BuildScript/compiler-full-path.test?rev=360355&view=auto
==
--- lldb/trunk/lit/BuildScript/compiler-full-path.test (added)
+++ lldb/trunk/lit/BuildScript/compiler-full-path.test Thu May  9 09:47:07 2019
@@ -0,0 +1,10 @@
+RUN: %build -n --verbose --arch=64 --compiler=/path/to/my/clang -o foo \
+RUN:foobar.c | FileCheck %s --check-prefix=CHECK-CLANG
+RUN: %build -n --verbose --arch=64 --compiler=/path/to/my/x64/cl.exe -o foo \
+RUN:foobar.c | FileCheck %s --check-prefix=CHECK-MSVC
+
+CHECK-CLANG: Command Line: /path/to/my/clang
+CHECK-SAME: -o
+
+CHECK-MSVC: Command Line: /path/to/my/x64/cl.exe
+CHECK-SAME: /Fo

Modified: lldb/trunk/lit/helper/build.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/lit/helper/build.py?rev=360355&r1=360354&r2=360355&view=diff
==
--- lldb/trunk/lit/helper/build.py (original)
+++ lldb/trunk/lit/helper/build.py Thu May  9 09:47:07 2019
@@ -207,16 +207,16 @@ def find_toolchain(compiler, tools_dir):
 file = os.path.basename(compiler)
 name, ext = os.path.splitext(file)
 if file.lower() == 'cl.exe':
-return 'msvc'
+return ('msvc', compiler)
 if name == 'clang-cl':
-return 'clang-cl'
+return ('clang-cl', compiler)
 if name.startswith('clang'):
-return 'clang'
+return ('clang', compiler)
 if name.startswith('gcc') or name.startswith('g++'):
-return 'gcc'
+return ('gcc', compiler)
 if name == 'cc' or name == 'c++':
-return 'generic'
-return 'unknown'
+return ('generic', compiler)
+return ('unknown', compiler)
 
 class Builder(object):
 def __init__(self, toolchain_type, args, obj_ext):


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

[Lldb-commits] [PATCH] D61713: [lldb] build.py: fix behavior when passing --compiler=/path/to/compiler

[Jorge Gorbe Moya via Phabricator via lldb-commits]

jgorbe updated this revision to Diff 198858.
jgorbe added a comment.

Removed trailing blank lines from test case, will commit now. Thanks for the 
review!


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

https://reviews.llvm.org/D61713

Files:
  lldb/lit/BuildScript/compiler-full-path.test
  lldb/lit/helper/build.py


Index: lldb/lit/helper/build.py
===
--- lldb/lit/helper/build.py
+++ lldb/lit/helper/build.py
@@ -207,16 +207,16 @@
 file = os.path.basename(compiler)
 name, ext = os.path.splitext(file)
 if file.lower() == 'cl.exe':
-return 'msvc'
+return ('msvc', compiler)
 if name == 'clang-cl':
-return 'clang-cl'
+return ('clang-cl', compiler)
 if name.startswith('clang'):
-return 'clang'
+return ('clang', compiler)
 if name.startswith('gcc') or name.startswith('g++'):
-return 'gcc'
+return ('gcc', compiler)
 if name == 'cc' or name == 'c++':
-return 'generic'
-return 'unknown'
+return ('generic', compiler)
+return ('unknown', compiler)
 
 class Builder(object):
 def __init__(self, toolchain_type, args, obj_ext):
Index: lldb/lit/BuildScript/compiler-full-path.test
===
--- /dev/null
+++ lldb/lit/BuildScript/compiler-full-path.test
@@ -0,0 +1,10 @@
+RUN: %build -n --verbose --arch=64 --compiler=/path/to/my/clang -o foo \
+RUN:foobar.c | FileCheck %s --check-prefix=CHECK-CLANG
+RUN: %build -n --verbose --arch=64 --compiler=/path/to/my/x64/cl.exe -o foo \
+RUN:foobar.c | FileCheck %s --check-prefix=CHECK-MSVC
+
+CHECK-CLANG: Command Line: /path/to/my/clang
+CHECK-SAME: -o
+
+CHECK-MSVC: Command Line: /path/to/my/x64/cl.exe
+CHECK-SAME: /Fo


Index: lldb/lit/helper/build.py
===
--- lldb/lit/helper/build.py
+++ lldb/lit/helper/build.py
@@ -207,16 +207,16 @@
 file = os.path.basename(compiler)
 name, ext = os.path.splitext(file)
 if file.lower() == 'cl.exe':
-return 'msvc'
+return ('msvc', compiler)
 if name == 'clang-cl':
-return 'clang-cl'
+return ('clang-cl', compiler)
 if name.startswith('clang'):
-return 'clang'
+return ('clang', compiler)
 if name.startswith('gcc') or name.startswith('g++'):
-return 'gcc'
+return ('gcc', compiler)
 if name == 'cc' or name == 'c++':
-return 'generic'
-return 'unknown'
+return ('generic', compiler)
+return ('unknown', compiler)
 
 class Builder(object):
 def __init__(self, toolchain_type, args, obj_ext):
Index: lldb/lit/BuildScript/compiler-full-path.test
===
--- /dev/null
+++ lldb/lit/BuildScript/compiler-full-path.test
@@ -0,0 +1,10 @@
+RUN: %build -n --verbose --arch=64 --compiler=/path/to/my/clang -o foo \
+RUN:foobar.c | FileCheck %s --check-prefix=CHECK-CLANG
+RUN: %build -n --verbose --arch=64 --compiler=/path/to/my/x64/cl.exe -o foo \
+RUN:foobar.c | FileCheck %s --check-prefix=CHECK-MSVC
+
+CHECK-CLANG: Command Line: /path/to/my/clang
+CHECK-SAME: -o
+
+CHECK-MSVC: Command Line: /path/to/my/x64/cl.exe
+CHECK-SAME: /Fo
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D61611: [JITLoaderGDB] Set eTypeJIT for objects read from JIT descriptors

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

In D61611#1496838 , @probinson wrote:

> @stella.stamenova I'm not familiar with any lit feature that gives a special 
> meaning to the prefix "no".  The opposite of "REQUIRES: windows" is not 
> "REQUIRES: nowindows" but "UNSUPPORTED: windows" AFAIK.
>  This part of the discussion should probably be taken to llvm-dev, though.


There's a `binary_feature` function in `utils/lit/lit/llvm/config.py`, but it's 
only used in a handful of cases. And yeah, I would generally prefer 
`UNSUPPORTED: XYZ` over `REQUIRES: noXYZ`.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D61611



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

[Lldb-commits] [PATCH] D61611: [JITLoaderGDB] Set eTypeJIT for objects read from JIT descriptors

[Paul Robinson via Phabricator via lldb-commits]

probinson added a comment.

@stella.stamenova I'm not familiar with any lit feature that gives a special 
meaning to the prefix "no".  The opposite of "REQUIRES: windows" is not 
"REQUIRES: nowindows" but "UNSUPPORTED: windows" AFAIK.
This part of the discussion should probably be taken to llvm-dev, though.

FTR I don't see that lldb's lit.cfg.py sets any features based on host OS, so 
even "UNSUPPORTED: windows" probably does not work currently.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D61611



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

[Lldb-commits] [PATCH] D61733: Breakpad: Generate unwind plans from STACK CFI records

[Pavel Labath via Phabricator via lldb-commits]

labath marked 4 inline comments as done.
labath added inline comments.



Comment at: source/Plugins/SymbolFile/Breakpad/SymbolFileBreakpad.cpp:418
+  if (name == ".ra")
+return resolver.ResolveNumber(eRegisterKindGeneric, 
LLDB_REGNUM_GENERIC_PC);
+  return ResolveRegister(resolver, name);

clayborg wrote:
> LLDB_REGNUM_GENERIC_RA? Do we want the PC here or do we want the link 
> register?
It looks a bit weird, but I believe it should be the PC (and I have checked 
that things unwind correctly this way), because we are specifying value for the 
PC in the parent frame (which is the same as the return address of the current 
frame). Or, to put it another way, breakpad uses ".ra" even on platforms which 
do not have a LLDB_REGNUM_GENERIC_RA register (like x86).



Comment at: source/Plugins/SymbolFile/Breakpad/SymbolFileBreakpad.cpp:491-492
+  llvm::Optional init_record = StackCFIRecord::parse(*It);
+  assert(init_record.hasValue());
+  assert(init_record->Size.hasValue());
+

clayborg wrote:
> will this code be ok if the assertions are compiled out?
Yes, because we make sure that we only store the address of a syntactically 
correct STACK CFI INIT record in the `m_unwind_data` map (down on line 645)


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

https://reviews.llvm.org/D61733



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

[Lldb-commits] [PATCH] D61713: [lldb] build.py: fix behavior when passing --compiler=/path/to/compiler

[Jorge Gorbe Moya via Phabricator via lldb-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL360355: [lldb] build.py: fix behavior when passing 
--compiler=/path/to/compiler (authored by jgorbe, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D61713?vs=198858&id=198859#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D61713

Files:
  lldb/trunk/lit/BuildScript/compiler-full-path.test
  lldb/trunk/lit/helper/build.py


Index: lldb/trunk/lit/BuildScript/compiler-full-path.test
===
--- lldb/trunk/lit/BuildScript/compiler-full-path.test
+++ lldb/trunk/lit/BuildScript/compiler-full-path.test
@@ -0,0 +1,10 @@
+RUN: %build -n --verbose --arch=64 --compiler=/path/to/my/clang -o foo \
+RUN:foobar.c | FileCheck %s --check-prefix=CHECK-CLANG
+RUN: %build -n --verbose --arch=64 --compiler=/path/to/my/x64/cl.exe -o foo \
+RUN:foobar.c | FileCheck %s --check-prefix=CHECK-MSVC
+
+CHECK-CLANG: Command Line: /path/to/my/clang
+CHECK-SAME: -o
+
+CHECK-MSVC: Command Line: /path/to/my/x64/cl.exe
+CHECK-SAME: /Fo
Index: lldb/trunk/lit/helper/build.py
===
--- lldb/trunk/lit/helper/build.py
+++ lldb/trunk/lit/helper/build.py
@@ -207,16 +207,16 @@
 file = os.path.basename(compiler)
 name, ext = os.path.splitext(file)
 if file.lower() == 'cl.exe':
-return 'msvc'
+return ('msvc', compiler)
 if name == 'clang-cl':
-return 'clang-cl'
+return ('clang-cl', compiler)
 if name.startswith('clang'):
-return 'clang'
+return ('clang', compiler)
 if name.startswith('gcc') or name.startswith('g++'):
-return 'gcc'
+return ('gcc', compiler)
 if name == 'cc' or name == 'c++':
-return 'generic'
-return 'unknown'
+return ('generic', compiler)
+return ('unknown', compiler)
 
 class Builder(object):
 def __init__(self, toolchain_type, args, obj_ext):


Index: lldb/trunk/lit/BuildScript/compiler-full-path.test
===
--- lldb/trunk/lit/BuildScript/compiler-full-path.test
+++ lldb/trunk/lit/BuildScript/compiler-full-path.test
@@ -0,0 +1,10 @@
+RUN: %build -n --verbose --arch=64 --compiler=/path/to/my/clang -o foo \
+RUN:foobar.c | FileCheck %s --check-prefix=CHECK-CLANG
+RUN: %build -n --verbose --arch=64 --compiler=/path/to/my/x64/cl.exe -o foo \
+RUN:foobar.c | FileCheck %s --check-prefix=CHECK-MSVC
+
+CHECK-CLANG: Command Line: /path/to/my/clang
+CHECK-SAME: -o
+
+CHECK-MSVC: Command Line: /path/to/my/x64/cl.exe
+CHECK-SAME: /Fo
Index: lldb/trunk/lit/helper/build.py
===
--- lldb/trunk/lit/helper/build.py
+++ lldb/trunk/lit/helper/build.py
@@ -207,16 +207,16 @@
 file = os.path.basename(compiler)
 name, ext = os.path.splitext(file)
 if file.lower() == 'cl.exe':
-return 'msvc'
+return ('msvc', compiler)
 if name == 'clang-cl':
-return 'clang-cl'
+return ('clang-cl', compiler)
 if name.startswith('clang'):
-return 'clang'
+return ('clang', compiler)
 if name.startswith('gcc') or name.startswith('g++'):
-return 'gcc'
+return ('gcc', compiler)
 if name == 'cc' or name == 'c++':
-return 'generic'
-return 'unknown'
+return ('generic', compiler)
+return ('unknown', compiler)
 
 class Builder(object):
 def __init__(self, toolchain_type, args, obj_ext):
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D61611: [JITLoaderGDB] Set eTypeJIT for objects read from JIT descriptors

[Stella Stamenova via Phabricator via lldb-commits]

stella.stamenova added a comment.

In D61611#1496838 , @probinson wrote:

> @stella.stamenova I'm not familiar with any lit feature that gives a special 
> meaning to the prefix "no".  The opposite of "REQUIRES: windows" is not 
> "REQUIRES: nowindows" but "UNSUPPORTED: windows" AFAIK.
>  This part of the discussion should probably be taken to llvm-dev, though.
>
> FTR I don't see that lldb's lit.cfg.py sets any features based on host OS, so 
> even "UNSUPPORTED: windows" probably does not work currently.


@probinson LLDB's lit configuration derives from the lit configuration in LLVM. 
The most important file you are looking for is:

`llvm\utils\lit\lit\llvm\config.py`

You can see there that we add various platform to the list of available 
features including system-windows, so XFAIL: system-windows, UNSUPPORTED: 
system-windows, etc. all work.

This is also where binary_features are set, such as 'zlib/nozlib', 
'asan/not_asan' etc. The prefix varies for historical reasons, but the paradigm 
has existed for a long time. If we wanted to support nosystem-windows, we would 
add it here.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D61611



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

[Lldb-commits] [PATCH] D61733: Breakpad: Generate unwind plans from STACK CFI records

[Greg Clayton via Phabricator via lldb-commits]

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

Thanks for the clarification! LGTM


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

https://reviews.llvm.org/D61733



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

[Lldb-commits] [PATCH] D61686: Enable lldb-server on Windows

[Saleem Abdulrasool via Phabricator via lldb-commits]

compnerd added inline comments.



Comment at: include/lldb/Host/windows/PosixApi.h:106-109
+inline pid_t waitpid(pid_t pid, int *status, int options) {
+  // To be implemented.
+  return pid_t(-1);
+}

labath wrote:
> As discussed in the review where this was forked from, we shouldn't be 
> mocking posix apis. Instead we should provide platform-independent 
> abstractions that each platform can implement in it's own way. Waitpid is 
> right now used in only one place. Implementing it here (even just as a stub) 
> just encourages others to add more uses of it.
> 
> Given that (I think) you don't care about the "server" mode of lldb-platform 
> at the moment, and the fact that the piece of code calling this is already 
> broken because the use of fork, I think that for now we should just 
> #ifdef-out the block of code calling fork and waitpid (it's already 
> structured in a way that's easy to #ifdef. This would enable you to even 
> provide a friendly error message explaining that the requested feature is not 
> available.
I definitely am in favour of removal of the mocked POSIX API, to the point 
where I'm willing to entertain reduced functionality for that.  If we can 
completely preprocess away the usage instead of adding this, I am absolutely 
okay with that.


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

https://reviews.llvm.org/D61686



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

[Lldb-commits] [PATCH] D61611: [JITLoaderGDB] Set eTypeJIT for objects read from JIT descriptors

[Paul Robinson via Phabricator via lldb-commits]

probinson added a comment.

In D61611#1496865 , @stella.stamenova 
wrote:

> In D61611#1496838 , @probinson wrote:
>
> > @stella.stamenova I'm not familiar with any lit feature that gives a 
> > special meaning to the prefix "no".  The opposite of "REQUIRES: windows" is 
> > not "REQUIRES: nowindows" but "UNSUPPORTED: windows" AFAIK.
> >  This part of the discussion should probably be taken to llvm-dev, though.
> >
> > FTR I don't see that lldb's lit.cfg.py sets any features based on host OS, 
> > so even "UNSUPPORTED: windows" probably does not work currently.
>
>
> @probinson LLDB's lit configuration derives from the lit configuration in 
> LLVM. The most important file you are looking for is:
>
> `llvm\utils\lit\lit\llvm\config.py`
>
> You can see there that we add various platform to the list of available 
> features including system-windows, so XFAIL: system-windows, UNSUPPORTED: 
> system-windows, etc. all work.
>
> This is also where binary_features are set, such as 'zlib/nozlib', 
> 'asan/not_asan' etc. The prefix varies for historical reasons, but the 
> paradigm has existed for a long time. If we wanted to support 
> nosystem-windows, we would add it here.


Thanks @stella.stamenova I did find that.  But I agree with Pavel, we are 
better off not having "nofoo" or "not_foo" features, because we can get the 
same effect using UNSUPPORTED: and it can mislead people into thinking the 
no/not_ prefix applies generally, and things like "REQUIRES: nowindows" will 
unexpectedly disable a test everywhere.

I am going to propose eliminating the negative keywords on llvm-dev.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D61611



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

[Lldb-commits] [PATCH] D61746: [Breakpoint] Make breakpoint language agnostic

[Alex Langford via Phabricator via lldb-commits]

xiaobai created this revision.
xiaobai added reviewers: JDevlieghere, jingham, clayborg.
Herald added a subscriber: mgorny.

Breakpoint shouldn't need to depend on any specific details from a
programming language. Currently the only language-specific detail it takes
advantage of are the different qualified names an objective-c method name might
have when adding a name lookup. This is reasonably generalizable.

The current method name I introduced is "GetVariantMethodNames", which I'm not
particularly tied to. If you have a better suggestion, please do let me know.


https://reviews.llvm.org/D61746

Files:
  include/lldb/Target/Language.h
  source/Breakpoint/BreakpointResolverName.cpp
  source/Breakpoint/CMakeLists.txt
  source/Plugins/Language/ObjC/ObjCLanguage.cpp
  source/Plugins/Language/ObjC/ObjCLanguage.h

Index: source/Plugins/Language/ObjC/ObjCLanguage.h
===
--- source/Plugins/Language/ObjC/ObjCLanguage.h
+++ source/Plugins/Language/ObjC/ObjCLanguage.h
@@ -73,18 +73,6 @@
 
 ConstString GetSelector();
 
-// Get all possible names for a method. Examples:
-// If name is "+[NSString(my_additions) myStringWithCString:]"
-//  names[0] => "+[NSString(my_additions) myStringWithCString:]"
-//  names[1] => "+[NSString myStringWithCString:]"
-// If name is specified without the leading '+' or '-' like
-// "[NSString(my_additions) myStringWithCString:]"
-//  names[0] => "+[NSString(my_additions) myStringWithCString:]"
-//  names[1] => "-[NSString(my_additions) myStringWithCString:]"
-//  names[2] => "+[NSString myStringWithCString:]"
-//  names[3] => "-[NSString myStringWithCString:]"
-size_t GetFullNames(std::vector &names, bool append);
-
   protected:
 ConstString
 m_full; // Full name:   "+[NSString(my_additions) myStringWithCString:]"
@@ -105,6 +93,19 @@
 return lldb::eLanguageTypeObjC;
   }
 
+  // Get all possible names for a method. Examples:
+  // If method_name is "+[NSString(my_additions) myStringWithCString:]"
+  //   variant_names[0] => "+[NSString myStringWithCString:]"
+  // If name is specified without the leading '+' or '-' like
+  // "[NSString(my_additions) myStringWithCString:]"
+  //  variant_names[0] => "+[NSString(my_additions) myStringWithCString:]"
+  //  variant_names[1] => "-[NSString(my_additions) myStringWithCString:]"
+  //  variant_names[2] => "+[NSString myStringWithCString:]"
+  //  variant_names[3] => "-[NSString myStringWithCString:]"
+  void
+  GetVariantMethodNames(ConstString method_name,
+std::vector &variant_names) const override;
+
   lldb::TypeCategoryImplSP GetFormatters() override;
 
   std::vector
Index: source/Plugins/Language/ObjC/ObjCLanguage.cpp
===
--- source/Plugins/Language/ObjC/ObjCLanguage.cpp
+++ source/Plugins/Language/ObjC/ObjCLanguage.cpp
@@ -220,43 +220,43 @@
   return ConstString();
 }
 
-size_t ObjCLanguage::MethodName::GetFullNames(std::vector &names,
-  bool append) {
-  if (!append)
-names.clear();
-  if (IsValid(false)) {
+void ObjCLanguage::GetVariantMethodNames(
+ConstString method_name, std::vector &variant_names) const {
+  ObjCLanguage::MethodName objc_method(method_name.GetCString(), false);
+  if (!objc_method.IsValid(false)) {
+return;
+  }
+
+  const bool is_class_method =
+  objc_method.GetType() == MethodName::eTypeClassMethod;
+  const bool is_instance_method =
+  objc_method.GetType() == MethodName::eTypeInstanceMethod;
+  ConstString name_sans_category =
+  objc_method.GetFullNameWithoutCategory(/*empty_if_no_category*/ true);
+
+  if (is_class_method || is_instance_method) {
+if (name_sans_category)
+  variant_names.emplace_back(name_sans_category);
+  } else {
 StreamString strm;
-const bool is_class_method = m_type == eTypeClassMethod;
-const bool is_instance_method = m_type == eTypeInstanceMethod;
-ConstString category = GetCategory();
-if (is_class_method || is_instance_method) {
-  names.push_back(m_full);
-  if (category) {
-strm.Printf("%c[%s %s]", is_class_method ? '+' : '-',
-GetClassName().GetCString(), GetSelector().GetCString());
-names.emplace_back(strm.GetString());
-  }
-} else {
-  ConstString class_name = GetClassName();
-  ConstString selector = GetSelector();
-  strm.Printf("+[%s %s]", class_name.GetCString(), selector.GetCString());
-  names.emplace_back(strm.GetString());
-  strm.Clear();
-  strm.Printf("-[%s %s]", class_name.GetCString(), selector.GetCString());
-  names.emplace_back(strm.GetString());
+
+strm.Printf("+%s", objc_method.GetFullName().GetCString());
+variant_names.emplace_back(strm.GetString());
+strm.Clear();
+
+strm.Printf("-%s", objc_method.GetFullName().GetCString());
+variant_names.empla

[Lldb-commits] [PATCH] D61737: [lldb] add -ex CLI option as alias to --one-line

[Jonas Devlieghere via Phabricator via lldb-commits]

JDevlieghere added a comment.

Looks good to me. Added some reviewers to make sure everyone is fine with this.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D61737



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

[Lldb-commits] [PATCH] D61737: [lldb] add -ex CLI option as alias to --one-line

[Raphael Isemann via Phabricator via lldb-commits]

teemperor added a comment.

Not sure if I like this change. We don't have single dash flags with multiple 
characters in LLDB, so this flag looks a bit out of place. And there is the 
bigger question if we really want to be compatible with the GDB flags (which 
are already incompatible with the flags LLDB is currently offering). If we 
really go this way then I would suggest we also add more commonly used GDB 
flags like `--args`.




Comment at: lldb/tools/driver/Options.td:164
+  Alias,
+  HelpText<"Alias for --one-line. This exists just to ease adoption of LLDB 
for GDB users.">,
+  Group;

Usually alias don't have any motivation/description, so the "This exists just 
to ease adoption of LLDB for GDB users." isn't really necessary (and just 
clutters the help page IMHO).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D61737



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

[Lldb-commits] [PATCH] D61746: [Breakpoint] Make breakpoint language agnostic

[Jonas Devlieghere via Phabricator via lldb-commits]

JDevlieghere added inline comments.



Comment at: include/lldb/Target/Language.h:197
+  virtual void
+  GetVariantMethodNames(ConstString method_name,
+std::vector &variant_names) const {

GetMethodNameVariants? 



Comment at: source/Breakpoint/BreakpointResolverName.cpp:237
+
+  Language *lang = Language::FindPlugin(m_language);
+  if (!lang) {

You could write this as 

```
  if (Language *lang = Language::FindPlugin(m_language)) {
add_variant_funcs(lang);
  } else {
// Most likely m_language is eLanguageTypeUnknown. We check each language 
for
// possible variants or more qualified names and create lookups for those as
// well.
Language::ForEach(add_variant_funcs);
  }
```


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

https://reviews.llvm.org/D61746



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

[Lldb-commits] [PATCH] D61737: [lldb] add -ex CLI option as alias to --one-line

[Jan Kratochvil via Phabricator via lldb-commits]

jankratochvil added a comment.

In D61737#1497004 , @teemperor wrote:

> We don't have single dash flags with multiple characters in LLDB


OK, true.

> And there is the bigger question if we really want to be compatible with the 
> GDB flags

Then do you prefer `lldb --gdb -ex 'b foo' -ex r --args prog arg` (like `gdb 
--dbx`) or a different binary `lldb-gdb -ex 'b foo' -ex r --args prog arg`?

> If we really go this way then I would suggest we also add more commonly used 
> GDB flags like `--args`.

Yes, `--args` is also planned+needed.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D61737



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

[Lldb-commits] [PATCH] D61737: [lldb] add -ex CLI option as alias to --one-line

[Raphael Isemann via Phabricator via lldb-commits]

teemperor added a comment.

If it's just about adding some commonly used GDB flags I'm fine with adding 
them to the normal LLDB flags. If the plan is to implement most/all of the 
flags GDB supports, then I would prefer having something like `--gdb` or 
`lldb-gdb` (which seems anyway necessary to resolve the conflicts with the 
current LLDB flags like -x, -b, -l, etc.).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D61737



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

[Lldb-commits] [PATCH] D61752: Re-enable a test for non-Windows

[Paul Robinson via Phabricator via lldb-commits]

probinson created this revision.
probinson added reviewers: stella.stamenova, labath.
Herald added a project: LLDB.
Herald added a subscriber: lldb-commits.

Required teaching lit.cfg.py to distinguish Windows the same way other projects 
do.


Repository:
  rLLDB LLDB

https://reviews.llvm.org/D61752

Files:
  lldb/lit/Breakpoint/case-sensitive.test
  lldb/lit/lit.cfg.py


Index: lldb/lit/lit.cfg.py
===
--- lldb/lit/lit.cfg.py
+++ lldb/lit/lit.cfg.py
@@ -96,3 +96,7 @@
 config.available_features.add('native-cpu-%s' % x)
 else:
 lit_config.warning("lit-cpuid failed: %s" % err)
+
+# Allow distinguishing Windows host from others.
+if sys.platform.startswith('win') or sys.platform.startswith('cygwin'):
+config.available_features.add('windows')
Index: lldb/lit/Breakpoint/case-sensitive.test
===
--- lldb/lit/Breakpoint/case-sensitive.test
+++ lldb/lit/Breakpoint/case-sensitive.test
@@ -1,4 +1,4 @@
-# REQUIRES: nowindows
+# UNSUPPORTED: windows
 #
 # RUN: %build %p/Inputs/case-sensitive.c --nodefaultlib -o %t
 # RUN: lldb-test breakpoints %t %s | FileCheck %s


Index: lldb/lit/lit.cfg.py
===
--- lldb/lit/lit.cfg.py
+++ lldb/lit/lit.cfg.py
@@ -96,3 +96,7 @@
 config.available_features.add('native-cpu-%s' % x)
 else:
 lit_config.warning("lit-cpuid failed: %s" % err)
+
+# Allow distinguishing Windows host from others.
+if sys.platform.startswith('win') or sys.platform.startswith('cygwin'):
+config.available_features.add('windows')
Index: lldb/lit/Breakpoint/case-sensitive.test
===
--- lldb/lit/Breakpoint/case-sensitive.test
+++ lldb/lit/Breakpoint/case-sensitive.test
@@ -1,4 +1,4 @@
-# REQUIRES: nowindows
+# UNSUPPORTED: windows
 #
 # RUN: %build %p/Inputs/case-sensitive.c --nodefaultlib -o %t
 # RUN: lldb-test breakpoints %t %s | FileCheck %s
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D61752: Re-enable a test for non-Windows

[Stella Stamenova via Phabricator via lldb-commits]

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



Comment at: lldb/lit/Breakpoint/case-sensitive.test:1
-# REQUIRES: nowindows
+# UNSUPPORTED: windows
 #

This should be system-windows. See config.py in llvm. By using system-windows, 
the test would be consistent with other platforms. Incidentally, I am just 
about to fix this as well as the test in LLVM that you changed to use windows - 
it should also use system-windows.



Comment at: lldb/lit/lit.cfg.py:101
+# Allow distinguishing Windows host from others.
+if sys.platform.startswith('win') or sys.platform.startswith('cygwin'):
+config.available_features.add('windows')

This really should live in config.py in llvm so that it can be used across all 
projects. And it should be system-windows for consistency with other platforms.


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D61752



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

[Lldb-commits] [lldb] r360368 - Use UNSUPPORTED: system-windows instead of REQUIRES: nowindows or UNSUPPORTED: windows. nowindows is not currently defined and windows does not cover all cases. system-

[Stella Stamenova via lldb-commits]

Author: stella.stamenova
Date: Thu May  9 12:40:21 2019
New Revision: 360368

URL: http://llvm.org/viewvc/llvm-project?rev=360368&view=rev
Log:
Use UNSUPPORTED: system-windows instead of REQUIRES: nowindows or UNSUPPORTED: 
windows. nowindows is not currently defined and windows does not cover all 
cases. system-windows is also consistent with how other platforms are used.

Modified:
lldb/trunk/lit/Breakpoint/case-sensitive.test

Modified: lldb/trunk/lit/Breakpoint/case-sensitive.test
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/lit/Breakpoint/case-sensitive.test?rev=360368&r1=360367&r2=360368&view=diff
==
--- lldb/trunk/lit/Breakpoint/case-sensitive.test (original)
+++ lldb/trunk/lit/Breakpoint/case-sensitive.test Thu May  9 12:40:21 2019
@@ -1,4 +1,4 @@
-# REQUIRES: nowindows
+# UNSUPPORTED: system-windows
 #
 # RUN: %build %p/Inputs/case-sensitive.c --nodefaultlib -o %t
 # RUN: lldb-test breakpoints %t %s | FileCheck %s


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

[Lldb-commits] [lldb] r360371 - Fix TestVSCode_attach on Linux

[Stella Stamenova via lldb-commits]

Author: stella.stamenova
Date: Thu May  9 12:49:26 2019
New Revision: 360371

URL: http://llvm.org/viewvc/llvm-project?rev=360371&view=rev
Log:
Fix TestVSCode_attach on Linux

The test is failing sometimes because the debugger is failing to attach for 
lack of permissions. The fix is to call lldb_enable_attach inside the inferior 
main function

Modified:
lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-vscode/attach/main.c

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-vscode/attach/main.c
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-vscode/attach/main.c?rev=360371&r1=360370&r2=360371&view=diff
==
--- lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-vscode/attach/main.c 
(original)
+++ lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-vscode/attach/main.c 
Thu May  9 12:49:26 2019
@@ -1,8 +1,11 @@
 #include 
 #include 
 
-int main(int argc, char const *argv[]) {
-  printf("pid = %i\n", getpid());
-  sleep(10);
-  return 0; // breakpoint 1
+int main(int argc, char const *argv[])
+{
+lldb_enable_attach();
+
+printf("pid = %i\n", getpid());
+sleep(10);
+return 0; // breakpoint 1
 }


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

[Lldb-commits] [PATCH] D60153: Re-enable most lldb-vscode tests on Linux.

[Stella Stamenova via Phabricator via lldb-commits]

stella.stamenova added a comment.

Thanks, Pavel! I tested out the proposed change and all of our Ubuntu bots now 
work. I've committed it as well.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D60153



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

[Lldb-commits] [PATCH] D61752: Re-enable a test for non-Windows

[Paul Robinson via Phabricator via lldb-commits]

probinson abandoned this revision.
probinson added a comment.

@stella.stamenova  fixed this using system-windows instead.


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D61752



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

[Lldb-commits] [PATCH] D61733: Breakpad: Generate unwind plans from STACK CFI records

[Adrian McCarthy via Phabricator via lldb-commits]

amccarth accepted this revision.
amccarth added a comment.

LGTM once you double-check the return value in the error case at the end of 
`SymbolFileBreakpad::ParseUnwindRow`.




Comment at: source/Plugins/SymbolFile/Breakpad/SymbolFileBreakpad.cpp:472
+  if (!unwind_rules.empty())
+LLDB_LOG(log, "Could not parse `{0}` as an unwind rule.", unwind_rules);
+  return true;

Should the function return `false` when there are leftover unparsable rules?  
The other error cases seem to do that.


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

https://reviews.llvm.org/D61733



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

[Lldb-commits] [PATCH] D61746: [Breakpoint] Make breakpoint language agnostic

[Jim Ingham via Phabricator via lldb-commits]

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

That looks fine, thanks for untangling this.

I do like Jonas' suggestion better.  GetVariantMethodNames sounds like 
"VariantMethods" are a specific thing and you are trying to find their names, 
whereas this is just variants of the method name.  GetMethodNameVariants makes 
that clearer.

I was going to quibble a bit about "Method" since this can also happen for 
regular functions.  This isn't entirely theoretical, macOS used to used to have 
different variants of some of the standard library routines based on the 
whether the program was running in strict posix mode or had xmm registers, etc. 
 Then it had the kernel map in the little block of function pointers and used 
assembly tricks so the function name would call through this block.  In that 
case since lldb didn't know which instance of the function was going to be used 
we had to look for these variants and break on all of them.  That code is gone 
now - macOS switched to dynamic resolver functions instead.  But this would 
have been another use for these "Variants".

OTOH, I can't think of a good name for "callable entities" that isn't awful, so 
I'm fine with Method...


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

https://reviews.llvm.org/D61746



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

[Lldb-commits] [PATCH] D61737: [lldb] add -ex CLI option as alias to --one-line

[Jim Ingham via Phabricator via lldb-commits]

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

I would rather not clutter up the lldb command driver's options with gdb 
command flags.  That seems like it will make lldb harder to figure out and 
reduce our freedom to choose reasonable short names for lldb driver options.

It was reasonable to add lldb aliases for the gdb commands that you use tens to 
hundreds of times in a give debugging session - those get wired into your 
hands...  But I don't think the same consideration holds for command line 
options...

If we feel the need to add a driver gdb compatibility mode like this, I like 
Rafael's suggestion of:

lldb --gdb 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D61737



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

[Lldb-commits] [lldb] r360375 - Improve step over performance by not stopping at branches that are function calls and stepping into and them out of each one

[Greg Clayton via lldb-commits]

Author: gclayton
Date: Thu May  9 13:39:34 2019
New Revision: 360375

URL: http://llvm.org/viewvc/llvm-project?rev=360375&view=rev
Log:
Improve step over performance by not stopping at branches that are function 
calls and stepping into and them out of each one

Currently when we single step over a source line, we run and stop at every 
branch in the source line range. We can reduce the number of times we stop when 
stepping over by figuring out if any of these branches are function calls, and 
if so, ignore these branches. Since we are stepping over we can safely ignore 
these calls since they will return to the next instruction. Currently the step 
logic would stop at those branches (1st stop), single step into the branch (2nd 
stop), and then set a breakpoint at the return address (3rd stop), and then 
continue.

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


Modified:
lldb/trunk/include/lldb/Core/Disassembler.h

lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/require_hw_breakpoints/TestRequireHWBreakpoints.py
lldb/trunk/source/Core/Disassembler.cpp
lldb/trunk/source/Target/Process.cpp
lldb/trunk/source/Target/ThreadPlanStepRange.cpp

Modified: lldb/trunk/include/lldb/Core/Disassembler.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Core/Disassembler.h?rev=360375&r1=360374&r2=360375&view=diff
==
--- lldb/trunk/include/lldb/Core/Disassembler.h (original)
+++ lldb/trunk/include/lldb/Core/Disassembler.h Thu May  9 13:39:34 2019
@@ -290,8 +290,32 @@ public:
 
   lldb::InstructionSP GetInstructionAtIndex(size_t idx) const;
 
+  //--
+  /// Get the index of the next branch instruction.
+  ///
+  /// Given a list of instructions, find the next branch instruction
+  /// in the list by returning an index.
+  ///
+  /// @param[in] start
+  /// The instruction index of the first instruction to check.
+  ///
+  /// @param[in] target
+  /// A LLDB target object that is used to resolve addresses.
+  ///
+  /// @param[in] ignore_calls
+  /// It true, then fine the first branch instruction that isn't
+  /// a function call (a branch that calls and returns to the next
+  /// instruction). If false, find the instruction index of any 
+  /// branch in the list.
+  ///
+  /// @return
+  /// The instruction index of the first branch that is at or past
+  /// \a start. Returns UINT32_MAX if no matching branches are 
+  /// found.
+  //--
   uint32_t GetIndexOfNextBranchInstruction(uint32_t start,
-   Target &target) const;
+   Target &target,
+   bool ignore_calls) const;
 
   uint32_t GetIndexOfInstructionAtLoadAddress(lldb::addr_t load_addr,
   Target &target);

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/require_hw_breakpoints/TestRequireHWBreakpoints.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/require_hw_breakpoints/TestRequireHWBreakpoints.py?rev=360375&r1=360374&r2=360375&view=diff
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/require_hw_breakpoints/TestRequireHWBreakpoints.py
 (original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/require_hw_breakpoints/TestRequireHWBreakpoints.py
 Thu May  9 13:39:34 2019
@@ -79,12 +79,11 @@ class BreakpointLocationsTestCase(TestBa
 self.runCmd("settings set target.require-hardware-breakpoint true")
 
 # Step over doesn't fail immediately but fails later on.
-self.expect("thread step-over")
 self.expect(
-"process status",
+"thread step-over",
+error=True,
 substrs=[
-'step over failed',
-'Could not create hardware breakpoint for thread plan'
+'error: Could not create hardware breakpoint for thread plan.'
 ])
 
 @skipIfWindows

Modified: lldb/trunk/source/Core/Disassembler.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Core/Disassembler.cpp?rev=360375&r1=360374&r2=360375&view=diff
==
--- lldb/trunk/source/Core/Disassembler.cpp (original)
+++ lldb/trunk/source/Core/Disassembler.cpp Thu May  9 13:39:34 2019
@@ -1087,13 +1087,16 @@ void InstructionList::Append(lldb::Instr
 
 uint32_t
 InstructionList::GetIndexOfNextBranchInstruction(uint32_t start,
- Target &target) const {
+

[Lldb-commits] [PATCH] D58678: Improve step over performance by not stopping at branches that are function calls and stepping into and them out of each one

[Phabricator via Phabricator via lldb-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rLLDB360375: Improve step over performance by not stopping at 
branches that are function… (authored by gclayton, committed by ).

Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D58678

Files:
  include/lldb/Core/Disassembler.h
  
packages/Python/lldbsuite/test/functionalities/breakpoint/require_hw_breakpoints/TestRequireHWBreakpoints.py
  source/Core/Disassembler.cpp
  source/Target/Process.cpp
  source/Target/ThreadPlanStepRange.cpp

Index: source/Core/Disassembler.cpp
===
--- source/Core/Disassembler.cpp
+++ source/Core/Disassembler.cpp
@@ -1087,13 +1087,16 @@
 
 uint32_t
 InstructionList::GetIndexOfNextBranchInstruction(uint32_t start,
- Target &target) const {
+ Target &target,
+ bool ignore_calls) const {
   size_t num_instructions = m_instructions.size();
 
   uint32_t next_branch = UINT32_MAX;
   size_t i;
   for (i = start; i < num_instructions; i++) {
 if (m_instructions[i]->DoesBranch()) {
+  if (ignore_calls && m_instructions[i]->IsCall())
+continue;
   next_branch = i;
   break;
 }
Index: source/Target/Process.cpp
===
--- source/Target/Process.cpp
+++ source/Target/Process.cpp
@@ -5832,7 +5832,8 @@
   }
 
   uint32_t branch_index =
-  insn_list->GetIndexOfNextBranchInstruction(insn_offset, target);
+  insn_list->GetIndexOfNextBranchInstruction(insn_offset, target,
+ false /* ignore_calls*/);
   if (branch_index == UINT32_MAX) {
 return retval;
   }
Index: source/Target/ThreadPlanStepRange.cpp
===
--- source/Target/ThreadPlanStepRange.cpp
+++ source/Target/ThreadPlanStepRange.cpp
@@ -315,9 +315,10 @@
 return false;
   else {
 Target &target = GetThread().GetProcess()->GetTarget();
-uint32_t branch_index;
-branch_index =
-instructions->GetIndexOfNextBranchInstruction(pc_index, target);
+const bool ignore_calls = GetKind() == eKindStepOverRange;
+uint32_t branch_index =
+instructions->GetIndexOfNextBranchInstruction(pc_index, target,
+  ignore_calls);
 
 Address run_to_address;
 
Index: include/lldb/Core/Disassembler.h
===
--- include/lldb/Core/Disassembler.h
+++ include/lldb/Core/Disassembler.h
@@ -290,8 +290,32 @@
 
   lldb::InstructionSP GetInstructionAtIndex(size_t idx) const;
 
+  //--
+  /// Get the index of the next branch instruction.
+  ///
+  /// Given a list of instructions, find the next branch instruction
+  /// in the list by returning an index.
+  ///
+  /// @param[in] start
+  /// The instruction index of the first instruction to check.
+  ///
+  /// @param[in] target
+  /// A LLDB target object that is used to resolve addresses.
+  ///
+  /// @param[in] ignore_calls
+  /// It true, then fine the first branch instruction that isn't
+  /// a function call (a branch that calls and returns to the next
+  /// instruction). If false, find the instruction index of any 
+  /// branch in the list.
+  ///
+  /// @return
+  /// The instruction index of the first branch that is at or past
+  /// \a start. Returns UINT32_MAX if no matching branches are 
+  /// found.
+  //--
   uint32_t GetIndexOfNextBranchInstruction(uint32_t start,
-   Target &target) const;
+   Target &target,
+   bool ignore_calls) const;
 
   uint32_t GetIndexOfInstructionAtLoadAddress(lldb::addr_t load_addr,
   Target &target);
Index: packages/Python/lldbsuite/test/functionalities/breakpoint/require_hw_breakpoints/TestRequireHWBreakpoints.py
===
--- packages/Python/lldbsuite/test/functionalities/breakpoint/require_hw_breakpoints/TestRequireHWBreakpoints.py
+++ packages/Python/lldbsuite/test/functionalities/breakpoint/require_hw_breakpoints/TestRequireHWBreakpoints.py
@@ -79,12 +79,11 @@
 self.runCmd("settings set target.require-hardware-breakpoint true")
 
 # Step over doesn't fail immediately but fails later on.
-self.expect("thread step-over")
 self.expect(
-"process status",
+"thread step-over",
+error=True,
 substr

[Lldb-commits] [PATCH] D61759: Switch to FindSymbolsMatchingRegExAndType() from FindFunctions() in FindLibCppStdFunctionCallableInfo()

[Shafik Yaghmour via Phabricator via lldb-commits]

shafik created this revision.
shafik added reviewers: friss, jingham, jasonmolenda.

FindLibCppStdFunctionCallableInfo() currently uses FindFunctions() in order to 
find a lambdas `operator()()` but using `FindSymbolsMatchingRegExAndType()` is 
cheaper and if we also anchor the regex using `^` this adds some additional 
performance gains.


https://reviews.llvm.org/D61759

Files:
  source/Target/CPPLanguageRuntime.cpp


Index: source/Target/CPPLanguageRuntime.cpp
===
--- source/Target/CPPLanguageRuntime.cpp
+++ source/Target/CPPLanguageRuntime.cpp
@@ -241,8 +241,8 @@
 
   SymbolContextList scl;
 
-  target.GetImages().FindFunctions(RegularExpression{func_to_match}, true, 
true,
-   true, scl);
+  target.GetImages().FindSymbolsMatchingRegExAndType(
+  RegularExpression{R"(^)" + func_to_match}, eSymbolTypeAny, scl, true);
 
   // Case 1,2 or 3
   if (scl.GetSize() >= 1) {


Index: source/Target/CPPLanguageRuntime.cpp
===
--- source/Target/CPPLanguageRuntime.cpp
+++ source/Target/CPPLanguageRuntime.cpp
@@ -241,8 +241,8 @@
 
   SymbolContextList scl;
 
-  target.GetImages().FindFunctions(RegularExpression{func_to_match}, true, true,
-   true, scl);
+  target.GetImages().FindSymbolsMatchingRegExAndType(
+  RegularExpression{R"(^)" + func_to_match}, eSymbolTypeAny, scl, true);
 
   // Case 1,2 or 3
   if (scl.GetSize() >= 1) {
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D61746: [Breakpoint] Make breakpoint language agnostic

[Alex Langford via Phabricator via lldb-commits]

xiaobai added a comment.

Thanks for the feedback!

I don't quite feel that "Method" is a great descriptor here either, but I think 
that it's probably fine for now until we can think of a better name. I'll 
update this when I get the chance.


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

https://reviews.llvm.org/D61746



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

[Lldb-commits] [PATCH] D61746: [Breakpoint] Make breakpoint language agnostic

[Alex Langford via Phabricator via lldb-commits]

xiaobai updated this revision to Diff 198911.
xiaobai added a comment.

Rework function
GetVariantMethodNames -> GetMethodNameVariants


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

https://reviews.llvm.org/D61746

Files:
  include/lldb/Target/Language.h
  source/Breakpoint/BreakpointResolverName.cpp
  source/Breakpoint/CMakeLists.txt
  source/Plugins/Language/ObjC/ObjCLanguage.cpp
  source/Plugins/Language/ObjC/ObjCLanguage.h

Index: source/Plugins/Language/ObjC/ObjCLanguage.h
===
--- source/Plugins/Language/ObjC/ObjCLanguage.h
+++ source/Plugins/Language/ObjC/ObjCLanguage.h
@@ -73,18 +73,6 @@
 
 ConstString GetSelector();
 
-// Get all possible names for a method. Examples:
-// If name is "+[NSString(my_additions) myStringWithCString:]"
-//  names[0] => "+[NSString(my_additions) myStringWithCString:]"
-//  names[1] => "+[NSString myStringWithCString:]"
-// If name is specified without the leading '+' or '-' like
-// "[NSString(my_additions) myStringWithCString:]"
-//  names[0] => "+[NSString(my_additions) myStringWithCString:]"
-//  names[1] => "-[NSString(my_additions) myStringWithCString:]"
-//  names[2] => "+[NSString myStringWithCString:]"
-//  names[3] => "-[NSString myStringWithCString:]"
-size_t GetFullNames(std::vector &names, bool append);
-
   protected:
 ConstString
 m_full; // Full name:   "+[NSString(my_additions) myStringWithCString:]"
@@ -105,6 +93,19 @@
 return lldb::eLanguageTypeObjC;
   }
 
+  // Get all possible names for a method. Examples:
+  // If method_name is "+[NSString(my_additions) myStringWithCString:]"
+  //   variant_names[0] => "+[NSString myStringWithCString:]"
+  // If name is specified without the leading '+' or '-' like
+  // "[NSString(my_additions) myStringWithCString:]"
+  //  variant_names[0] => "+[NSString(my_additions) myStringWithCString:]"
+  //  variant_names[1] => "-[NSString(my_additions) myStringWithCString:]"
+  //  variant_names[2] => "+[NSString myStringWithCString:]"
+  //  variant_names[3] => "-[NSString myStringWithCString:]"
+  void
+  GetMethodNameVariants(ConstString method_name,
+std::vector &variant_names) const override;
+
   lldb::TypeCategoryImplSP GetFormatters() override;
 
   std::vector
Index: source/Plugins/Language/ObjC/ObjCLanguage.cpp
===
--- source/Plugins/Language/ObjC/ObjCLanguage.cpp
+++ source/Plugins/Language/ObjC/ObjCLanguage.cpp
@@ -220,43 +220,43 @@
   return ConstString();
 }
 
-size_t ObjCLanguage::MethodName::GetFullNames(std::vector &names,
-  bool append) {
-  if (!append)
-names.clear();
-  if (IsValid(false)) {
+void ObjCLanguage::GetMethodNameVariants(
+ConstString method_name, std::vector &variant_names) const {
+  ObjCLanguage::MethodName objc_method(method_name.GetCString(), false);
+  if (!objc_method.IsValid(false)) {
+return;
+  }
+
+  const bool is_class_method =
+  objc_method.GetType() == MethodName::eTypeClassMethod;
+  const bool is_instance_method =
+  objc_method.GetType() == MethodName::eTypeInstanceMethod;
+  ConstString name_sans_category =
+  objc_method.GetFullNameWithoutCategory(/*empty_if_no_category*/ true);
+
+  if (is_class_method || is_instance_method) {
+if (name_sans_category)
+  variant_names.emplace_back(name_sans_category);
+  } else {
 StreamString strm;
-const bool is_class_method = m_type == eTypeClassMethod;
-const bool is_instance_method = m_type == eTypeInstanceMethod;
-ConstString category = GetCategory();
-if (is_class_method || is_instance_method) {
-  names.push_back(m_full);
-  if (category) {
-strm.Printf("%c[%s %s]", is_class_method ? '+' : '-',
-GetClassName().GetCString(), GetSelector().GetCString());
-names.emplace_back(strm.GetString());
-  }
-} else {
-  ConstString class_name = GetClassName();
-  ConstString selector = GetSelector();
-  strm.Printf("+[%s %s]", class_name.GetCString(), selector.GetCString());
-  names.emplace_back(strm.GetString());
-  strm.Clear();
-  strm.Printf("-[%s %s]", class_name.GetCString(), selector.GetCString());
-  names.emplace_back(strm.GetString());
+
+strm.Printf("+%s", objc_method.GetFullName().GetCString());
+variant_names.emplace_back(strm.GetString());
+strm.Clear();
+
+strm.Printf("-%s", objc_method.GetFullName().GetCString());
+variant_names.emplace_back(strm.GetString());
+strm.Clear();
+
+if (name_sans_category) {
+  strm.Printf("+%s", name_sans_category.GetCString());
+  variant_names.emplace_back(strm.GetString());
   strm.Clear();
-  if (category) {
-strm.Printf("+[%s(%s) %s]", class_name.GetCString(),
-category.GetCString(), selector.GetCString());
-   

[Lldb-commits] [lldb] r360386 - [Docs] Port python reference page

[Jonas Devlieghere via lldb-commits]

Author: jdevlieghere
Date: Thu May  9 15:14:14 2019
New Revision: 360386

URL: http://llvm.org/viewvc/llvm-project?rev=360386&view=rev
Log:
[Docs] Port python reference page

I somehow forgot to port over this page from the old website. Thank you
Jim for the heads up!

Added:
lldb/trunk/docs/use/python-reference.rst
Modified:
lldb/trunk/docs/index.rst

Modified: lldb/trunk/docs/index.rst
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/docs/index.rst?rev=360386&r1=360385&r2=360386&view=diff
==
--- lldb/trunk/docs/index.rst (original)
+++ lldb/trunk/docs/index.rst Thu May  9 15:14:14 2019
@@ -40,6 +40,7 @@ Use & Extension
use/symbolication
use/symbols
use/python
+   use/python-reference
use/remote
use/troubleshooting
use/architecture

Added: lldb/trunk/docs/use/python-reference.rst
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/docs/use/python-reference.rst?rev=360386&view=auto
==
--- lldb/trunk/docs/use/python-reference.rst (added)
+++ lldb/trunk/docs/use/python-reference.rst Thu May  9 15:14:14 2019
@@ -0,0 +1,822 @@
+Python Reference
+
+
+The entire LLDB API is available as Python functions through a script bridging
+interface. This means the LLDB API's can be used directly from python either
+interactively or to build python apps that provide debugger features.
+
+Additionally, Python can be used as a programmatic interface within the lldb
+command interpreter (we refer to this for brevity as the embedded interpreter).
+Of course, in this context it has full access to the LLDB API - with some
+additional conveniences we will call out in the FAQ.
+
+.. contents::
+   :local:
+
+Documentation
+--
+
+The LLDB API is contained in a python module named lldb. A useful resource when
+writing Python extensions is the lldb Python classes reference guide.
+
+The documentation is also accessible in an interactive debugger session with
+the following command:
+
+::
+
+   (lldb) script help(lldb)
+  Help on package lldb:
+
+  NAME
+ lldb - The lldb module contains the public APIs for Python binding.
+
+  FILE
+ 
/System/Library/PrivateFrameworks/LLDB.framework/Versions/A/Resources/Python/lldb/__init__.py
+
+  DESCRIPTION
+   ...
+
+You can also get help using a module class name. The full API that is exposed
+for that class will be displayed in a man page style window. Below we want to
+get help on the lldb.SBFrame class:
+
+::
+
+   (lldb) script help(lldb.SBFrame)
+  Help on class SBFrame in module lldb:
+
+  class SBFrame(__builtin__.object)
+  |  Represents one of the stack frames associated with a thread.
+  |  SBThread contains SBFrame(s). For example (from test/lldbutil.py),
+  |
+  |  def print_stacktrace(thread, string_buffer = False):
+  |  '''Prints a simple stack trace of this thread.'''
+  |
+   ...
+
+Or you can get help using any python object, here we use the lldb.process
+object which is a global variable in the lldb module which represents the
+currently selected process:
+
+::
+
+   (lldb) script help(lldb.process)
+  Help on SBProcess in module lldb object:
+
+  class SBProcess(__builtin__.object)
+  |  Represents the process associated with the target program.
+  |
+  |  SBProcess supports thread iteration. For example (from 
test/lldbutil.py),
+  |
+  |  # ==
+  |  # Utility functions related to Threads and Processes
+  |  # ==
+  |
+   ...
+
+Embedded Python Interpreter
+---
+
+The embedded python interpreter can be accessed in a variety of ways from
+within LLDB. The easiest way is to use the lldb command script with no
+arguments at the lldb command prompt:
+
+::
+
+   (lldb) script
+   Python Interactive Interpreter. To exit, type 'quit()', 'exit()' or Ctrl-D.
+   >>> 2+3
+   5
+   >>> hex(12345)
+   '0x3039'
+   >>>
+
+This drops you into the embedded python interpreter. When running under the
+script command, lldb sets some convenience variables that give you quick access
+to the currently selected entities that characterize the program and debugger
+state. In each case, if there is no currently selected entity of the
+appropriate type, the variable's IsValid method will return false. These
+variables are:
+
++---+-+-+
+| Variable  | Type| Description
 |
++---+-+-+
+| **lldb.debugge

[Lldb-commits] Fwd: buildbot failure in LLVM on lldb-x64-windows-ninja

[Greg Clayton via lldb-commits]

Can anyone that builds the windows lldb compile the following file as the test 
suite would:

trunk/packages/Python/lldbsuite/test/python_api/thread/main2.cpp

and send me the binary that is produced by the test suite? 

I see the windows bot is failing and need to see binary that we produce so I 
can disassemble and see what is going wrong.

Greg


> Begin forwarded message:
> 
> From: llvm.buildmas...@lab.llvm.org
> Subject: buildbot failure in LLVM on lldb-x64-windows-ninja
> Date: May 9, 2019 at 2:16:02 PM PDT
> To: Alex Lorenz , Greg Clayton 
> Cc: gkistan...@gmail.com
> 
> The Buildbot has detected a new failure on builder lldb-x64-windows-ninja 
> while building cfe.
> Full details are available at:
> http://lab.llvm.org:8011/builders/lldb-x64-windows-ninja/builds/4523
> 
> Buildbot URL: http://lab.llvm.org:8011/
> 
> Buildslave for this Build: win-py3-buildbot
> 
> Build Reason: scheduler
> Build Source Stamp: [branch trunk] 360375
> Blamelist: arphaman,gclayton
> 
> BUILD FAILED: failed test
> 
> sincerely,
> -The Buildbot
> 
> 
> 

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

[Lldb-commits] [PATCH] D61090: [SBHostOS} Remove getting the python script interpreter path

[Jonas Devlieghere via Phabricator via lldb-commits]

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

Move the function into SBDebugger


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

https://reviews.llvm.org/D61090

Files:
  lldb/include/lldb/API/SBDebugger.h
  lldb/include/lldb/API/SBFileSpec.h
  lldb/include/lldb/API/SBHostOS.h
  lldb/include/lldb/Interpreter/ScriptInterpreter.h
  lldb/source/API/SBDebugger.cpp
  lldb/source/API/SBHostOS.cpp
  lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.h
  lldb/tools/driver/Driver.cpp

Index: lldb/tools/driver/Driver.cpp
===
--- lldb/tools/driver/Driver.cpp
+++ lldb/tools/driver/Driver.cpp
@@ -391,7 +391,7 @@
   }
 
   if (m_option_data.m_print_python_path) {
-SBFileSpec python_file_spec = SBHostOS::GetLLDBPythonPath();
+SBFileSpec python_file_spec = m_debugger.GetScriptDirectory();
 if (python_file_spec.IsValid()) {
   char python_path[PATH_MAX];
   size_t num_chars = python_file_spec.GetPath(python_path, PATH_MAX);
Index: lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.h
===
--- lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.h
+++ lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.h
@@ -46,6 +46,8 @@
   static const char *GetPluginDescriptionStatic();
   static FileSpec GetPythonDir();
 
+  virtual FileSpec GetModuleDirectory() { return GetPythonDir(); };
+
 protected:
   static void ComputePythonDirForApple(llvm::SmallVectorImpl &path);
   static void ComputePythonDirForPosix(llvm::SmallVectorImpl &path);
Index: lldb/source/API/SBHostOS.cpp
===
--- lldb/source/API/SBHostOS.cpp
+++ lldb/source/API/SBHostOS.cpp
@@ -60,9 +60,7 @@
 fspec = HostInfo::GetHeaderDir();
 break;
   case ePathTypePythonDir:
-#ifndef LLDB_DISABLE_PYTHON
-fspec = ScriptInterpreterPython::GetPythonDir();
-#endif
+// Deprecated. Use SBCommandInpterpreter::GetScriptModuleDirectory instead.
 break;
   case ePathTypeLLDBSystemPlugins:
 fspec = HostInfo::GetSystemPluginDir();
Index: lldb/source/API/SBDebugger.cpp
===
--- lldb/source/API/SBDebugger.cpp
+++ lldb/source/API/SBDebugger.cpp
@@ -577,6 +577,19 @@
   llvm::StringRef(script_language_name), eScriptLanguageDefault, nullptr);
 }
 
+lldb::SBFileSpec SBDebugger::GetScriptDirectory() const {
+  if (!m_opaque_sp)
+return {};
+
+  ScriptInterpreter *script_interpreter =
+  m_opaque_sp->GetScriptInterpreter(true);
+
+  if (!script_interpreter)
+return {};
+
+  return SBFileSpec(script_interpreter->GetModuleDirectory());
+}
+
 const char *SBDebugger::GetVersionString() {
   LLDB_RECORD_STATIC_METHOD_NO_ARGS(const char *, SBDebugger, GetVersionString);
 
Index: lldb/include/lldb/Interpreter/ScriptInterpreter.h
===
--- lldb/include/lldb/Interpreter/ScriptInterpreter.h
+++ lldb/include/lldb/Interpreter/ScriptInterpreter.h
@@ -467,6 +467,8 @@
 
   lldb::ScriptLanguage GetLanguage() { return m_script_lang; }
 
+  virtual FileSpec GetModuleDirectory() { return {}; };
+
 protected:
   Debugger &m_debugger;
   lldb::ScriptLanguage m_script_lang;
Index: lldb/include/lldb/API/SBHostOS.h
===
--- lldb/include/lldb/API/SBHostOS.h
+++ lldb/include/lldb/API/SBHostOS.h
@@ -18,6 +18,7 @@
 public:
   static lldb::SBFileSpec GetProgramFileSpec();
 
+  // Deprecated. Use SBCommandInpterpreter::GetScriptModuleDirectory instead.
   static lldb::SBFileSpec GetLLDBPythonPath();
 
   static lldb::SBFileSpec GetLLDBPath(lldb::PathType path_type);
Index: lldb/include/lldb/API/SBFileSpec.h
===
--- lldb/include/lldb/API/SBFileSpec.h
+++ lldb/include/lldb/API/SBFileSpec.h
@@ -61,6 +61,7 @@
   friend class SBBlock;
   friend class SBCommandInterpreter;
   friend class SBCompileUnit;
+  friend class SBDebugger;
   friend class SBDeclaration;
   friend class SBFileSpecList;
   friend class SBHostOS;
Index: lldb/include/lldb/API/SBDebugger.h
===
--- lldb/include/lldb/API/SBDebugger.h
+++ lldb/include/lldb/API/SBDebugger.h
@@ -180,6 +180,9 @@
 
   lldb::ScriptLanguage GetScriptingLanguage(const char *script_language_name);
 
+  /// Return the module path for the script interpreter, if one is registered.
+  lldb::SBFileSpec GetScriptDirectory() const;
+
   static const char *GetVersionString();
 
   static const char *StateAsCString(lldb::StateType state);
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D61501: 02/06: Finish renaming CompileUnit->Unit

[Jonas Devlieghere via Phabricator via lldb-commits]

JDevlieghere accepted this revision.
JDevlieghere added a comment.

LGTM with Pavel's comment addressed.


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D61501



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

[Lldb-commits] [lldb] r360397 - Disable the step over skipping calls feature since buildbots are not happy.

[Greg Clayton via lldb-commits]

Author: gclayton
Date: Thu May  9 17:13:03 2019
New Revision: 360397

URL: http://llvm.org/viewvc/llvm-project?rev=360397&view=rev
Log:
Disable the step over skipping calls feature since buildbots are not happy.


Modified:
lldb/trunk/source/Core/Disassembler.cpp

Modified: lldb/trunk/source/Core/Disassembler.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Core/Disassembler.cpp?rev=360397&r1=360396&r2=360397&view=diff
==
--- lldb/trunk/source/Core/Disassembler.cpp (original)
+++ lldb/trunk/source/Core/Disassembler.cpp Thu May  9 17:13:03 2019
@@ -1095,8 +1095,8 @@ InstructionList::GetIndexOfNextBranchIns
   size_t i;
   for (i = start; i < num_instructions; i++) {
 if (m_instructions[i]->DoesBranch()) {
-  if (ignore_calls && m_instructions[i]->IsCall())
-continue;
+//  if (ignore_calls && m_instructions[i]->IsCall())
+//continue;
   next_branch = i;
   break;
 }


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

[Lldb-commits] [lldb] r360398 - [Docs] Fix table formatting in Pytho reference

[Jonas Devlieghere via lldb-commits]

Author: jdevlieghere
Date: Thu May  9 17:23:02 2019
New Revision: 360398

URL: http://llvm.org/viewvc/llvm-project?rev=360398&view=rev
Log:
[Docs] Fix table formatting in Pytho reference

Modified:
lldb/trunk/docs/use/python-reference.rst

Modified: lldb/trunk/docs/use/python-reference.rst
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/docs/use/python-reference.rst?rev=360398&r1=360397&r2=360398&view=diff
==
--- lldb/trunk/docs/use/python-reference.rst (original)
+++ lldb/trunk/docs/use/python-reference.rst Thu May  9 17:23:02 2019
@@ -98,38 +98,38 @@ state. In each case, if there is no curr
 appropriate type, the variable's IsValid method will return false. These
 variables are:
 
-+---+-+-+
-| Variable  | Type| Description
 |
-+---+-+-+
-| **lldb.debugger** | **lldb.SBDebugger** | Contains the debugger object whose 
**script** command was invoked.  |
-|   | | The 
**lldb.SBDebugger** object owns the command interpreter 
|
-|   | | and all the targets in 
your debug session.  There will always be a  |
-|   | | Debugger in the 
embedded interpreter.   |
-+---+-+-+
-| **lldb.target**   | **lldb.SBTarget**   | Contains the currently selected 
target - for instance the one made with the |
-|   | | **file** or selected 
by the **target select ** command.   |
-|   | | The **lldb.SBTarget** 
manages one running process, and all the executable   |
-|   | | and debug files for 
the process.|
-+---+-+-+
-| **lldb.process**  | **lldb.SBProcess**  | Contains the process of the 
currently selected target.  |
-|   | | The **lldb.SBProcess** 
object manages the threads and allows access to  |
-|   | | memory for the 
process. |
-+---+-+-+
-| **lldb.thread**   | **lldb.SBThread**   | Contains the currently selected 
thread. |
-|   | | The **lldb.SBThread** 
object manages the stack frames in that thread.   |
-|   | | A thread is always 
selected in the command interpreter when a target stops. |
-|   | | The **thread select 
** command can be used to change the  |
-|   | | currently selected 
thread.  So as long as you have a stopped process, there will be |
-|   | | some selected thread.  
 |
-+---+-+-+
-| **lldb.frame**| **lldb.SBFrame**| Contains the currently selected 
stack frame.|
-|   | | The **lldb.SBFrame** 
object manage the stack locals and the register set for|
-|   | | that stack.
 |
-|   | | A stack frame is 
always selected in the command interpreter when a target stops.|
-|   | | The **frame select 
** command can be used to change the|
-|   | | currently selected 
frame.  So as l

[Lldb-commits] [PATCH] D61733: Breakpad: Generate unwind plans from STACK CFI records

[Jason Molenda via Phabricator via lldb-commits]

jasonmolenda accepted this revision.
jasonmolenda added inline comments.



Comment at: source/Plugins/SymbolFile/Breakpad/SymbolFileBreakpad.cpp:418
+  if (name == ".ra")
+return resolver.ResolveNumber(eRegisterKindGeneric, 
LLDB_REGNUM_GENERIC_PC);
+  return ResolveRegister(resolver, name);

labath wrote:
> clayborg wrote:
> > LLDB_REGNUM_GENERIC_RA? Do we want the PC here or do we want the link 
> > register?
> It looks a bit weird, but I believe it should be the PC (and I have checked 
> that things unwind correctly this way), because we are specifying value for 
> the PC in the parent frame (which is the same as the return address of the 
> current frame). Or, to put it another way, breakpad uses ".ra" even on 
> platforms which do not have a LLDB_REGNUM_GENERIC_RA register (like x86).
This is fine, fwiw RegisterContextLLDB won't try to use LLDB_REGNUM_GENERIC_RA 
on architectures that don't use a return address register (e.g. lr on arm), so 
using LLDB_REGNUM_GENERIC_PC is correct if we ever need to do this unwind on an 
x86 breakpad file.


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

https://reviews.llvm.org/D61733



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

[Lldb-commits] [PATCH] D61732: FuncUnwinders: Add a new "SymbolFile" unwind plan

[Jason Molenda via Phabricator via lldb-commits]

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

Looks good to me.

Yes, we need to change from a model of "the remote stub teaches lldb everything 
about registers" to "lldb knows all the architectural / ABI register number 
details, asks the remote stub what numbers it uses for them when connected".  
The need to go through RegisterContext::ConvertBetweenRegisterKinds / 
RegisterContext::GetRegisterInfoAtIndex to get any information about registers 
is unfortunate.

I'm not super concerned about the size of the UnwindPlan or FuncUnwinders 
objects - we create them lazily as we unwind through functions in the process, 
so my guess is that even a long-running debug session will have on the order of 
thousands of these objects.  The ABIs don't even bother to issue a single 
ArchDefault unwind plan and FunctionEntry unwind plan, handing out a new one 
for each FuncUnwinders object (ok that part is a little embarrassing, but again 
this isn't super high on the priority list to fix imo.)


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

https://reviews.llvm.org/D61732



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

[Lldb-commits] [PATCH] D58678: Improve step over performance by not stopping at branches that are function calls and stepping into and them out of each one

[Jim Ingham via Phabricator via lldb-commits]

jingham added a comment.

The one outstanding bit of work here is that this change requires that the 
MSInst "IsCall" function has to mean "will return to the next instruction after 
call" or we might lose control of the program.  It seems obvious that that 
SHOULD be what it means, but we need to make sure that is always going to be 
what it means or we risk losing control of the program.  Greg is going to 
follow up on that.

If we have that assurance then this is a great change, a little because it 
avoids the extra stop and start and even more because it means we don't have to 
be so disciplined about never doing any work when we newly arrive in a frame.  
I've had to squash bugs where we start to get debug info for a function we have 
no intention of stopping in, which can really slow down stepping in a big 
program to no purpose.


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D58678



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

[Lldb-commits] [PATCH] D61776: [Target] Generalize some behavior in Thread

[Alex Langford via Phabricator via lldb-commits]

xiaobai created this revision.
xiaobai added reviewers: davide, JDevlieghere, jingham, kubamracek, clayborg.

I don't think there's a good reason for this behavior to be considered
ObjC-specific. We can generalize this.


https://reviews.llvm.org/D61776

Files:
  source/Target/Thread.cpp


Index: source/Target/Thread.cpp
===
--- source/Target/Thread.cpp
+++ source/Target/Thread.cpp
@@ -2209,25 +2209,27 @@
   if (auto e = recognized_frame->GetExceptionObject())
 return e;
 
-  // FIXME: For now, only ObjC exceptions are supported. This should really
-  // iterate over all language runtimes and ask them all to give us the current
-  // exception.
-  if (auto runtime = GetProcess()->GetObjCLanguageRuntime())
-if (auto e = runtime->GetExceptionObjectForThread(shared_from_this()))
-  return e;
+  for (unsigned lang = eLanguageTypeUnknown; lang < eNumLanguageTypes; lang++) 
{
+if (auto runtime = GetProcess()->GetLanguageRuntime(
+static_cast(lang)))
+  if (auto e = runtime->GetExceptionObjectForThread(shared_from_this()))
+return e;
+  }
 
   return ValueObjectSP();
 }
 
 ThreadSP Thread::GetCurrentExceptionBacktrace() {
   ValueObjectSP exception = GetCurrentException();
-  if (!exception) return ThreadSP();
+  if (!exception)
+return ThreadSP();
 
-  // FIXME: For now, only ObjC exceptions are supported. This should really
-  // iterate over all language runtimes and ask them all to give us the current
-  // exception.
-  auto runtime = GetProcess()->GetObjCLanguageRuntime();
-  if (!runtime) return ThreadSP();
+  for (unsigned lang = eLanguageTypeUnknown; lang < eNumLanguageTypes; lang++) 
{
+if (auto runtime = GetProcess()->GetLanguageRuntime(
+static_cast(lang)))
+  if (auto bt = runtime->GetBacktraceThreadFromException(exception))
+return bt;
+  }
 
-  return runtime->GetBacktraceThreadFromException(exception);
+  return ThreadSP();
 }


Index: source/Target/Thread.cpp
===
--- source/Target/Thread.cpp
+++ source/Target/Thread.cpp
@@ -2209,25 +2209,27 @@
   if (auto e = recognized_frame->GetExceptionObject())
 return e;
 
-  // FIXME: For now, only ObjC exceptions are supported. This should really
-  // iterate over all language runtimes and ask them all to give us the current
-  // exception.
-  if (auto runtime = GetProcess()->GetObjCLanguageRuntime())
-if (auto e = runtime->GetExceptionObjectForThread(shared_from_this()))
-  return e;
+  for (unsigned lang = eLanguageTypeUnknown; lang < eNumLanguageTypes; lang++) {
+if (auto runtime = GetProcess()->GetLanguageRuntime(
+static_cast(lang)))
+  if (auto e = runtime->GetExceptionObjectForThread(shared_from_this()))
+return e;
+  }
 
   return ValueObjectSP();
 }
 
 ThreadSP Thread::GetCurrentExceptionBacktrace() {
   ValueObjectSP exception = GetCurrentException();
-  if (!exception) return ThreadSP();
+  if (!exception)
+return ThreadSP();
 
-  // FIXME: For now, only ObjC exceptions are supported. This should really
-  // iterate over all language runtimes and ask them all to give us the current
-  // exception.
-  auto runtime = GetProcess()->GetObjCLanguageRuntime();
-  if (!runtime) return ThreadSP();
+  for (unsigned lang = eLanguageTypeUnknown; lang < eNumLanguageTypes; lang++) {
+if (auto runtime = GetProcess()->GetLanguageRuntime(
+static_cast(lang)))
+  if (auto bt = runtime->GetBacktraceThreadFromException(exception))
+return bt;
+  }
 
-  return runtime->GetBacktraceThreadFromException(exception);
+  return ThreadSP();
 }
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D61737: [lldb] add -ex CLI option as alias to --one-line

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

Selecting the option parsing mode explicitly sounds like the way to go to me 
too. I'm wondering if we should call it `--driver-mode=gdb` to match the 
equivalent functionality in clang. Having a symlink (lldb-gdb or whatever) 
which automatically selects "gdb" as the "driver mode" also sounds reasonable.

> lldb --gdb 

I wouldn't make this positional because clang's --driver-mode arg also isn't 
positional (it applies to the whole command line, even args that come before 
it). Also making this positional would open the door to having both kinds of 
options present at once, which is going to make parsing a lot more complicated 
(and it probably wouldn't be a very useful feature anyway).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D61737



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

[Lldb-commits] [PATCH] D61746: [Breakpoint] Make breakpoint language agnostic

[Pavel Labath via Phabricator via lldb-commits]

labath added inline comments.



Comment at: include/lldb/Target/Language.h:198
+  GetMethodNameVariants(ConstString method_name,
+std::vector &variant_names) const {
+return;

Return the vector by value ?


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

https://reviews.llvm.org/D61746



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

[Lldb-commits] [PATCH] D61778: [Docs] Replace SVN revisions with lldb versions

[Dave Lee via Phabricator via lldb-commits]

kastiglione created this revision.
kastiglione added a reviewer: JDevlieghere.
Herald added a project: LLDB.
Herald added a subscriber: lldb-commits.

Replaces references to svn commits with the lldb version number those commits 
first appeared in. Themotivation is to show that these features are no longer 
that new and can generally be adopted.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D61778

Files:
  lldb/docs/use/python-reference.rst


Index: lldb/docs/use/python-reference.rst
===
--- lldb/docs/use/python-reference.rst
+++ lldb/docs/use/python-reference.rst
@@ -494,10 +494,9 @@
   """This command takes a lot of options and does many fancy things"""
   # Your code goes here
 
-Starting with SVN revision 218834, LLDB Python commands can also take an
-SBExecutionContext as an argument. This is useful in cases where the command's
-notion of where to act is independent of the currently-selected entities in the
-debugger.
+Since lldb 3.5.2, LLDB Python commands can also take an SBExecutionContext as 
an
+argument. This is useful in cases where the command's notion of where to act is
+independent of the currently-selected entities in the debugger.
 
 This feature is enabled if the command-implementing function can be recognized
 as taking 5 arguments, or a variable number of arguments, and it alters the
@@ -519,7 +518,7 @@
 
+---++--+
 | **exe_ctx**   | **lldb.SBExecutionContext**| An execution context 
object carrying around information on the inferior process' context in which 
the command is expected to act |
 |   || 

 |
-|   || *Optional since SVN 
r218834, unavailable before*
 |
+|   || *Optional since lldb 
3.5.2, unavailable before*  
|
 
+---++--+
 | **result**| **lldb.SBCommandReturnObject** | A return object which 
encapsulates success/failure information for the command and output text
   |
 |   || that needs to be 
printed as a result of the command. The plain Python "print" command also works 
but |
@@ -529,8 +528,8 @@
 |   || and functions.  

 |
 
+---++--+
 
-Starting with SVN revision 232224, Python commands can also be implemented by
-means of a class which should implement the following interface:
+Since lldb 3.7, Python commands can also be implemented by means of a class
+which should implement the following interface:
 
 ::
 


Index: lldb/docs/use/python-reference.rst
===
--- lldb/docs/use/python-reference.rst
+++ lldb/docs/use/python-reference.rst
@@ -494,10 +494,9 @@
   """This command takes a lot of options and does many fancy things"""
   # Your code goes here
 
-Starting with SVN revision 218834, LLDB Python commands can also take an
-SBExecutionContext as an argument. This is useful in cases where the command's
-notion of where to act is independent of the currently-selected entities in the
-debugger.
+Since lldb 3.5.2, LLDB Python commands can also take an SBExecutionContext as an
+argument. This is useful in cases where the command's notion of where to act is
+independent of the currently-selected entities in the debugger.
 
 This feature is enabled if the command-implementing function can be recognized
 as taking 5 arguments, or a variable number of arguments, and it alters the
@@ -519,7 +518,7 @@
 +---++--+
 | **exe_ctx**   | **lldb.SBExecutionContext**| An execution context object carrying around information on the inferior process' context in which the command is expected to act |
 |   |  

[Lldb-commits] [lldb] r360407 - Revert "Disable the step over skipping calls feature since buildbots are not happy."

[Pavel Labath via lldb-commits]

Author: labath
Date: Thu May  9 23:57:25 2019
New Revision: 360407

URL: http://llvm.org/viewvc/llvm-project?rev=360407&view=rev
Log:
Revert "Disable the step over skipping calls feature since buildbots are not 
happy."

While this fixed the windows bot failures, it also broke all other bots.

Upon closer inspection, it turns out that the windows bots were "broken"
because two tests were unexpectedly passing -- i.e., the original patch
(r360375) actually improved our stepping support on windows.

So instead, I remove the relevant XFAILs.

This reverts commit r360397.

Modified:

lldb/trunk/packages/Python/lldbsuite/test/functionalities/command_script/TestCommandScript.py
lldb/trunk/packages/Python/lldbsuite/test/python_api/thread/TestThreadAPI.py
lldb/trunk/source/Core/Disassembler.cpp

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/command_script/TestCommandScript.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/command_script/TestCommandScript.py?rev=360407&r1=360406&r2=360407&view=diff
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/command_script/TestCommandScript.py
 (original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/command_script/TestCommandScript.py
 Thu May  9 23:57:25 2019
@@ -17,7 +17,6 @@ class CmdPythonTestCase(TestBase):
 mydir = TestBase.compute_mydir(__file__)
 NO_DEBUG_INFO_TESTCASE = True
 
-@expectedFailureAll(oslist=["windows"], bugnumber="llvm.org/pr32343")
 def test(self):
 self.build()
 self.pycmd_tests()

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/python_api/thread/TestThreadAPI.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/python_api/thread/TestThreadAPI.py?rev=360407&r1=360406&r2=360407&view=diff
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/python_api/thread/TestThreadAPI.py 
(original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/python_api/thread/TestThreadAPI.py 
Thu May  9 23:57:25 2019
@@ -52,7 +52,6 @@ class ThreadAPITestCase(TestBase):
 self.step_out_of_malloc_into_function_b(self.exe_name)
 
 @add_test_categories(['pyapi'])
-@expectedFailureAll(oslist=["windows"], bugnumber='llvm.org/pr32343')
 def test_step_over_3_times(self):
 """Test Python SBThread.StepOver() API."""
 # We build a different executable than the default build() does.

Modified: lldb/trunk/source/Core/Disassembler.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Core/Disassembler.cpp?rev=360407&r1=360406&r2=360407&view=diff
==
--- lldb/trunk/source/Core/Disassembler.cpp (original)
+++ lldb/trunk/source/Core/Disassembler.cpp Thu May  9 23:57:25 2019
@@ -1095,8 +1095,8 @@ InstructionList::GetIndexOfNextBranchIns
   size_t i;
   for (i = start; i < num_instructions; i++) {
 if (m_instructions[i]->DoesBranch()) {
-//  if (ignore_calls && m_instructions[i]->IsCall())
-//continue;
+  if (ignore_calls && m_instructions[i]->IsCall())
+continue;
   next_branch = i;
   break;
 }


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