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

2019-04-25 Thread Pavel Labath via Phabricator via lldb-commits
labath added a comment.

I'm going to throw one more opinion into the mix here. :)

While I agree that sprinkling `#ifdef PYTHON` everywhere is bad, and it's great 
to be rid of it, I also think that it is good for the user to be able to know 
how a particular build of lldb was configured. So, I wouldn't say this goes 
"against the  notion of a generic pluggable interpreter". In fact I would say 
the opposite. In an imaginary future where lldb can be built with either python 
or say javascript support (or both?), it may be very important for programs to 
detect whether the library they are using is compatible with them.

The question on my mind is "do we ever want/anticipate the python path to 
change at runtime?". If we don't, then getting the path value through a command 
interpreter *instance* seems odd. In fact, I would say that the SBHostOS is the 
best place to provide this info, as it is really a property of the host, which 
does not depend on any runtime configuration of anything. So, if the only  
reason you made this go through the command interpreter class was to break the 
build dependency, then I think we should do this another way. One way to handle 
this would be to add one more argument to the PluginManager::RegisterPlugin 
function which is called from ScriptInterpreterPython::Initialize. This 
argument could be either a callback which computes the "module path" for the 
given language, or even the path itself. Then SBHostOS could just get the path 
by asking the PluginManager.

So, with both backward and forward compatibility in mind, what I'd to is this:

- don't add any new SB interfaces
- implement `SBHostOS::GetLLDBPythonPath` via a call to 
`PluginManager::GetModulePathFor(eScriptLanguagePython)` as described previously
- In the future, once multiple interpreters become a reality, consider a new 
SBHostOS function, which takes a language type as an argument. This will allow 
the user to determine which scripting languages are available and leave the 
door open for a single build of lldb to support multiple languages (which the 
current proposal doesn't). `SBHostOS::GetLLDBPythonPath` then just becomes a 
deprecated variant of this new function.


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

https://reviews.llvm.org/D61090



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


[Lldb-commits] [PATCH] D60962: [NativePDB] Extend .pdb files search folders

2019-04-25 Thread Mikhail Senkov via Phabricator via lldb-commits
zloyrobot marked 2 inline comments as done.
zloyrobot added inline comments.



Comment at: lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.cpp:110
+
+static std::string findPdbFile(const llvm::StringRef exe_path, const 
llvm::StringRef pdb_file, llvm::file_magic &magic) {
+  auto ec = llvm::identify_magic(pdb_file, magic);

labath wrote:
> I find the interface of this function odd. First, the `const`s on the 
> StringRef argument are useless and should be removed. Secondly, the by-ref 
> return of the `magic` argument is something that would be nice to avoid. It 
> looks like that could easily be done here by just checking whether the file 
> exists and doing the identify_magic check in the caller (if you want an 
> existing-but-not-pdb file to abort the search), or by checking the signature 
> in this function (if you want to skip past non-pdb files). Also, this patch 
> could use clang-formatting as this line is over the column limit.
I want to skip past non-pdb files. Am I understand correctly that you suggest 
me to get rid of file_magic parameter and call identify_magic (open and read 
pdb file) additional time (in caller)? 



Comment at: lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.cpp:111
+static std::string findPdbFile(const llvm::StringRef exe_path, const 
llvm::StringRef pdb_file, llvm::file_magic &magic) {
+  auto ec = llvm::identify_magic(pdb_file, magic);
+  if (!ec)

labath wrote:
> Llvm policy is to use `auto` "if and only if it makes the code more readable" 
> .
>  Whether that's the case here is somewhat subjective, but I'd say that none 
> of the uses of auto in this patch are helping readability, as all the types 
> used in this patch are short enough and spelling them out saves the reader 
> from guessing whether `ec` really is a `std::error_code`, etc.
Please note that I moved  ```auto ec = ...```  from original Turner's code 


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D60962



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


[Lldb-commits] [PATCH] D59537: Instantiate 'std' templates explicitly in the expression evaluator

2019-04-25 Thread Raphael Isemann via Phabricator via lldb-commits
teemperor marked an inline comment as done.
teemperor added inline comments.



Comment at: lldb/source/Symbol/StdModuleHandler.cpp:242
+// Instantiate the template.
+found_decl = ClassTemplateSpecializationDecl::Create(
+m_sema->getASTContext(),

martong wrote:
> martong wrote:
> > Is there any guarantee that the before any subsequent 
> > clang::ASTImporter::Import call this newly created node is registered as 
> > imported (via ASTImporter::MapImported)?
> > 
> > The reason why I am asking this is because we have to enforce in 
> > clang::ASTImporter that after every Decl is created then immediately it is 
> > registered as an imported Decl, see `ASTImporter::GetImportedOrCreateDecl`. 
> > This we we make sure that no subsequent import calls will create the same 
> > node again.
> > The cycles in the AST are handled properly only this way.
> > 
> > This is one reason which makes me worried about exposing the import 
> > mechanism via `ImportInternal`.  Would it be working if 
> > `GetImportedOrCreateDecl` was virtual and overridden here?
> > Would it be working if GetImportedOrCreateDecl was virtual and overridden 
> > here?
> 
> Sorry, that would certainly not work, but perhaps a virtual hook inside that 
> function could work...
Sorry for the late reply.

So I was looking into changing the code to your suggestion, but I don't think 
we can get this working reliably. The problem is that if we intercept the 
importing in GetImportedOrCreateDecl then we need to intercept not just 
`std::vector` but also all related imports that the ASTImporter may make before 
importing `std::vector` itself, e.g. DeclContext, parent classes, return type, 
template args, etc. Also we constantly would need to update this list in case 
the standard library or the ASTImporter change internally to make sure we 
intercept everything.

Maybe we could instead implement an mechanism in the LLDB code that ensures we 
do call MapImported and add the decl to the lookup directly after creating a 
decl? E.g. by implementing something similar to ASTImporter's 
`GetImportedOrCreateDecl`?


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

https://reviews.llvm.org/D59537



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


[Lldb-commits] [PATCH] D60962: [NativePDB] Extend .pdb files search folders

2019-04-25 Thread Pavel Labath via Phabricator via lldb-commits
labath added a subscriber: zturner.
labath added inline comments.



Comment at: lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.cpp:110
+
+static std::string findPdbFile(const llvm::StringRef exe_path, const 
llvm::StringRef pdb_file, llvm::file_magic &magic) {
+  auto ec = llvm::identify_magic(pdb_file, magic);

zloyrobot wrote:
> labath wrote:
> > I find the interface of this function odd. First, the `const`s on the 
> > StringRef argument are useless and should be removed. Secondly, the by-ref 
> > return of the `magic` argument is something that would be nice to avoid. It 
> > looks like that could easily be done here by just checking whether the file 
> > exists and doing the identify_magic check in the caller (if you want an 
> > existing-but-not-pdb file to abort the search), or by checking the 
> > signature in this function (if you want to skip past non-pdb files). Also, 
> > this patch could use clang-formatting as this line is over the column limit.
> I want to skip past non-pdb files. Am I understand correctly that you suggest 
> me to get rid of file_magic parameter and call identify_magic (open and read 
> pdb file) additional time (in caller)? 
In that case, what you could do is get rid of the `magic` as an argument, and 
change this function to return a valid result, only if you found the file *and* 
that files magic number is correct. (note that this is not what the current 
implementation does)



Comment at: lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.cpp:111
+static std::string findPdbFile(const llvm::StringRef exe_path, const 
llvm::StringRef pdb_file, llvm::file_magic &magic) {
+  auto ec = llvm::identify_magic(pdb_file, magic);
+  if (!ec)

zloyrobot wrote:
> labath wrote:
> > Llvm policy is to use `auto` "if and only if it makes the code more 
> > readable" 
> > .
> >  Whether that's the case here is somewhat subjective, but I'd say that none 
> > of the uses of auto in this patch are helping readability, as all the types 
> > used in this patch are short enough and spelling them out saves the reader 
> > from guessing whether `ec` really is a `std::error_code`, etc.
> Please note that I moved  ```auto ec = ...```  from original Turner's code 
yeah, I know, but that doesn't make it right. :) In fact, based on a random 
sample, I would guess that about 90% of uses of `auto ec` in llvm is @zturner's 
code. :P

TBH, the `ec` is no the part I'm having problems with the most. If it was just 
that, I wouldn't mention it, but the fact that you're using it all over the 
place tells me you weren't aware of llvm's policy regarding `auto` (which 
explicitly states "don't 'almost always use auto'"), and I figured it's best to 
mention that early on. 


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D60962



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


[Lldb-commits] [PATCH] D60962: [NativePDB] Extend .pdb files search folders

2019-04-25 Thread Mikhail Senkov via Phabricator via lldb-commits
zloyrobot updated this revision to Diff 196614.

Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D60962

Files:
  lldb/lit/SymbolFile/NativePDB/Inputs/pdb-file-lookup.lldbinit
  lldb/lit/SymbolFile/NativePDB/pdb-file-lookup.cpp
  lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.cpp

Index: lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.cpp
===
--- lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.cpp
+++ lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.cpp
@@ -106,6 +106,45 @@
   return File;
 }
 
+
+static std::string findPdbFile(llvm::StringRef exe_path, 
+   llvm::StringRef pdb_file) {
+  llvm::file_magic magic;
+  std::error_code ec = llvm::identify_magic(pdb_file, magic);
+  if (!ec && magic == llvm::file_magic::pdb)
+return pdb_file;
+
+  llvm::StringRef pdb_file_name = llvm::sys::path::filename(pdb_file);
+
+  llvm::SmallString<128> path = exe_path;
+  llvm::sys::path::remove_filename(path);
+  llvm::sys::path::append(path, pdb_file_name);
+
+  ec = llvm::identify_magic(path, magic);
+  if (!ec && magic == llvm::file_magic::pdb)
+return path.str();
+
+  llvm::StringRef nt_symbol_path = ::getenv("_NT_SYMBOL_PATH");
+  llvm::SmallVector parts;
+  nt_symbol_path.split(parts, ';', -1, false);
+
+  for (llvm::StringRef part_ref : parts)  {
+if (part_ref.startswith_lower("srv*")) {
+  //Symbol servers is not supported yet
+  continue;
+}
+
+path = part_ref;
+llvm::sys::path::append(path, pdb_file_name);
+
+ec = llvm::identify_magic(path, magic);
+if (!ec && magic == llvm::file_magic::pdb) {
+  return path.str();
+}
+  }
+
+  return {};
+}
 static std::unique_ptr
 loadMatchingPDBFile(std::string exe_path, llvm::BumpPtrAllocator &allocator) {
   // Try to find a matching PDB for an EXE.
@@ -130,13 +169,13 @@
   if (ec)
 return nullptr;
 
+  auto pdb_full_path = findPdbFile(exe_path, pdb_file);
+
   // if the file doesn't exist, is not a pdb, or doesn't have a matching guid,
   // fail.
-  llvm::file_magic magic;
-  ec = llvm::identify_magic(pdb_file, magic);
-  if (ec || magic != llvm::file_magic::pdb)
+  if (pdb_full_path.empty())
 return nullptr;
-  std::unique_ptr pdb = loadPDBFile(pdb_file, allocator);
+  std::unique_ptr pdb = loadPDBFile(pdb_full_path, allocator);
   if (!pdb)
 return nullptr;
 
Index: lldb/lit/SymbolFile/NativePDB/pdb-file-lookup.cpp
===
--- /dev/null
+++ lldb/lit/SymbolFile/NativePDB/pdb-file-lookup.cpp
@@ -0,0 +1,31 @@
+// clang-format off
+// REQUIRES: lld
+
+// Test that we can find .pdb file in _NT_SYMBOL_PATH folder. 
+// RUN: %build --compiler=clang-cl --nodefaultlib -o %t.exe -- %s 
+// RUN: mkdir -p %t
+// RUN: mv %t.pdb %t/pdb-file-lookup.cpp.tmp.pdb
+// RUN: env _NT_SYMBOL_PATH=%t LLDB_USE_NATIVE_PDB_READER=1 %lldb -f %t.exe -s \
+// RUN: %p/Inputs/pdb-file-lookup.lldbinit | FileCheck %s
+//
+// Test that we can find .pdb file in folder containing .exe file.
+// RUN: mv %t.exe %t/pdb-file-lookup.cpp.tmp.exe
+// RUN: env LLDB_USE_NATIVE_PDB_READER=1 %lldb -f \
+// RUN: %t/pdb-file-lookup.cpp.tmp.exe -s \
+// RUN: %p/Inputs/pdb-file-lookup.lldbinit | FileCheck %s
+
+
+
+int main(int argc, char **argv) {
+  // Here are some comments.
+  return 0;
+}
+
+// CHECK: (lldb) source list -n main
+// CHECK: File: {{.*}}pdb-file-lookup.cpp
+// CHECK:18
+// CHECK:19   int main(int argc, char **argv) {
+// CHECK:20 // Here are some comments.
+// CHECK:21 return 0;
+// CHECK:22   }
+// CHECK:23
Index: lldb/lit/SymbolFile/NativePDB/Inputs/pdb-file-lookup.lldbinit
===
--- /dev/null
+++ lldb/lit/SymbolFile/NativePDB/Inputs/pdb-file-lookup.lldbinit
@@ -0,0 +1,2 @@
+source list -n main
+quit
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [PATCH] D60962: [NativePDB] Extend .pdb files search folders

2019-04-25 Thread Mikhail Senkov via Phabricator via lldb-commits
zloyrobot marked 2 inline comments as done.
zloyrobot added inline comments.



Comment at: lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.cpp:110
+
+static std::string findPdbFile(const llvm::StringRef exe_path, const 
llvm::StringRef pdb_file, llvm::file_magic &magic) {
+  auto ec = llvm::identify_magic(pdb_file, magic);

labath wrote:
> zloyrobot wrote:
> > labath wrote:
> > > I find the interface of this function odd. First, the `const`s on the 
> > > StringRef argument are useless and should be removed. Secondly, the 
> > > by-ref return of the `magic` argument is something that would be nice to 
> > > avoid. It looks like that could easily be done here by just checking 
> > > whether the file exists and doing the identify_magic check in the caller 
> > > (if you want an existing-but-not-pdb file to abort the search), or by 
> > > checking the signature in this function (if you want to skip past non-pdb 
> > > files). Also, this patch could use clang-formatting as this line is over 
> > > the column limit.
> > I want to skip past non-pdb files. Am I understand correctly that you 
> > suggest me to get rid of file_magic parameter and call identify_magic (open 
> > and read pdb file) additional time (in caller)? 
> In that case, what you could do is get rid of the `magic` as an argument, and 
> change this function to return a valid result, only if you found the file 
> *and* that files magic number is correct. (note that this is not what the 
> current implementation does)
got it, thanks



Comment at: lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.cpp:111
+static std::string findPdbFile(const llvm::StringRef exe_path, const 
llvm::StringRef pdb_file, llvm::file_magic &magic) {
+  auto ec = llvm::identify_magic(pdb_file, magic);
+  if (!ec)

labath wrote:
> zloyrobot wrote:
> > labath wrote:
> > > Llvm policy is to use `auto` "if and only if it makes the code more 
> > > readable" 
> > > .
> > >  Whether that's the case here is somewhat subjective, but I'd say that 
> > > none of the uses of auto in this patch are helping readability, as all 
> > > the types used in this patch are short enough and spelling them out saves 
> > > the reader from guessing whether `ec` really is a `std::error_code`, etc.
> > Please note that I moved  ```auto ec = ...```  from original Turner's code 
> yeah, I know, but that doesn't make it right. :) In fact, based on a random 
> sample, I would guess that about 90% of uses of `auto ec` in llvm is 
> @zturner's code. :P
> 
> TBH, the `ec` is no the part I'm having problems with the most. If it was 
> just that, I wouldn't mention it, but the fact that you're using it all over 
> the place tells me you weren't aware of llvm's policy regarding `auto` (which 
> explicitly states "don't 'almost always use auto'"), and I figured it's best 
> to mention that early on. 
Thanks for the clarifications, I updated the path


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D60962



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


[Lldb-commits] [PATCH] D60519: [Windows] Dump more information about access violation exception

2019-04-25 Thread Leonid Mashinskiy via Phabricator via lldb-commits
leonid.mashinskiy added a comment.

Ping!
Are these changes accepted ?


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D60519



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


[Lldb-commits] [PATCH] D61128: Fix stack unwinding for struct methods

2019-04-25 Thread Mikhail Senkov via Phabricator via lldb-commits
zloyrobot created this revision.
zloyrobot added reviewers: amccarth, aleksandr.urakov.
zloyrobot added a project: LLDB.
Herald added subscribers: lldb-commits, teemperor.

Repository:
  rLLDB LLDB

https://reviews.llvm.org/D61128

Files:
  lldb/lit/SymbolFile/NativePDB/Inputs/stack_unwinding01.lldbinit
  lldb/lit/SymbolFile/NativePDB/stack_unwinding01.cpp
  lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.cpp
  lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.h

Index: lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.h
===
--- lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.h
+++ lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.h
@@ -180,6 +180,9 @@
   lldb::TypeSP CreateArrayType(PdbTypeSymId type_id,
const llvm::codeview::ArrayRecord &ar,
CompilerType ct);
+  lldb::TypeSP CreateFunctionType(PdbTypeSymId type_id,
+  const llvm::codeview::MemberFunctionRecord &pr,
+  CompilerType ct);
   lldb::TypeSP CreateProcedureType(PdbTypeSymId type_id,
const llvm::codeview::ProcedureRecord &pr,
CompilerType ct);
Index: lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.cpp
===
--- lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.cpp
+++ lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.cpp
@@ -595,6 +595,17 @@
   return array_sp;
 }
 
+
+TypeSP SymbolFileNativePDB::CreateFunctionType(PdbTypeSymId type_id,
+   const MemberFunctionRecord &mfr,
+   CompilerType ct) {
+  Declaration decl;
+  return std::make_shared(
+  toOpaqueUid(type_id), this, ConstString(), 0, nullptr, LLDB_INVALID_UID,
+  lldb_private::Type::eEncodingIsUID, decl, ct,
+  lldb_private::Type::eResolveStateFull);
+}
+
 TypeSP SymbolFileNativePDB::CreateProcedureType(PdbTypeSymId type_id,
 const ProcedureRecord &pr,
 CompilerType ct) {
@@ -655,6 +666,11 @@
 llvm::cantFail(TypeDeserializer::deserializeAs(cvt, pr));
 return CreateProcedureType(type_id, pr, ct);
   }
+  if (cvt.kind() == LF_MFUNCTION) {
+MemberFunctionRecord mfr;
+llvm::cantFail(TypeDeserializer::deserializeAs(cvt, mfr));
+return CreateFunctionType(type_id, mfr, ct);
+  }
 
   return nullptr;
 }
Index: lldb/lit/SymbolFile/NativePDB/stack_unwinding01.cpp
===
--- /dev/null
+++ lldb/lit/SymbolFile/NativePDB/stack_unwinding01.cpp
@@ -0,0 +1,48 @@
+// clang-format off
+// REQUIRES: lld
+
+// RUN: %build --compiler=clang-cl --nodefaultlib -o %t.exe -- %s
+// RUN: env LLDB_USE_NATIVE_PDB_READER=1 %lldb -f %t.exe -s \
+// RUN: %p/Inputs/stack_unwinding01.lldbinit 2>&1 | FileCheck %s
+
+
+struct Struct {
+  void simple_method(int a, int b) {
+ a += 1;
+ simple_method(a, b);
+  }
+};
+
+
+
+int main(int argc, char **argv) {
+  Struct s;
+  s.simple_method(1,2);
+  return 0;
+}
+
+
+// CHECK: (lldb) thread backtrace
+// CHECK-NEXT: * thread #1, stop reason = breakpoint 1.1
+// CHECK-NEXT:   * frame #0: {{.*}} stack_unwinding01.cpp.tmp.exe`Struct::simple_method at stack_unwinding01.cpp:12
+// CHECK-NEXT: frame #1: {{.*}} stack_unwinding01.cpp.tmp.exe`main(argc={{.*}}, argv={{.*}}) at stack_unwinding01.cpp:20
+// CHECK-NEXT: frame #2: {{.*}} kernel32.dll`BaseThreadInitThunk + 34
+// CHECK-NEXT: frame #3: {{.*}} ntdll.dll`RtlUserThreadStart + 52
+
+
+// CHECK: (lldb) thread backtrace
+// CHECK-NEXT: * thread #1, stop reason = breakpoint 1.1
+// CHECK-NEXT:   * frame #0: {{.*}} stack_unwinding01.cpp.tmp.exe`Struct::simple_method at stack_unwinding01.cpp:12
+// CHECK-NEXT: frame #1: {{.*}} stack_unwinding01.cpp.tmp.exe`Struct::simple_method at stack_unwinding01.cpp:12
+// CHECK-NEXT: frame #2: {{.*}} stack_unwinding01.cpp.tmp.exe`main(argc={{.*}}, argv={{.*}}) at stack_unwinding01.cpp:20
+// CHECK-NEXT: frame #3: {{.*}} kernel32.dll`BaseThreadInitThunk + 34
+// CHECK-NEXT: frame #4: {{.*}} ntdll.dll`RtlUserThreadStart + 52
+
+// CHECK: (lldb) thread backtrace
+// CHECK-NEXT: * thread #1, stop reason = breakpoint 1.1
+// CHECK-NEXT:   * frame #0: {{.*}} stack_unwinding01.cpp.tmp.exe`Struct::simple_method at stack_unwinding01.cpp:12
+// CHECK-NEXT: frame #1: {{.*}} stack_unwinding01.cpp.tmp.exe`Struct::simple_method at stack_unwinding01.cpp:12
+// CHECK-NEXT: frame #2: {{.*}} stack_unwinding01.cpp.tmp.exe`Struct::simple_method at stack_unwinding01.cpp:12
+// CHECK-NEXT: frame #3: {{.*}} stack_unwinding01.cpp.tmp.exe`main(argc={{.*}}, argv={{.*}}) at stack_unwinding01.

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

2019-04-25 Thread Greg Clayton via Phabricator via lldb-commits
clayborg added a comment.

I agree with Pavel: no new SB APIs needed as this call is where it is supposed 
to be on SBHostOS.


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

https://reviews.llvm.org/D61090



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


[Lldb-commits] [PATCH] D61085: [lldb] [lit] Remove unnecessary array use in XMM reading test

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

This looks like the kind of thing you could have committed without review. :)


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

https://reviews.llvm.org/D61085



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


[Lldb-commits] [PATCH] D61072: [lldb] [lit] Add tests for reading new x86_64 registers

2019-04-25 Thread Pavel Labath via Phabricator via lldb-commits
labath accepted this revision.
labath added inline comments.
This revision is now accepted and ready to land.



Comment at: lldb/lit/Register/Inputs/x86-64-read.cpp:8
+int main() {
+  uint64_t r8 = 0x0102030405060708;
+  uint64_t r9 = 0x1112131415161718;

what do you think about including r0-r7 too? They're of different sizes on x86 
vs x86_64, so I don't think we'll be able to have a single test which would 
work on both arches.


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

https://reviews.llvm.org/D61072



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


[Lldb-commits] [PATCH] D61072: [lldb] [lit] Add tests for reading new x86_64 registers

2019-04-25 Thread Michał Górny via Phabricator via lldb-commits
mgorny added inline comments.



Comment at: lldb/lit/Register/Inputs/x86-64-read.cpp:8
+int main() {
+  uint64_t r8 = 0x0102030405060708;
+  uint64_t r9 = 0x1112131415161718;

labath wrote:
> what do you think about including r0-r7 too? They're of different sizes on 
> x86 vs x86_64, so I don't think we'll be able to have a single test which 
> would work on both arches.
Do you mean RAX, RBX, etc.? Yeah, I suppose I can do that.


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

https://reviews.llvm.org/D61072



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


[Lldb-commits] [PATCH] D61074: [lldb] [lit] Add register read tests for YMM registers (AVX)

2019-04-25 Thread Pavel Labath via Phabricator via lldb-commits
labath added a comment.

This test is pretty much a reimplementation of TestYMMRegisters dotest test. I 
like this one more for several reasons, but if we're going to check this in, we 
should also delete the other one.


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

https://reviews.llvm.org/D61074



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


[Lldb-commits] [PATCH] D61073: [lldb] [lit] Add feature flags for native CPU features

2019-04-25 Thread Pavel Labath via Phabricator via lldb-commits
labath added a reviewer: JDevlieghere.
labath added a subscriber: JDevlieghere.
labath added a comment.

I like this approach, but as this is a novel idea, I'd like to get more 
opinions first. @JDevlieghere, what do you think?




Comment at: lldb/lit/lit.cfg.py:81
+cpuid_exe = lit.util.which('lit-cpuid', config.lldb_tools_dir)
+if cpuid_exe is not None:
+out, err, exitcode = lit.util.executeCommand([cpuid_exe])

So if the binary is not found for any reason, this will just silently skip the 
relevant tests, right? Would it make sense to at least print a warning in this 
case?


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

https://reviews.llvm.org/D61073



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


[Lldb-commits] [PATCH] D61073: [lldb] [lit] Add feature flags for native CPU features

2019-04-25 Thread Michał Górny via Phabricator via lldb-commits
mgorny marked an inline comment as done.
mgorny added inline comments.



Comment at: lldb/lit/lit.cfg.py:81
+cpuid_exe = lit.util.which('lit-cpuid', config.lldb_tools_dir)
+if cpuid_exe is not None:
+out, err, exitcode = lit.util.executeCommand([cpuid_exe])

labath wrote:
> So if the binary is not found for any reason, this will just silently skip 
> the relevant tests, right? Would it make sense to at least print a warning in 
> this case?
Yes, it will skip them. I don't have an opinion on whether it's something we 
should warn about; but I can surely add one.


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

https://reviews.llvm.org/D61073



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


[Lldb-commits] [PATCH] D61072: [lldb] [lit] Add tests for reading new x86_64 registers

2019-04-25 Thread Pavel Labath via Phabricator via lldb-commits
labath added inline comments.



Comment at: lldb/lit/Register/Inputs/x86-64-read.cpp:8
+int main() {
+  uint64_t r8 = 0x0102030405060708;
+  uint64_t r9 = 0x1112131415161718;

mgorny wrote:
> labath wrote:
> > what do you think about including r0-r7 too? They're of different sizes on 
> > x86 vs x86_64, so I don't think we'll be able to have a single test which 
> > would work on both arches.
> Do you mean RAX, RBX, etc.? Yeah, I suppose I can do that.
Yep, those. %rip might be interesting too. I mean, it's so fundamental that 
we're bound to notice if reading it ever breaks, but it might be nice to have 
an test which clearly indicates what the problem is. You'll probably have a 
hard time setting it to  a known value, but you might be able to test it via 
relationship with some other registers (e.g. %rax == (%rip << 32) & (%rip >> 
32)).


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

https://reviews.llvm.org/D61072



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


[Lldb-commits] [PATCH] D61073: [lldb] [lit] Add feature flags for native CPU features

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

I really like this too, it's conceptually simple, easy to use and allows us to 
write more tests in lit. Thanks for doing this Michał.




Comment at: lldb/lit/lit.cfg.py:81
+cpuid_exe = lit.util.which('lit-cpuid', config.lldb_tools_dir)
+if cpuid_exe is not None:
+out, err, exitcode = lit.util.executeCommand([cpuid_exe])

mgorny wrote:
> labath wrote:
> > So if the binary is not found for any reason, this will just silently skip 
> > the relevant tests, right? Would it make sense to at least print a warning 
> > in this case?
> Yes, it will skip them. I don't have an opinion on whether it's something we 
> should warn about; but I can surely add one.
I agree it would be good to print a warning. We're the ones building the tool 
so there's really no good reason for it not to be found. 


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

https://reviews.llvm.org/D61073



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


[Lldb-commits] [PATCH] D61056: PostfixExpression: move DWARF generator out of NativePDB internals

2019-04-25 Thread Pavel Labath via Phabricator via lldb-commits
labath updated this revision to Diff 196665.
labath marked an inline comment as done.
labath added a comment.

- simplify symbol resolution even more
- drop the NativePDB unittest changes


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

https://reviews.llvm.org/D61056

Files:
  include/lldb/Symbol/PostfixExpression.h
  source/Plugins/SymbolFile/NativePDB/PdbFPOProgramToDWARFExpression.cpp
  source/Symbol/PostfixExpression.cpp
  unittests/Symbol/PostfixExpressionTest.cpp

Index: unittests/Symbol/PostfixExpressionTest.cpp
===
--- unittests/Symbol/PostfixExpressionTest.cpp
+++ unittests/Symbol/PostfixExpressionTest.cpp
@@ -7,6 +7,9 @@
 //===--===//
 
 #include "lldb/Symbol/PostfixExpression.h"
+#include "lldb/Expression/DWARFExpression.h"
+#include "lldb/Utility/DataExtractor.h"
+#include "lldb/Utility/StreamString.h"
 #include "llvm/Support/FormatVariadic.h"
 #include "llvm/Support/raw_ostream.h"
 #include "gtest/gtest.h"
@@ -95,3 +98,55 @@
   EXPECT_EQ("nullptr", ParseAndStringify("1 2"));
   EXPECT_EQ("nullptr", ParseAndStringify(""));
 }
+
+static std::string ParseAndGenerateDWARF(llvm::StringRef expr) {
+  llvm::BumpPtrAllocator alloc;
+  Node *ast = Parse(expr, alloc);
+  if (!ast)
+return "Parse failed.";
+  if (!ResolveSymbols(ast, [&](SymbolNode &symbol) -> Node * {
+uint32_t num;
+if (to_integer(symbol.GetName().drop_front(), num))
+  return MakeNode(alloc, num);
+return nullptr;
+  })) {
+return "Resolution failed.";
+  }
+
+  const size_t addr_size = 4;
+  StreamString dwarf(Stream::eBinary, addr_size, lldb::eByteOrderLittle);
+  ToDWARF(*ast, dwarf);
+
+  // print dwarf expression to comparable textual representation
+  DataExtractor extractor(dwarf.GetData(), dwarf.GetSize(),
+  lldb::eByteOrderLittle, addr_size);
+
+  StreamString result;
+  if (!DWARFExpression::PrintDWARFExpression(result, extractor, addr_size,
+ /*dwarf_ref_size*/ 4,
+ /*location_expression*/ false)) {
+return "DWARF printing failed.";
+  }
+
+  return result.GetString();
+}
+
+TEST(PostfixExpression, ToDWARF) {
+  EXPECT_EQ("DW_OP_constu 0x0", ParseAndGenerateDWARF("0"));
+
+  EXPECT_EQ("DW_OP_breg1 +0", ParseAndGenerateDWARF("R1"));
+
+  EXPECT_EQ("DW_OP_bregx 65 0", ParseAndGenerateDWARF("R65"));
+
+  EXPECT_EQ("DW_OP_constu 0x4, DW_OP_constu 0x5, DW_OP_plus ",
+ParseAndGenerateDWARF("4 5 +"));
+
+  EXPECT_EQ("DW_OP_constu 0x4, DW_OP_constu 0x5, DW_OP_minus ",
+ParseAndGenerateDWARF("4 5 -"));
+
+  EXPECT_EQ("DW_OP_constu 0x4, DW_OP_deref ", ParseAndGenerateDWARF("4 ^"));
+
+  EXPECT_EQ("DW_OP_breg6 +0, DW_OP_constu 0x80, DW_OP_lit1 "
+", DW_OP_minus , DW_OP_not , DW_OP_and ",
+ParseAndGenerateDWARF("R6 128 @"));
+}
Index: source/Symbol/PostfixExpression.cpp
===
--- source/Symbol/PostfixExpression.cpp
+++ source/Symbol/PostfixExpression.cpp
@@ -12,6 +12,8 @@
 //===--===//
 
 #include "lldb/Symbol/PostfixExpression.h"
+#include "lldb/Core/dwarf.h"
+#include "lldb/Utility/Stream.h"
 #include "llvm/ADT/StringExtras.h"
 
 using namespace lldb_private;
@@ -80,3 +82,121 @@
 
   return stack.back();
 }
+
+namespace {
+class SymbolResolver : public Visitor {
+public:
+  SymbolResolver(llvm::function_ref replacer)
+  : m_replacer(replacer) {}
+
+  using Visitor::Dispatch;
+
+private:
+  bool Visit(BinaryOpNode &binary, Node *&) override {
+return Dispatch(binary.Left()) && Dispatch(binary.Right());
+  }
+
+  bool Visit(IntegerNode &integer, Node *&) override { return true; }
+  bool Visit(RegisterNode ®, Node *&) override { return true; }
+
+  bool Visit(SymbolNode &symbol, Node *&ref) override {
+if (Node *replacement = m_replacer(symbol)) {
+  ref = replacement;
+  if (replacement != &symbol)
+return Dispatch(ref);
+  return true;
+}
+return false;
+  }
+
+  bool Visit(UnaryOpNode &unary, Node *&) override {
+return Dispatch(unary.Operand());
+  }
+
+  llvm::function_ref m_replacer;
+};
+
+class DWARFCodegen : public Visitor<> {
+public:
+  DWARFCodegen(Stream &stream) : m_out_stream(stream) {}
+
+  using Visitor<>::Dispatch;
+
+private:
+  void Visit(BinaryOpNode &binary, Node *&);
+
+  void Visit(IntegerNode &integer, Node *&) {
+m_out_stream.PutHex8(DW_OP_constu);
+m_out_stream.PutULEB128(integer.GetValue());
+  }
+
+  void Visit(RegisterNode ®, Node *&);
+
+  void Visit(SymbolNode &symbol, Node *&) {
+llvm_unreachable("Symbols should have been resolved by now!");
+  }
+
+  void Visit(UnaryOpNode &unary, Node *&);
+
+  Stream &m_out_stream;
+};
+} // namespace
+
+void DWARFCodegen::Visit(B

[Lldb-commits] [PATCH] D61056: PostfixExpression: move DWARF generator out of NativePDB internals

2019-04-25 Thread Pavel Labath via Phabricator via lldb-commits
labath marked 4 inline comments as done.
labath added a comment.

In D61056#1477914 , @amccarth wrote:

> Can the test deletions be a separate patch, or will they fail because of the 
> other changes in this patch?  They feel like a good but separable step.


Nope, the tests still pass, they just felt superfluous. I'll remove them in a 
separate patch.




Comment at: include/lldb/Symbol/PostfixExpression.h:216
+  /// nullptr, if unable to replace/resolve.
+  virtual Node *Replace(SymbolNode &symbol) = 0;
+};

amccarth wrote:
> I'm confused why this takes `symbol` by (non-const) ref.  Is `symbol` 
> modified in the process of figuring out what should replace it?
> 
> Oh, peeking ahead at the implementation, I see it can return the address of 
> `symbol`.  I'm left wondering whether there's a less confusing API.
Yeah, I too had the feeling that there ought to be a simpler way to do this, 
but I couldn't figure out how until now...

Check out the new version of the patch. Now, instead of having to subclass 
something one can implement a trivial search-and-replace operation by just 
passing a callback to the function. (There is subclassing going on under the 
hood, but the user is unaware of that).

In fact, it made things so simple, I just decided to merge the two-pass 
algorithm in NativePDB into a single function.



Comment at: 
source/Plugins/SymbolFile/NativePDB/PdbFPOProgramToDWARFExpression.cpp:46
+  Node *result = it->second;
+  Dispatch(result); // Recursively process the result.
+  return result;// And return it.

amccarth wrote:
> If I understand correctly, we don't care about the return value of `Dispatch` 
> because all that matters is whether `result` points to a valid `Node` or is 
> just `nullptr`.  Right?
> 
> If so, then should `SymbolResolver ` derive from `Visitor` rather than 
> `Visitor`?
Not exactly. The fact whether is the replacement function returned nullptr is 
then propagated up the Dispatch function, and eventually makes its way out as 
the result of the entire replacement operation (so, yes, the bool is needed 
here).


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

https://reviews.llvm.org/D61056



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


[Lldb-commits] [lldb] r359206 - Fixed typo in CompileUnit::GetImportedModules documentation [NFC]

2019-04-25 Thread Raphael Isemann via lldb-commits
Author: teemperor
Date: Thu Apr 25 10:08:54 2019
New Revision: 359206

URL: http://llvm.org/viewvc/llvm-project?rev=359206&view=rev
Log:
Fixed typo in CompileUnit::GetImportedModules documentation [NFC]

Modified:
lldb/trunk/include/lldb/Symbol/CompileUnit.h

Modified: lldb/trunk/include/lldb/Symbol/CompileUnit.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Symbol/CompileUnit.h?rev=359206&r1=359205&r2=359206&view=diff
==
--- lldb/trunk/include/lldb/Symbol/CompileUnit.h (original)
+++ lldb/trunk/include/lldb/Symbol/CompileUnit.h Thu Apr 25 10:08:54 2019
@@ -240,7 +240,7 @@ public:
   /// current module.
   ///
   /// \return
-  /// A list of imported module names.
+  /// A list of imported modules.
   const std::vector &GetImportedModules();
 
   /// Get the SymbolFile plug-in user data.


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


Re: [Lldb-commits] [lldb] r359138 - [ScriptInterpreterPython] find_first_of -> find (NFC)

2019-04-25 Thread Pavel Labath via lldb-commits

On 24/04/2019 22:40, Jonas Devlieghere via lldb-commits wrote:

Author: jdevlieghere
Date: Wed Apr 24 13:40:24 2019
New Revision: 359138

URL: http://llvm.org/viewvc/llvm-project?rev=359138&view=rev
Log:
[ScriptInterpreterPython] find_first_of -> find (NFC)

Follow up to r357198.

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

Modified: 
lldb/trunk/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp?rev=359138&r1=359137&r2=359138&view=diff
==
--- 
lldb/trunk/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp 
(original)
+++ 
lldb/trunk/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp 
Wed Apr 24 13:40:24 2019
@@ -2869,7 +2869,8 @@ bool ScriptInterpreterPythonImpl::IsRese
  
// filter out a few characters that would just confuse us and that are

// clearly not keyword material anyway
-  if (word_sr.find_first_of("'\"") != llvm::StringRef::npos)
+  if (word_sr.find('"') != llvm::StringRef::npos ||
+  word_sr.find('\'') != llvm::StringRef::npos)
  return false;
  


I suppose that's a matter of opinion, but I actually found the original 
version clearer. I also wouldn't be surprised if the original version 
was faster or at least equally fast (as the character list is a 
compile-time constant, there's a lot of optimizations that can be done 
even with the `find` function.

___
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

2019-04-25 Thread Jim Ingham via Phabricator via lldb-commits
jingham added a comment.

I'm a bit confused.  If we get to the world where we can support multiple 
script interpreters, I would expect to add a static method on ScriptInterpreter 
that enumerates the available interpreters.  I would not expect that to be on 
SBHostOS since this is not a feature of the Host OS but of how lldb was 
configured.  An lldb running on macOS with the Python2 plugin available behaves 
- w.r.t. macOS  - exactly the same as one built with a Python3 plugin 
available, etc.

So the "available languages" query for sure seems to me to belong as a static 
method on the ScriptInterpreter class.  But then once I've requested a 
particular script interpreter, asking it where it put the lldb module seems 
much more natural than going to the HostOS.  Under the covers, we will need to 
cooperate with the HostOS since that knows how lldb is packaged for a 
particular system.  But that doesn't seem like something we need to have users 
know.


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

https://reviews.llvm.org/D61090



___
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

2019-04-25 Thread Pavel Labath via Phabricator via lldb-commits
labath added a comment.

In D61090#1479004 , @jingham wrote:

> I'm a bit confused.  If we get to the world where we can support multiple 
> script interpreters, I would expect to add a static method on 
> ScriptInterpreter that enumerates the available interpreters.  I would not 
> expect that to be on SBHostOS since this is not a feature of the Host OS but 
> of how lldb was configured.  An lldb running on macOS with the Python2 plugin 
> available behaves - w.r.t. macOS  - exactly the same as one built with a 
> Python3 plugin available, etc.
>
> So the "available languages" query for sure seems to me to belong as a static 
> method on the ScriptInterpreter class.  But then once I've requested a 
> particular script interpreter, asking it where it put the lldb module seems 
> much more natural than going to the HostOS.  Under the covers, we will need 
> to cooperate with the HostOS since that knows how lldb is packaged for a 
> particular system.  But that doesn't seem like something we need to have 
> users know.


That also sounds pretty reasonable, especially if we want to do other things 
with the enumerated script interpreters besides getting their "module paths". 
The only thing is that there isn't a *Script*Interpreter class at the SB level. 
There is a *Command*Interpreter (which is what this patch is using), but that 
does not sound completely right to me as there is more to scripting languages 
than just the "script" command (in fact, I think the main reason that python 
layering is so hard to get right is that it has a dual role -- python is both 
embedded into lldb, and it also can be used to drive lldb from the outside).


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

https://reviews.llvm.org/D61090



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


[Lldb-commits] [PATCH] D61074: [lldb] [lit] Add register read tests for YMM registers (AVX)

2019-04-25 Thread Michał Górny via Phabricator via lldb-commits
mgorny added a comment.

In D61074#1478859 , @labath wrote:

> This test is pretty much a reimplementation of TestYMMRegisters dotest test. 
> I like this one more for several reasons, but if we're going to check this 
> in, we should also delete the other one.


Hmm, I see that the dotest test also includes support for 32-bit x86. Should I 
provide a 32-bit version of this one as well, or just neglect it?


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

https://reviews.llvm.org/D61074



___
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

2019-04-25 Thread Jim Ingham via Phabricator via lldb-commits
jingham added a comment.

I really thought there was one at the SB layer, because in terms of design that 
is what makes sense.  I guess we never really needed it until now, so we didn't 
add it.  Once there's more than one hard-coded script interpreter, we will need 
to add some way to select & direct scripts at the various script interpreters 
so we will need SBScriptInterpreter at the SB layer.  So maybe now is the time 
to add it in preparation...

Also, the fact that at the lldb_private layer, the ScriptInterpreter is held 
onto by the CommandInterpreter is clearly wrong.  The CommandInterpreter should 
have a member that tells it the currently selected ScriptInterpreter, but the 
list of script interpreters should belong to the Debugger.  We should probably 
disentangle that at the same time.

As an aside, IIUC, the current work to support either Python flavor only 
supports one interpreter at a time because Python doesn't support loading 
Python 2 & 3 into the same process?  That wouldn't be true for any other script 
interpreter.  I get LOTS of requests to add Swift as a script interpreter, BTW, 
though at present Swift isn't really ready for that so far as I can see...


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

https://reviews.llvm.org/D61090



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


[Lldb-commits] [PATCH] D61073: [lldb] [lit] Add feature flags for native CPU features

2019-04-25 Thread Michał Górny via Phabricator via lldb-commits
mgorny updated this revision to Diff 196675.
mgorny added a comment.

Added warnings for missing or failed lit-cpuid. Not that there any failure 
conditions in the program right now ;-).


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

https://reviews.llvm.org/D61073

Files:
  lldb/CMakeLists.txt
  lldb/lit/CMakeLists.txt
  lldb/lit/Register/x86-mm-xmm-read.test
  lldb/lit/lit.cfg.py
  lldb/utils/lit-cpuid/CMakeLists.txt
  lldb/utils/lit-cpuid/lit-cpuid.cpp

Index: lldb/utils/lit-cpuid/lit-cpuid.cpp
===
--- /dev/null
+++ lldb/utils/lit-cpuid/lit-cpuid.cpp
@@ -0,0 +1,33 @@
+//===- lit-cpuid.cpp - Get CPU feature flags for lit exported features ===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// lit-cpuid obtains the feature list for the currently running CPU, and outputs
+// those flags that are interesting for LLDB lit tests.
+//
+//===--===//
+
+#include "llvm/ADT/StringMap.h"
+#include "llvm/Support/Host.h"
+#include "llvm/Support/raw_ostream.h"
+
+using namespace llvm;
+
+int main(int argc, char **argv) {
+#if defined(__i386__) || defined(_M_IX86) || \
+defined(__x86_64__) || defined(_M_X64)
+  StringMap features;
+
+  if (!sys::getHostCPUFeatures(features))
+return 1;
+
+  if (features["sse"])
+outs() << "sse\n";
+#endif
+
+  return 0;
+}
Index: lldb/utils/lit-cpuid/CMakeLists.txt
===
--- /dev/null
+++ lldb/utils/lit-cpuid/CMakeLists.txt
@@ -0,0 +1,5 @@
+add_llvm_utility(lit-cpuid
+  lit-cpuid.cpp
+  )
+
+target_link_libraries(lit-cpuid PRIVATE LLVMSupport)
Index: lldb/lit/lit.cfg.py
===
--- lldb/lit/lit.cfg.py
+++ lldb/lit/lit.cfg.py
@@ -73,3 +73,17 @@
 if os.path.isdir(cachedir):
 print("Deleting module cache at %s."%cachedir)
 shutil.rmtree(cachedir)
+
+# If running tests natively, check for CPU features needed for some tests.
+
+if 'native' in config.available_features:
+cpuid_exe = lit.util.which('lit-cpuid', config.lldb_tools_dir)
+if cpuid_exe is None:
+lit_config.warning("lit-cpuid not found, tests requiring CPU extensions will be skipped")
+else:
+out, err, exitcode = lit.util.executeCommand([cpuid_exe])
+if exitcode == 0:
+for x in out.split():
+config.available_features.add('native-cpu-%s' % x)
+else:
+lit_config.warning("lit-cpuid failed: %s" % err)
Index: lldb/lit/Register/x86-mm-xmm-read.test
===
--- lldb/lit/Register/x86-mm-xmm-read.test
+++ lldb/lit/Register/x86-mm-xmm-read.test
@@ -1,6 +1,6 @@
 # XFAIL: system-darwin
 # XFAIL: system-windows
-# REQUIRES: native && (target-x86 || target-x86_64)
+# REQUIRES: native && (target-x86 || target-x86_64) && native-cpu-sse
 # RUN: %clangxx %p/Inputs/x86-mm-xmm-read.cpp -o %t
 # RUN: %lldb -b -s %s %t | FileCheck %s
 process launch
Index: lldb/lit/CMakeLists.txt
===
--- lldb/lit/CMakeLists.txt
+++ lldb/lit/CMakeLists.txt
@@ -20,6 +20,7 @@
 list(APPEND LLDB_TEST_DEPS
   LLDBUnitTests
   dsymutil
+  lit-cpuid
   llc
   lldb
   lldb-test
Index: lldb/CMakeLists.txt
===
--- lldb/CMakeLists.txt
+++ lldb/CMakeLists.txt
@@ -138,6 +138,7 @@
   add_subdirectory(test)
   add_subdirectory(unittests)
   add_subdirectory(lit)
+  add_subdirectory(utils/lit-cpuid)
   add_subdirectory(utils/lldb-dotest)
 endif()
 
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] r359208 - [lldb] [lit] Remove unnecessary array use in XMM reading test

2019-04-25 Thread Michal Gorny via lldb-commits
Author: mgorny
Date: Thu Apr 25 10:42:40 2019
New Revision: 359208

URL: http://llvm.org/viewvc/llvm-project?rev=359208&view=rev
Log:
[lldb] [lit] Remove unnecessary array use in XMM reading test

Remove the use of 2-element array for XMM data.  It is an accidental
leftover from previous implementation attempt, and it is unnecessary
with xmm_t.

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

Modified:
lldb/trunk/lit/Register/Inputs/x86-mm-xmm-read.cpp

Modified: lldb/trunk/lit/Register/Inputs/x86-mm-xmm-read.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/lit/Register/Inputs/x86-mm-xmm-read.cpp?rev=359208&r1=359207&r2=359208&view=diff
==
--- lldb/trunk/lit/Register/Inputs/x86-mm-xmm-read.cpp (original)
+++ lldb/trunk/lit/Register/Inputs/x86-mm-xmm-read.cpp Thu Apr 25 10:42:40 2019
@@ -14,14 +14,14 @@ int main() {
   uint64_t mm6 = 0x6162636465666768;
   uint64_t mm7 = 0x7172737475767778;
 
-  xmm_t xmm0[2] = { 0x020406080A0C0E01, 0x030507090B0D0F00 };
-  xmm_t xmm1[2] = { 0x121416181A1C1E11, 0x131517191B1D1F10 };
-  xmm_t xmm2[2] = { 0x222426282A2C2E21, 0x232527292B2D2F20 };
-  xmm_t xmm3[2] = { 0x323436383A3C3E31, 0x333537393B3D3F30 };
-  xmm_t xmm4[2] = { 0x424446484A4C4E41, 0x434547494B4D4F40 };
-  xmm_t xmm5[2] = { 0x525456585A5C5E51, 0x535557595B5D5F50 };
-  xmm_t xmm6[2] = { 0x626466686A6C6E61, 0x636567696B6D6F60 };
-  xmm_t xmm7[2] = { 0x727476787A7C7E71, 0x737577797B7D7F70 };
+  xmm_t xmm0 = { 0x020406080A0C0E01, 0x030507090B0D0F00 };
+  xmm_t xmm1 = { 0x121416181A1C1E11, 0x131517191B1D1F10 };
+  xmm_t xmm2 = { 0x222426282A2C2E21, 0x232527292B2D2F20 };
+  xmm_t xmm3 = { 0x323436383A3C3E31, 0x333537393B3D3F30 };
+  xmm_t xmm4 = { 0x424446484A4C4E41, 0x434547494B4D4F40 };
+  xmm_t xmm5 = { 0x525456585A5C5E51, 0x535557595B5D5F50 };
+  xmm_t xmm6 = { 0x626466686A6C6E61, 0x636567696B6D6F60 };
+  xmm_t xmm7 = { 0x727476787A7C7E71, 0x737577797B7D7F70 };
 
   asm volatile(
 "movq%0, %%mm0\n\t"


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


[Lldb-commits] [lldb] r359210 - [lldb] [lit] Add tests for reading new x86_64 registers

2019-04-25 Thread Michal Gorny via lldb-commits
Author: mgorny
Date: Thu Apr 25 10:42:49 2019
New Revision: 359210

URL: http://llvm.org/viewvc/llvm-project?rev=359210&view=rev
Log:
[lldb] [lit] Add tests for reading new x86_64 registers

Add tests covering read operations for the general-purpose and XMM
registers added in x86_64 (r8-r15 and xmm8-xmm15).

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

Added:
lldb/trunk/lit/Register/Inputs/x86-64-read.cpp
lldb/trunk/lit/Register/x86-64-read.test

Added: lldb/trunk/lit/Register/Inputs/x86-64-read.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/lit/Register/Inputs/x86-64-read.cpp?rev=359210&view=auto
==
--- lldb/trunk/lit/Register/Inputs/x86-64-read.cpp (added)
+++ lldb/trunk/lit/Register/Inputs/x86-64-read.cpp Thu Apr 25 10:42:49 2019
@@ -0,0 +1,55 @@
+#include 
+
+struct alignas(16) xmm_t {
+  uint64_t a, b;
+};
+
+int main() {
+  uint64_t r8 = 0x0102030405060708;
+  uint64_t r9 = 0x1112131415161718;
+  uint64_t r10 = 0x2122232425262728;
+  uint64_t r11 = 0x3132333435363738;
+  uint64_t r12 = 0x4142434445464748;
+  uint64_t r13 = 0x5152535455565758;
+  uint64_t r14 = 0x6162636465666768;
+  uint64_t r15 = 0x7172737475767778;
+
+  xmm_t xmm8 = { 0x020406080A0C0E01, 0x030507090B0D0F00 };
+  xmm_t xmm9 = { 0x121416181A1C1E11, 0x131517191B1D1F10 };
+  xmm_t xmm10 = { 0x222426282A2C2E21, 0x232527292B2D2F20 };
+  xmm_t xmm11 = { 0x323436383A3C3E31, 0x333537393B3D3F30 };
+  xmm_t xmm12 = { 0x424446484A4C4E41, 0x434547494B4D4F40 };
+  xmm_t xmm13 = { 0x525456585A5C5E51, 0x535557595B5D5F50 };
+  xmm_t xmm14 = { 0x626466686A6C6E61, 0x636567696B6D6F60 };
+  xmm_t xmm15 = { 0x727476787A7C7E71, 0x737577797B7D7F70 };
+
+  asm volatile(
+"movq%0, %%r8\n\t"
+"movq%1, %%r9\n\t"
+"movq%2, %%r10\n\t"
+"movq%3, %%r11\n\t"
+"movq%4, %%r12\n\t"
+"movq%5, %%r13\n\t"
+"movq%6, %%r14\n\t"
+"movq%7, %%r15\n\t"
+"\n\t"
+"movaps  %8, %%xmm8\n\t"
+"movaps  %9, %%xmm9\n\t"
+"movaps  %10, %%xmm10\n\t"
+"movaps  %11, %%xmm11\n\t"
+"movaps  %12, %%xmm12\n\t"
+"movaps  %13, %%xmm13\n\t"
+"movaps  %14, %%xmm14\n\t"
+"movaps  %15, %%xmm15\n\t"
+"\n\t"
+"int3"
+:
+: "g"(r8), "g"(r9), "g"(r10), "g"(r11), "g"(r12), "g"(r13), "g"(r14),
+  "g"(r15), "m"(xmm8), "m"(xmm9), "m"(xmm10), "m"(xmm11), "m"(xmm12),
+  "m"(xmm13), "m"(xmm14), "m"(xmm15)
+: "%r8", "%r9", "%r10", "%r11", "%r12", "%r13", "%r14", "%r15", "%xmm8",
+  "%xmm9", "%xmm10", "%xmm11", "%xmm12", "%xmm13", "%xmm14", "%xmm15"
+  );
+
+  return 0;
+}

Added: lldb/trunk/lit/Register/x86-64-read.test
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/lit/Register/x86-64-read.test?rev=359210&view=auto
==
--- lldb/trunk/lit/Register/x86-64-read.test (added)
+++ lldb/trunk/lit/Register/x86-64-read.test Thu Apr 25 10:42:49 2019
@@ -0,0 +1,48 @@
+# XFAIL: system-darwin
+# XFAIL: system-windows
+# REQUIRES: native && target-x86_64
+# RUN: %clangxx %p/Inputs/x86-64-read.cpp -o %t
+# RUN: %lldb -b -s %s %t | FileCheck %s
+process launch
+
+register read --all
+# CHECK-DAG: r8 = 0x0102030405060708
+# CHECK-DAG: r9 = 0x1112131415161718
+# CHECK-DAG: r10 = 0x2122232425262728
+# CHECK-DAG: r11 = 0x3132333435363738
+# CHECK-DAG: r12 = 0x4142434445464748
+# CHECK-DAG: r13 = 0x5152535455565758
+# CHECK-DAG: r14 = 0x6162636465666768
+# CHECK-DAG: r15 = 0x7172737475767778
+# CHECK-DAG: r8d = 0x05060708
+# CHECK-DAG: r9d = 0x15161718
+# CHECK-DAG: r10d = 0x25262728
+# CHECK-DAG: r11d = 0x35363738
+# CHECK-DAG: r12d = 0x45464748
+# CHECK-DAG: r13d = 0x55565758
+# CHECK-DAG: r14d = 0x65666768
+# CHECK-DAG: r15d = 0x75767778
+# CHECK-DAG: r8w = 0x0708
+# CHECK-DAG: r9w = 0x1718
+# CHECK-DAG: r10w = 0x2728
+# CHECK-DAG: r11w = 0x3738
+# CHECK-DAG: r12w = 0x4748
+# CHECK-DAG: r13w = 0x5758
+# CHECK-DAG: r14w = 0x6768
+# CHECK-DAG: r15w = 0x7778
+# CHECK-DAG: r8l = 0x08
+# CHECK-DAG: r9l = 0x18
+# CHECK-DAG: r10l = 0x28
+# CHECK-DAG: r11l = 0x38
+# CHECK-DAG: r12l = 0x48
+# CHECK-DAG: r13l = 0x58
+# CHECK-DAG: r14l = 0x68
+# CHECK-DAG: r15l = 0x78
+# CHECK-DAG: xmm8 = {0x01 0x0e 0x0c 0x0a 0x08 0x06 0x04 0x02 0x00 0x0f 0x0d 
0x0b 0x09 0x07 0x05 0x03}
+# CHECK-DAG: xmm9 = {0x11 0x1e 0x1c 0x1a 0x18 0x16 0x14 0x12 0x10 0x1f 0x1d 
0x1b 0x19 0x17 0x15 0x13}
+# CHECK-DAG: xmm10 = {0x21 0x2e 0x2c 0x2a 0x28 0x26 0x24 0x22 0x20 0x2f 0x2d 
0x2b 0x29 0x27 0x25 0x23}
+# CHECK-DAG: xmm11 = {0x31 0x3e 0x3c 0x3a 0x38 0x36 0x34 0x32 0x30 0x3f 0x3d 
0x3b 0x39 0x37 0x35 0x33}
+# CHECK-DAG: xmm12 = {0x41 0x4e 0x4c 0x4a 0x48 0x46 0x44 0x42 0x40 0x4f 0x4d 
0x4b 0x49 0x47 0x45 0x43}
+# CHECK-DAG: xmm13 = {0x51 0x5e 0x5c 0x5a 0x58 0x56 0x54 0x52 0x50 0x5f 0x5d 
0x5b 0x59 0x57 0x55 0x53}
+# CHECK-DAG: xmm14 = {0x61 0x6e 0x6c 0x6a 0x68 0x66 0x64 0x62 0x60 0x6f 0x6d 
0x6b 0x69 0x67 0x65 0x63}
+# CHECK-DAG: xmm15 = {0x71 0x7e 0x7c 0x

[Lldb-commits] [PATCH] D61072: [lldb] [lit] Add tests for reading new x86_64 registers

2019-04-25 Thread Michał Górny via Phabricator via lldb-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL359210: [lldb] [lit] Add tests for reading new x86_64 
registers (authored by mgorny, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D61072?vs=196502&id=196678#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D61072

Files:
  lldb/trunk/lit/Register/Inputs/x86-64-read.cpp
  lldb/trunk/lit/Register/x86-64-read.test

Index: lldb/trunk/lit/Register/x86-64-read.test
===
--- lldb/trunk/lit/Register/x86-64-read.test
+++ lldb/trunk/lit/Register/x86-64-read.test
@@ -0,0 +1,48 @@
+# XFAIL: system-darwin
+# XFAIL: system-windows
+# REQUIRES: native && target-x86_64
+# RUN: %clangxx %p/Inputs/x86-64-read.cpp -o %t
+# RUN: %lldb -b -s %s %t | FileCheck %s
+process launch
+
+register read --all
+# CHECK-DAG: r8 = 0x0102030405060708
+# CHECK-DAG: r9 = 0x1112131415161718
+# CHECK-DAG: r10 = 0x2122232425262728
+# CHECK-DAG: r11 = 0x3132333435363738
+# CHECK-DAG: r12 = 0x4142434445464748
+# CHECK-DAG: r13 = 0x5152535455565758
+# CHECK-DAG: r14 = 0x6162636465666768
+# CHECK-DAG: r15 = 0x7172737475767778
+# CHECK-DAG: r8d = 0x05060708
+# CHECK-DAG: r9d = 0x15161718
+# CHECK-DAG: r10d = 0x25262728
+# CHECK-DAG: r11d = 0x35363738
+# CHECK-DAG: r12d = 0x45464748
+# CHECK-DAG: r13d = 0x55565758
+# CHECK-DAG: r14d = 0x65666768
+# CHECK-DAG: r15d = 0x75767778
+# CHECK-DAG: r8w = 0x0708
+# CHECK-DAG: r9w = 0x1718
+# CHECK-DAG: r10w = 0x2728
+# CHECK-DAG: r11w = 0x3738
+# CHECK-DAG: r12w = 0x4748
+# CHECK-DAG: r13w = 0x5758
+# CHECK-DAG: r14w = 0x6768
+# CHECK-DAG: r15w = 0x7778
+# CHECK-DAG: r8l = 0x08
+# CHECK-DAG: r9l = 0x18
+# CHECK-DAG: r10l = 0x28
+# CHECK-DAG: r11l = 0x38
+# CHECK-DAG: r12l = 0x48
+# CHECK-DAG: r13l = 0x58
+# CHECK-DAG: r14l = 0x68
+# CHECK-DAG: r15l = 0x78
+# CHECK-DAG: xmm8 = {0x01 0x0e 0x0c 0x0a 0x08 0x06 0x04 0x02 0x00 0x0f 0x0d 0x0b 0x09 0x07 0x05 0x03}
+# CHECK-DAG: xmm9 = {0x11 0x1e 0x1c 0x1a 0x18 0x16 0x14 0x12 0x10 0x1f 0x1d 0x1b 0x19 0x17 0x15 0x13}
+# CHECK-DAG: xmm10 = {0x21 0x2e 0x2c 0x2a 0x28 0x26 0x24 0x22 0x20 0x2f 0x2d 0x2b 0x29 0x27 0x25 0x23}
+# CHECK-DAG: xmm11 = {0x31 0x3e 0x3c 0x3a 0x38 0x36 0x34 0x32 0x30 0x3f 0x3d 0x3b 0x39 0x37 0x35 0x33}
+# CHECK-DAG: xmm12 = {0x41 0x4e 0x4c 0x4a 0x48 0x46 0x44 0x42 0x40 0x4f 0x4d 0x4b 0x49 0x47 0x45 0x43}
+# CHECK-DAG: xmm13 = {0x51 0x5e 0x5c 0x5a 0x58 0x56 0x54 0x52 0x50 0x5f 0x5d 0x5b 0x59 0x57 0x55 0x53}
+# CHECK-DAG: xmm14 = {0x61 0x6e 0x6c 0x6a 0x68 0x66 0x64 0x62 0x60 0x6f 0x6d 0x6b 0x69 0x67 0x65 0x63}
+# CHECK-DAG: xmm15 = {0x71 0x7e 0x7c 0x7a 0x78 0x76 0x74 0x72 0x70 0x7f 0x7d 0x7b 0x79 0x77 0x75 0x73}
Index: lldb/trunk/lit/Register/Inputs/x86-64-read.cpp
===
--- lldb/trunk/lit/Register/Inputs/x86-64-read.cpp
+++ lldb/trunk/lit/Register/Inputs/x86-64-read.cpp
@@ -0,0 +1,55 @@
+#include 
+
+struct alignas(16) xmm_t {
+  uint64_t a, b;
+};
+
+int main() {
+  uint64_t r8 = 0x0102030405060708;
+  uint64_t r9 = 0x1112131415161718;
+  uint64_t r10 = 0x2122232425262728;
+  uint64_t r11 = 0x3132333435363738;
+  uint64_t r12 = 0x4142434445464748;
+  uint64_t r13 = 0x5152535455565758;
+  uint64_t r14 = 0x6162636465666768;
+  uint64_t r15 = 0x7172737475767778;
+
+  xmm_t xmm8 = { 0x020406080A0C0E01, 0x030507090B0D0F00 };
+  xmm_t xmm9 = { 0x121416181A1C1E11, 0x131517191B1D1F10 };
+  xmm_t xmm10 = { 0x222426282A2C2E21, 0x232527292B2D2F20 };
+  xmm_t xmm11 = { 0x323436383A3C3E31, 0x333537393B3D3F30 };
+  xmm_t xmm12 = { 0x424446484A4C4E41, 0x434547494B4D4F40 };
+  xmm_t xmm13 = { 0x525456585A5C5E51, 0x535557595B5D5F50 };
+  xmm_t xmm14 = { 0x626466686A6C6E61, 0x636567696B6D6F60 };
+  xmm_t xmm15 = { 0x727476787A7C7E71, 0x737577797B7D7F70 };
+
+  asm volatile(
+"movq%0, %%r8\n\t"
+"movq%1, %%r9\n\t"
+"movq%2, %%r10\n\t"
+"movq%3, %%r11\n\t"
+"movq%4, %%r12\n\t"
+"movq%5, %%r13\n\t"
+"movq%6, %%r14\n\t"
+"movq%7, %%r15\n\t"
+"\n\t"
+"movaps  %8, %%xmm8\n\t"
+"movaps  %9, %%xmm9\n\t"
+"movaps  %10, %%xmm10\n\t"
+"movaps  %11, %%xmm11\n\t"
+"movaps  %12, %%xmm12\n\t"
+"movaps  %13, %%xmm13\n\t"
+"movaps  %14, %%xmm14\n\t"
+"movaps  %15, %%xmm15\n\t"
+"\n\t"
+"int3"
+:
+: "g"(r8), "g"(r9), "g"(r10), "g"(r11), "g"(r12), "g"(r13), "g"(r14),
+  "g"(r15), "m"(xmm8), "m"(xmm9), "m"(xmm10), "m"(xmm11), "m"(xmm12),
+  "m"(xmm13), "m"(xmm14), "m"(xmm15)
+: "%r8", "%r9", "%r10", "%r11", "%r12", "%r13", "%r14", "%r15", "%xmm8",
+  "%xmm9", "%xmm10", "%xmm11", "%xmm12", "%xmm13", "%xmm14", "%xmm15"
+  );
+
+  return 0;
+}
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/li

[Lldb-commits] [PATCH] D61085: [lldb] [lit] Remove unnecessary array use in XMM reading test

2019-04-25 Thread Michał Górny via Phabricator via lldb-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL359208: [lldb] [lit] Remove unnecessary array use in XMM 
reading test (authored by mgorny, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D61085?vs=196500&id=196677#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D61085

Files:
  lldb/trunk/lit/Register/Inputs/x86-mm-xmm-read.cpp


Index: lldb/trunk/lit/Register/Inputs/x86-mm-xmm-read.cpp
===
--- lldb/trunk/lit/Register/Inputs/x86-mm-xmm-read.cpp
+++ lldb/trunk/lit/Register/Inputs/x86-mm-xmm-read.cpp
@@ -14,14 +14,14 @@
   uint64_t mm6 = 0x6162636465666768;
   uint64_t mm7 = 0x7172737475767778;
 
-  xmm_t xmm0[2] = { 0x020406080A0C0E01, 0x030507090B0D0F00 };
-  xmm_t xmm1[2] = { 0x121416181A1C1E11, 0x131517191B1D1F10 };
-  xmm_t xmm2[2] = { 0x222426282A2C2E21, 0x232527292B2D2F20 };
-  xmm_t xmm3[2] = { 0x323436383A3C3E31, 0x333537393B3D3F30 };
-  xmm_t xmm4[2] = { 0x424446484A4C4E41, 0x434547494B4D4F40 };
-  xmm_t xmm5[2] = { 0x525456585A5C5E51, 0x535557595B5D5F50 };
-  xmm_t xmm6[2] = { 0x626466686A6C6E61, 0x636567696B6D6F60 };
-  xmm_t xmm7[2] = { 0x727476787A7C7E71, 0x737577797B7D7F70 };
+  xmm_t xmm0 = { 0x020406080A0C0E01, 0x030507090B0D0F00 };
+  xmm_t xmm1 = { 0x121416181A1C1E11, 0x131517191B1D1F10 };
+  xmm_t xmm2 = { 0x222426282A2C2E21, 0x232527292B2D2F20 };
+  xmm_t xmm3 = { 0x323436383A3C3E31, 0x333537393B3D3F30 };
+  xmm_t xmm4 = { 0x424446484A4C4E41, 0x434547494B4D4F40 };
+  xmm_t xmm5 = { 0x525456585A5C5E51, 0x535557595B5D5F50 };
+  xmm_t xmm6 = { 0x626466686A6C6E61, 0x636567696B6D6F60 };
+  xmm_t xmm7 = { 0x727476787A7C7E71, 0x737577797B7D7F70 };
 
   asm volatile(
 "movq%0, %%mm0\n\t"


Index: lldb/trunk/lit/Register/Inputs/x86-mm-xmm-read.cpp
===
--- lldb/trunk/lit/Register/Inputs/x86-mm-xmm-read.cpp
+++ lldb/trunk/lit/Register/Inputs/x86-mm-xmm-read.cpp
@@ -14,14 +14,14 @@
   uint64_t mm6 = 0x6162636465666768;
   uint64_t mm7 = 0x7172737475767778;
 
-  xmm_t xmm0[2] = { 0x020406080A0C0E01, 0x030507090B0D0F00 };
-  xmm_t xmm1[2] = { 0x121416181A1C1E11, 0x131517191B1D1F10 };
-  xmm_t xmm2[2] = { 0x222426282A2C2E21, 0x232527292B2D2F20 };
-  xmm_t xmm3[2] = { 0x323436383A3C3E31, 0x333537393B3D3F30 };
-  xmm_t xmm4[2] = { 0x424446484A4C4E41, 0x434547494B4D4F40 };
-  xmm_t xmm5[2] = { 0x525456585A5C5E51, 0x535557595B5D5F50 };
-  xmm_t xmm6[2] = { 0x626466686A6C6E61, 0x636567696B6D6F60 };
-  xmm_t xmm7[2] = { 0x727476787A7C7E71, 0x737577797B7D7F70 };
+  xmm_t xmm0 = { 0x020406080A0C0E01, 0x030507090B0D0F00 };
+  xmm_t xmm1 = { 0x121416181A1C1E11, 0x131517191B1D1F10 };
+  xmm_t xmm2 = { 0x222426282A2C2E21, 0x232527292B2D2F20 };
+  xmm_t xmm3 = { 0x323436383A3C3E31, 0x333537393B3D3F30 };
+  xmm_t xmm4 = { 0x424446484A4C4E41, 0x434547494B4D4F40 };
+  xmm_t xmm5 = { 0x525456585A5C5E51, 0x535557595B5D5F50 };
+  xmm_t xmm6 = { 0x626466686A6C6E61, 0x636567696B6D6F60 };
+  xmm_t xmm7 = { 0x727476787A7C7E71, 0x737577797B7D7F70 };
 
   asm volatile(
 "movq%0, %%mm0\n\t"
___
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

2019-04-25 Thread Greg Clayton via Phabricator via lldb-commits
clayborg added a comment.

I agree with all that was said above.

My reason for leaving it in SBHostOS is due to SBCommandInterpreter not being 
the right place, since we don't have SBScriptInprereter in the API, and we 
might as well leave it in SBHostOS until we are going to do it right by having 
a static call on SBScriptInterpreter that takes a enumeration from 
lldb-enumerations.h with a list of script interpreter languages that could be 
supported. Right now we just have python, so no need to add that functionality 
yet.


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

https://reviews.llvm.org/D61090



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


[Lldb-commits] [PATCH] D60519: [Windows] Dump more information about access violation exception

2019-04-25 Thread Stella Stamenova via Phabricator via lldb-commits
stella.stamenova accepted this revision.
stella.stamenova added a comment.
This revision is now accepted and ready to land.

Yes, sorry. I hadn't gotten around to testing it to make sure the failures were 
gone. Do you still need someone to commit for you?


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D60519



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


[Lldb-commits] [PATCH] D61056: PostfixExpression: move DWARF generator out of NativePDB internals

2019-04-25 Thread Adrian McCarthy via Phabricator via lldb-commits
amccarth accepted this revision.
amccarth marked 2 inline comments as done.
amccarth added a comment.
This revision is now accepted and ready to land.

Clever (hopefully not too clever)!  Not having to derive a special class from 
Visitor is really nice.

LGTM.




Comment at: include/lldb/Symbol/PostfixExpression.h:216
+  /// nullptr, if unable to replace/resolve.
+  virtual Node *Replace(SymbolNode &symbol) = 0;
+};

labath wrote:
> amccarth wrote:
> > I'm confused why this takes `symbol` by (non-const) ref.  Is `symbol` 
> > modified in the process of figuring out what should replace it?
> > 
> > Oh, peeking ahead at the implementation, I see it can return the address of 
> > `symbol`.  I'm left wondering whether there's a less confusing API.
> Yeah, I too had the feeling that there ought to be a simpler way to do this, 
> but I couldn't figure out how until now...
> 
> Check out the new version of the patch. Now, instead of having to subclass 
> something one can implement a trivial search-and-replace operation by just 
> passing a callback to the function. (There is subclassing going on under the 
> hood, but the user is unaware of that).
> 
> In fact, it made things so simple, I just decided to merge the two-pass 
> algorithm in NativePDB into a single function.
Well, it is simpler, but we still have that non-const ref to symbol, which is 
what originally threw me.  I don't see a way to get around that, and I like the 
new solution better than having to derive your own visitor.



Comment at: 
source/Plugins/SymbolFile/NativePDB/PdbFPOProgramToDWARFExpression.cpp:46
+  Node *result = it->second;
+  Dispatch(result); // Recursively process the result.
+  return result;// And return it.

labath wrote:
> amccarth wrote:
> > If I understand correctly, we don't care about the return value of 
> > `Dispatch` because all that matters is whether `result` points to a valid 
> > `Node` or is just `nullptr`.  Right?
> > 
> > If so, then should `SymbolResolver ` derive from `Visitor` rather 
> > than `Visitor`?
> Not exactly. The fact whether is the replacement function returned nullptr is 
> then propagated up the Dispatch function, and eventually makes its way out as 
> the result of the entire replacement operation (so, yes, the bool is needed 
> here).
Oh yes.  I was looking at the Dispatch calls in the DWARF CodeGen class by 
mistake.  Those are Visitor.  Perfect.


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

https://reviews.llvm.org/D61056



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


[Lldb-commits] [PATCH] D60519: [Windows] Dump more information about access violation exception

2019-04-25 Thread Leonid Mashinskiy via Phabricator via lldb-commits
leonid.mashinskiy added a comment.

Thanks!
I think I can ask @aleksandr.urakov to land changes.


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D60519



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


[Lldb-commits] [lldb] r359221 - [lldb] [lit] Un-XFAIL Register/x86-64-read.test for Darwin

2019-04-25 Thread Michal Gorny via lldb-commits
Author: mgorny
Date: Thu Apr 25 11:38:58 2019
New Revision: 359221

URL: http://llvm.org/viewvc/llvm-project?rev=359221&view=rev
Log:
[lldb] [lit] Un-XFAIL Register/x86-64-read.test for Darwin

Modified:
lldb/trunk/lit/Register/x86-64-read.test

Modified: lldb/trunk/lit/Register/x86-64-read.test
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/lit/Register/x86-64-read.test?rev=359221&r1=359220&r2=359221&view=diff
==
--- lldb/trunk/lit/Register/x86-64-read.test (original)
+++ lldb/trunk/lit/Register/x86-64-read.test Thu Apr 25 11:38:58 2019
@@ -1,4 +1,3 @@
-# XFAIL: system-darwin
 # XFAIL: system-windows
 # REQUIRES: native && target-x86_64
 # RUN: %clangxx %p/Inputs/x86-64-read.cpp -o %t


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


[Lldb-commits] [lldb] r359228 - [lldb] [lit] Use constexpr and better constraints in Register tests

2019-04-25 Thread Michal Gorny via lldb-commits
Author: mgorny
Date: Thu Apr 25 12:56:54 2019
New Revision: 359228

URL: http://llvm.org/viewvc/llvm-project?rev=359228&view=rev
Log:
[lldb] [lit] Use constexpr and better constraints in Register tests

Use constexpr to explicitly indicate that we're dealing with integer
constants, and provoke clang to assign them straight to registers
whenever possible.  Adjust input constraints in %mmN tests to "rm"
as using integer constants is apparently disallowed there.  Also
use "i" for %rN tests, as we don't want clang to accidentally clobber
those general purpose registers while assigning to them (however
unlikely that is).

Modified:
lldb/trunk/lit/Register/Inputs/x86-64-read.cpp
lldb/trunk/lit/Register/Inputs/x86-mm-xmm-read.cpp

Modified: lldb/trunk/lit/Register/Inputs/x86-64-read.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/lit/Register/Inputs/x86-64-read.cpp?rev=359228&r1=359227&r2=359228&view=diff
==
--- lldb/trunk/lit/Register/Inputs/x86-64-read.cpp (original)
+++ lldb/trunk/lit/Register/Inputs/x86-64-read.cpp Thu Apr 25 12:56:54 2019
@@ -5,23 +5,23 @@ struct alignas(16) xmm_t {
 };
 
 int main() {
-  uint64_t r8 = 0x0102030405060708;
-  uint64_t r9 = 0x1112131415161718;
-  uint64_t r10 = 0x2122232425262728;
-  uint64_t r11 = 0x3132333435363738;
-  uint64_t r12 = 0x4142434445464748;
-  uint64_t r13 = 0x5152535455565758;
-  uint64_t r14 = 0x6162636465666768;
-  uint64_t r15 = 0x7172737475767778;
+  constexpr uint64_t r8 = 0x0102030405060708;
+  constexpr uint64_t r9 = 0x1112131415161718;
+  constexpr uint64_t r10 = 0x2122232425262728;
+  constexpr uint64_t r11 = 0x3132333435363738;
+  constexpr uint64_t r12 = 0x4142434445464748;
+  constexpr uint64_t r13 = 0x5152535455565758;
+  constexpr uint64_t r14 = 0x6162636465666768;
+  constexpr uint64_t r15 = 0x7172737475767778;
 
-  xmm_t xmm8 = { 0x020406080A0C0E01, 0x030507090B0D0F00 };
-  xmm_t xmm9 = { 0x121416181A1C1E11, 0x131517191B1D1F10 };
-  xmm_t xmm10 = { 0x222426282A2C2E21, 0x232527292B2D2F20 };
-  xmm_t xmm11 = { 0x323436383A3C3E31, 0x333537393B3D3F30 };
-  xmm_t xmm12 = { 0x424446484A4C4E41, 0x434547494B4D4F40 };
-  xmm_t xmm13 = { 0x525456585A5C5E51, 0x535557595B5D5F50 };
-  xmm_t xmm14 = { 0x626466686A6C6E61, 0x636567696B6D6F60 };
-  xmm_t xmm15 = { 0x727476787A7C7E71, 0x737577797B7D7F70 };
+  constexpr xmm_t xmm8 = { 0x020406080A0C0E01, 0x030507090B0D0F00 };
+  constexpr xmm_t xmm9 = { 0x121416181A1C1E11, 0x131517191B1D1F10 };
+  constexpr xmm_t xmm10 = { 0x222426282A2C2E21, 0x232527292B2D2F20 };
+  constexpr xmm_t xmm11 = { 0x323436383A3C3E31, 0x333537393B3D3F30 };
+  constexpr xmm_t xmm12 = { 0x424446484A4C4E41, 0x434547494B4D4F40 };
+  constexpr xmm_t xmm13 = { 0x525456585A5C5E51, 0x535557595B5D5F50 };
+  constexpr xmm_t xmm14 = { 0x626466686A6C6E61, 0x636567696B6D6F60 };
+  constexpr xmm_t xmm15 = { 0x727476787A7C7E71, 0x737577797B7D7F70 };
 
   asm volatile(
 "movq%0, %%r8\n\t"
@@ -44,8 +44,8 @@ int main() {
 "\n\t"
 "int3"
 :
-: "g"(r8), "g"(r9), "g"(r10), "g"(r11), "g"(r12), "g"(r13), "g"(r14),
-  "g"(r15), "m"(xmm8), "m"(xmm9), "m"(xmm10), "m"(xmm11), "m"(xmm12),
+: "i"(r8), "i"(r9), "i"(r10), "i"(r11), "i"(r12), "i"(r13), "i"(r14),
+  "i"(r15), "m"(xmm8), "m"(xmm9), "m"(xmm10), "m"(xmm11), "m"(xmm12),
   "m"(xmm13), "m"(xmm14), "m"(xmm15)
 : "%r8", "%r9", "%r10", "%r11", "%r12", "%r13", "%r14", "%r15", "%xmm8",
   "%xmm9", "%xmm10", "%xmm11", "%xmm12", "%xmm13", "%xmm14", "%xmm15"

Modified: lldb/trunk/lit/Register/Inputs/x86-mm-xmm-read.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/lit/Register/Inputs/x86-mm-xmm-read.cpp?rev=359228&r1=359227&r2=359228&view=diff
==
--- lldb/trunk/lit/Register/Inputs/x86-mm-xmm-read.cpp (original)
+++ lldb/trunk/lit/Register/Inputs/x86-mm-xmm-read.cpp Thu Apr 25 12:56:54 2019
@@ -5,23 +5,23 @@ struct alignas(16) xmm_t {
 };
 
 int main() {
-  uint64_t mm0 = 0x0102030405060708;
-  uint64_t mm1 = 0x1112131415161718;
-  uint64_t mm2 = 0x2122232425262728;
-  uint64_t mm3 = 0x3132333435363738;
-  uint64_t mm4 = 0x4142434445464748;
-  uint64_t mm5 = 0x5152535455565758;
-  uint64_t mm6 = 0x6162636465666768;
-  uint64_t mm7 = 0x7172737475767778;
+  constexpr uint64_t mm0 = 0x0102030405060708;
+  constexpr uint64_t mm1 = 0x1112131415161718;
+  constexpr uint64_t mm2 = 0x2122232425262728;
+  constexpr uint64_t mm3 = 0x3132333435363738;
+  constexpr uint64_t mm4 = 0x4142434445464748;
+  constexpr uint64_t mm5 = 0x5152535455565758;
+  constexpr uint64_t mm6 = 0x6162636465666768;
+  constexpr uint64_t mm7 = 0x7172737475767778;
 
-  xmm_t xmm0 = { 0x020406080A0C0E01, 0x030507090B0D0F00 };
-  xmm_t xmm1 = { 0x121416181A1C1E11, 0x131517191B1D1F10 };
-  xmm_t xmm2 = { 0x222426282A2C2E21, 0x232527292B2D2F20 };
-  xmm_t xmm3 = { 0x323436383A3C3E31, 0x333537393B3D3F30 };
-  xmm_t xmm4 = { 0x424446484A

[Lldb-commits] [lldb] r359234 - Two tests were using the interactive convenience variable

2019-04-25 Thread Jason Molenda via lldb-commits
Author: jmolenda
Date: Thu Apr 25 13:03:39 2019
New Revision: 359234

URL: http://llvm.org/viewvc/llvm-project?rev=359234&view=rev
Log:
Two tests were using the interactive convenience variable
lldb.debugger.  They should not be.
 

Modified:

lldb/trunk/packages/Python/lldbsuite/test/expression_command/issue_11588/Test11588.py

lldb/trunk/packages/Python/lldbsuite/test/macosx/thread-names/TestInterruptThreadNames.py

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/expression_command/issue_11588/Test11588.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/expression_command/issue_11588/Test11588.py?rev=359234&r1=359233&r2=359234&view=diff
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/expression_command/issue_11588/Test11588.py
 (original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/expression_command/issue_11588/Test11588.py
 Thu Apr 25 13:03:39 2019
@@ -48,7 +48,7 @@ class Issue11581TestCase(TestBase):
 # register r14 is an x86_64 extension let's skip this part of the test
 # if we are on a different architecture
 if self.getArchitecture() == 'x86_64':
-target = lldb.debugger.GetSelectedTarget()
+target = self.dbg.GetSelectedTarget()
 process = target.GetProcess()
 frame = process.GetSelectedThread().GetSelectedFrame()
 pointer = frame.FindVariable("r14")

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/macosx/thread-names/TestInterruptThreadNames.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/macosx/thread-names/TestInterruptThreadNames.py?rev=359234&r1=359233&r2=359234&view=diff
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/macosx/thread-names/TestInterruptThreadNames.py
 (original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/macosx/thread-names/TestInterruptThreadNames.py
 Thu Apr 25 13:03:39 2019
@@ -30,11 +30,11 @@ class TestInterruptThreadNames(TestBase)
 
 launch_info = lldb.SBLaunchInfo(None)
 error = lldb.SBError()
-lldb.debugger.SetAsync(True)
+self.dbg.SetAsync(True)
 process = target.Launch(launch_info, error)
 self.assertTrue(process, PROCESS_IS_VALID)
 
-listener = lldb.debugger.GetListener()
+listener = self.dbg.GetListener()
 broadcaster = process.GetBroadcaster()
 rc = broadcaster.AddListener(listener, 
lldb.SBProcess.eBroadcastBitStateChanged)
 self.assertTrue(rc != 0, "Unable to add listener to process")


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


[Lldb-commits] [PATCH] D61074: [lldb] [lit] Add register read tests for YMM registers (AVX)

2019-04-25 Thread Michał Górny via Phabricator via lldb-commits
mgorny updated this revision to Diff 196714.
mgorny added a comment.

Added a 32-bit version of the test, and constexpr.

I propose to keep the dotest tests until I reimplement ZMM as well, and then 
remove it altogether.


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

https://reviews.llvm.org/D61074

Files:
  lldb/lit/Register/Inputs/x86-ymm-read.cpp
  lldb/lit/Register/x86-64-ymm-read.test
  lldb/lit/Register/x86-ymm-read.test
  lldb/utils/lit-cpuid/lit-cpuid.cpp

Index: lldb/utils/lit-cpuid/lit-cpuid.cpp
===
--- lldb/utils/lit-cpuid/lit-cpuid.cpp
+++ lldb/utils/lit-cpuid/lit-cpuid.cpp
@@ -27,6 +27,8 @@
 
   if (features["sse"])
 outs() << "sse\n";
+  if (features["avx"])
+outs() << "avx\n";
 #endif
 
   return 0;
Index: lldb/lit/Register/x86-ymm-read.test
===
--- /dev/null
+++ lldb/lit/Register/x86-ymm-read.test
@@ -0,0 +1,23 @@
+# XFAIL: system-windows
+# REQUIRES: native && target-x86 && native-cpu-avx
+# RUN: %clangxx %p/Inputs/x86-ymm-read.cpp -o %t
+# RUN: %lldb -b -s %s %t | FileCheck %s
+process launch
+
+register read --all
+# CHECK-DAG: xmm0 = {0x01 0x0e 0x0c 0x0a 0x08 0x06 0x04 0x02 0x00 0x0f 0x0d 0x0b 0x09 0x07 0x05 0x03}
+# CHECK-DAG: xmm1 = {0x11 0x1e 0x1c 0x1a 0x18 0x16 0x14 0x12 0x10 0x1f 0x1d 0x1b 0x19 0x17 0x15 0x13}
+# CHECK-DAG: xmm2 = {0x21 0x2e 0x2c 0x2a 0x28 0x26 0x24 0x22 0x20 0x2f 0x2d 0x2b 0x29 0x27 0x25 0x23}
+# CHECK-DAG: xmm3 = {0x31 0x3e 0x3c 0x3a 0x38 0x36 0x34 0x32 0x30 0x3f 0x3d 0x3b 0x39 0x37 0x35 0x33}
+# CHECK-DAG: xmm4 = {0x41 0x4e 0x4c 0x4a 0x48 0x46 0x44 0x42 0x40 0x4f 0x4d 0x4b 0x49 0x47 0x45 0x43}
+# CHECK-DAG: xmm5 = {0x51 0x5e 0x5c 0x5a 0x58 0x56 0x54 0x52 0x50 0x5f 0x5d 0x5b 0x59 0x57 0x55 0x53}
+# CHECK-DAG: xmm6 = {0x61 0x6e 0x6c 0x6a 0x68 0x66 0x64 0x62 0x60 0x6f 0x6d 0x6b 0x69 0x67 0x65 0x63}
+# CHECK-DAG: xmm7 = {0x71 0x7e 0x7c 0x7a 0x78 0x76 0x74 0x72 0x70 0x7f 0x7d 0x7b 0x79 0x77 0x75 0x73}
+# CHECK-DAG: ymm0 = {0x01 0x0e 0x0c 0x0a 0x08 0x06 0x04 0x02 0x00 0x0f 0x0d 0x0b 0x09 0x07 0x05 0x03 0x80 0x8f 0x8d 0x8b 0x89 0x87 0x85 0x83 0x81 0x8e 0x8c 0x8a 0x88 0x86 0x84 0x82}
+# CHECK-DAG: ymm1 = {0x11 0x1e 0x1c 0x1a 0x18 0x16 0x14 0x12 0x10 0x1f 0x1d 0x1b 0x19 0x17 0x15 0x13 0x90 0x9f 0x9d 0x9b 0x99 0x97 0x95 0x93 0x91 0x9e 0x9c 0x9a 0x98 0x96 0x94 0x92}
+# CHECK-DAG: ymm2 = {0x21 0x2e 0x2c 0x2a 0x28 0x26 0x24 0x22 0x20 0x2f 0x2d 0x2b 0x29 0x27 0x25 0x23 0xa0 0xaf 0xad 0xab 0xa9 0xa7 0xa5 0xa3 0xa1 0xae 0xac 0xaa 0xa8 0xa6 0xa4 0xa2}
+# CHECK-DAG: ymm3 = {0x31 0x3e 0x3c 0x3a 0x38 0x36 0x34 0x32 0x30 0x3f 0x3d 0x3b 0x39 0x37 0x35 0x33 0xb0 0xbf 0xbd 0xbb 0xb9 0xb7 0xb5 0xb3 0xb1 0xbe 0xbc 0xba 0xb8 0xb6 0xb4 0xb2}
+# CHECK-DAG: ymm4 = {0x41 0x4e 0x4c 0x4a 0x48 0x46 0x44 0x42 0x40 0x4f 0x4d 0x4b 0x49 0x47 0x45 0x43 0xc0 0xcf 0xcd 0xcb 0xc9 0xc7 0xc5 0xc3 0xc1 0xce 0xcc 0xca 0xc8 0xc6 0xc4 0xc2}
+# CHECK-DAG: ymm5 = {0x51 0x5e 0x5c 0x5a 0x58 0x56 0x54 0x52 0x50 0x5f 0x5d 0x5b 0x59 0x57 0x55 0x53 0xd0 0xdf 0xdd 0xdb 0xd9 0xd7 0xd5 0xd3 0xd1 0xde 0xdc 0xda 0xd8 0xd6 0xd4 0xd2}
+# CHECK-DAG: ymm6 = {0x61 0x6e 0x6c 0x6a 0x68 0x66 0x64 0x62 0x60 0x6f 0x6d 0x6b 0x69 0x67 0x65 0x63 0xe0 0xef 0xed 0xeb 0xe9 0xe7 0xe5 0xe3 0xe1 0xee 0xec 0xea 0xe8 0xe6 0xe4 0xe2}
+# CHECK-DAG: ymm7 = {0x71 0x7e 0x7c 0x7a 0x78 0x76 0x74 0x72 0x70 0x7f 0x7d 0x7b 0x79 0x77 0x75 0x73 0xf0 0xff 0xfd 0xfb 0xf9 0xf7 0xf5 0xf3 0xf1 0xfe 0xfc 0xfa 0xf8 0xf6 0xf4 0xf2}
Index: lldb/lit/Register/x86-64-ymm-read.test
===
--- /dev/null
+++ lldb/lit/Register/x86-64-ymm-read.test
@@ -0,0 +1,39 @@
+# XFAIL: system-windows
+# REQUIRES: native && target-x86_64 && native-cpu-avx
+# RUN: %clangxx %p/Inputs/x86-ymm-read.cpp -o %t
+# RUN: %lldb -b -s %s %t | FileCheck %s
+process launch
+
+register read --all
+# CHECK-DAG: xmm0 = {0x01 0x0e 0x0c 0x0a 0x08 0x06 0x04 0x02 0x00 0x0f 0x0d 0x0b 0x09 0x07 0x05 0x03}
+# CHECK-DAG: xmm1 = {0x11 0x1e 0x1c 0x1a 0x18 0x16 0x14 0x12 0x10 0x1f 0x1d 0x1b 0x19 0x17 0x15 0x13}
+# CHECK-DAG: xmm2 = {0x21 0x2e 0x2c 0x2a 0x28 0x26 0x24 0x22 0x20 0x2f 0x2d 0x2b 0x29 0x27 0x25 0x23}
+# CHECK-DAG: xmm3 = {0x31 0x3e 0x3c 0x3a 0x38 0x36 0x34 0x32 0x30 0x3f 0x3d 0x3b 0x39 0x37 0x35 0x33}
+# CHECK-DAG: xmm4 = {0x41 0x4e 0x4c 0x4a 0x48 0x46 0x44 0x42 0x40 0x4f 0x4d 0x4b 0x49 0x47 0x45 0x43}
+# CHECK-DAG: xmm5 = {0x51 0x5e 0x5c 0x5a 0x58 0x56 0x54 0x52 0x50 0x5f 0x5d 0x5b 0x59 0x57 0x55 0x53}
+# CHECK-DAG: xmm6 = {0x61 0x6e 0x6c 0x6a 0x68 0x66 0x64 0x62 0x60 0x6f 0x6d 0x6b 0x69 0x67 0x65 0x63}
+# CHECK-DAG: xmm7 = {0x71 0x7e 0x7c 0x7a 0x78 0x76 0x74 0x72 0x70 0x7f 0x7d 0x7b 0x79 0x77 0x75 0x73}
+# CHECK-DAG: xmm8 = {0x80 0x8f 0x8d 0x8b 0x89 0x87 0x85 0x83 0x81 0x8e 0x8c 0x8a 0x88 0x86 0x84 0x82}
+# CHECK-DAG: xmm9 = {0x90 0x9f 0x9d 0x9b 0x99 0x97 0x95 0x93 0x91 0x9e 0x9c 0x9a 0x98 0x96 0x94 0x92}
+# CHECK-DAG: xmm10 = {0xa0 0xaf 0xad 0xab 0xa9 0xa7 0xa5 0xa3 0xa1 0xae 0xa

[Lldb-commits] [PATCH] D61146: Set a CXXRecordDecl to not be passed in registers if DW_CC_pass_by_reference when loading from DWARF

2019-04-25 Thread Shafik Yaghmour via Phabricator via lldb-commits
shafik created this revision.
shafik added reviewers: jingham, aprantl, teemperor, rsmith.

This will fix a bug where during expression parsing we are not setting a 
`CXXRecordDecl` to not be passed in registers and the resulting code generation 
is wrong.

The DWARF attribute `DW_CC_pass_by_reference` tells us that we should not be 
passing in registers i.e. `RAA_Indirect`.

This change depends this clang change which fixes the fact that the ASTImporter 
does not copy `RecordDeclBits` for `CXXRecordDecl`:

  https://reviews.llvm.org/D61140


https://reviews.llvm.org/D61146

Files:
  
packages/Python/lldbsuite/test/expression_command/argument_passing_restrictions/Makefile
  
packages/Python/lldbsuite/test/expression_command/argument_passing_restrictions/TestArgumentPassingRestrictions.py
  
packages/Python/lldbsuite/test/expression_command/argument_passing_restrictions/main.cpp
  source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp

Index: source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
===
--- source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
+++ source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
@@ -959,6 +959,15 @@
   }
 }
 
+if (calling_convention == llvm::dwarf::DW_CC_pass_by_reference) {
+  clang::CXXRecordDecl *record_decl =
+  m_ast.GetAsCXXRecordDecl(clang_type.GetOpaqueQualType());
+  if (record_decl) {
+record_decl->setArgPassingRestrictions(
+clang::RecordDecl::APK_CannotPassInRegs);
+  }
+}
+
   } break;
 
   case DW_TAG_enumeration_type: {
Index: packages/Python/lldbsuite/test/expression_command/argument_passing_restrictions/main.cpp
===
--- /dev/null
+++ packages/Python/lldbsuite/test/expression_command/argument_passing_restrictions/main.cpp
@@ -0,0 +1,40 @@
+struct Bounds {
+  Bounds() = default;
+  Bounds(const Bounds &b);
+
+  int x, y;
+};
+
+Bounds::Bounds(const Bounds &b) : x(b.x), y(b.y) {}
+
+class Shape {
+static Shape *sp;
+public:
+  static Shape *empty_shape() { return sp;}
+
+  bool check() const { return this == sp;}
+
+  void get_bounds(Bounds &bounds) const{
+if (check())
+{
+  bounds.x = 1;
+  bounds.y = 2;
+  return;
+}
+  }
+
+  Bounds bounds() const {
+  Bounds b;
+  get_bounds(b);
+  return b;
+  }
+};
+
+Shape shape;
+Shape *Shape::sp=&shape;
+
+int main() {
+Shape s;
+
+return Shape::empty_shape()->bounds().x; // break here
+}
Index: packages/Python/lldbsuite/test/expression_command/argument_passing_restrictions/TestArgumentPassingRestrictions.py
===
--- /dev/null
+++ packages/Python/lldbsuite/test/expression_command/argument_passing_restrictions/TestArgumentPassingRestrictions.py
@@ -0,0 +1,29 @@
+"""
+This is a test to ensure that both lldb is reconstructing the right
+calling convention for a CXXRecordDecl as represented by:
+
+   DW_CC_pass_by_reference
+   DW_CC_pass_by_value
+
+and to also make sure that the ASTImporter is copying over this
+setting when importing the CXXRecordDecl via setArgPassingRestrictions.
+"""
+
+
+import lldb
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+
+class TestArgumentPassingRestrictions(TestBase):
+
+  mydir = TestBase.compute_mydir(__file__)
+
+  def test_argument_passing_restrictions(self):
+self.build()
+
+lldbutil.run_to_source_breakpoint(self, '// break here',
+lldb.SBFileSpec("main.cpp", False))
+
+self.expect("expr Shape::empty_shape()->bounds()",
+substrs=['(Bounds) $0 = (x = 1, y = 2)'])
Index: packages/Python/lldbsuite/test/expression_command/argument_passing_restrictions/Makefile
===
--- /dev/null
+++ packages/Python/lldbsuite/test/expression_command/argument_passing_restrictions/Makefile
@@ -0,0 +1,5 @@
+LEVEL = ../../make
+
+CXX_SOURCES := main.cpp
+
+include $(LEVEL)/Makefile.rules
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] r359240 - Another use of the interactive lldb.debugger.

2019-04-25 Thread Jason Molenda via lldb-commits
Author: jmolenda
Date: Thu Apr 25 13:45:10 2019
New Revision: 359240

URL: http://llvm.org/viewvc/llvm-project?rev=359240&view=rev
Log:
Another use of the interactive lldb.debugger.

Modified:
lldb/trunk/packages/Python/lldbsuite/test/python_api/formatters/synth.py

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/python_api/formatters/synth.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/python_api/formatters/synth.py?rev=359240&r1=359239&r2=359240&view=diff
==
--- lldb/trunk/packages/Python/lldbsuite/test/python_api/formatters/synth.py 
(original)
+++ lldb/trunk/packages/Python/lldbsuite/test/python_api/formatters/synth.py 
Thu Apr 25 13:45:10 2019
@@ -92,7 +92,7 @@ def __lldb_init_module(debugger, dict):
 debugger.CreateCategory("JASSynth").AddTypeSynthetic(
 lldb.SBTypeNameSpecifier("JustAStruct"),
 lldb.SBTypeSynthetic.CreateWithClassName("synth.jasSynthProvider"))
-cat = lldb.debugger.CreateCategory("CCCSynth")
+cat = debugger.CreateCategory("CCCSynth")
 cat.AddTypeSynthetic(
 lldb.SBTypeNameSpecifier("CCC"),
 lldb.SBTypeSynthetic.CreateWithClassName("synth.CCCSynthProvider",


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


[Lldb-commits] [PATCH] D61146: Set a CXXRecordDecl to not be passed in registers if DW_CC_pass_by_reference when loading from DWARF

2019-04-25 Thread Shafik Yaghmour via Phabricator via lldb-commits
shafik added a comment.

@rsmith I tagged you in this change in case we are missing any implications in 
using `DW_CC_pass_by_reference` to do 
`setArgPassingRestrictions(clang::RecordDecl::APK_CannotPassInRegs);`


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

https://reviews.llvm.org/D61146



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


[Lldb-commits] [PATCH] D60667: Allow direct comparison of ConstString against StringRef

2019-04-25 Thread Raphael Isemann via Phabricator via lldb-commits
teemperor updated this revision to Diff 196732.
teemperor added a comment.

- Removed the remaining uses of the new operator for comparisons against values 
that are not literals.


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

https://reviews.llvm.org/D60667

Files:
  lldb/include/lldb/Utility/ConstString.h
  lldb/source/Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderDarwin.cpp
  lldb/source/Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderMacOS.cpp
  lldb/source/Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderMacOSXDYLD.cpp
  lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionSourceCode.cpp
  lldb/source/Plugins/ExpressionParser/Clang/ClangUserExpression.cpp
  lldb/source/Plugins/Language/CPlusPlus/LibCxx.cpp
  lldb/source/Plugins/Language/CPlusPlus/LibCxxVector.cpp
  lldb/source/Plugins/Language/CPlusPlus/LibStdcpp.cpp
  lldb/source/Plugins/Language/CPlusPlus/LibStdcppUniquePointer.cpp
  lldb/source/Plugins/Language/ObjC/CF.cpp
  lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntime.cpp
  lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
  lldb/source/Plugins/Platform/Android/PlatformAndroid.cpp
  lldb/source/Plugins/SystemRuntime/MacOSX/SystemRuntimeMacOSX.cpp
  lldb/unittests/Utility/ConstStringTest.cpp

Index: lldb/unittests/Utility/ConstStringTest.cpp
===
--- lldb/unittests/Utility/ConstStringTest.cpp
+++ lldb/unittests/Utility/ConstStringTest.cpp
@@ -89,3 +89,51 @@
   EXPECT_TRUE(null.IsEmpty());
   EXPECT_TRUE(null.IsNull());
 }
+
+TEST(ConstStringTest, CompareConstString) {
+  ConstString foo("foo");
+  ConstString foo2("foo");
+  ConstString bar("bar");
+
+  EXPECT_TRUE(foo == foo2);
+  EXPECT_TRUE(foo2 == foo);
+  EXPECT_TRUE(foo == ConstString("foo"));
+
+  EXPECT_FALSE(foo == bar);
+  EXPECT_FALSE(foo2 == bar);
+  EXPECT_FALSE(foo == ConstString("bar"));
+  EXPECT_FALSE(foo == ConstString("different"));
+  EXPECT_FALSE(foo == ConstString(""));
+  EXPECT_FALSE(foo == ConstString());
+
+  ConstString empty("");
+  EXPECT_FALSE(empty == ConstString("bar"));
+  EXPECT_FALSE(empty == ConstString());
+  EXPECT_TRUE(empty == ConstString(""));
+
+  ConstString null;
+  EXPECT_FALSE(null == ConstString("bar"));
+  EXPECT_TRUE(null == ConstString());
+  EXPECT_FALSE(null == ConstString(""));
+}
+
+TEST(ConstStringTest, CompareStringRef) {
+  ConstString foo("foo");
+
+  EXPECT_TRUE(foo == "foo");
+  EXPECT_TRUE(foo != "");
+  EXPECT_FALSE(foo == static_cast(nullptr));
+  EXPECT_TRUE(foo != "bar");
+
+  ConstString empty("");
+  EXPECT_FALSE(empty == "foo");
+  EXPECT_FALSE(empty != "");
+  EXPECT_FALSE(empty == static_cast(nullptr));
+  EXPECT_TRUE(empty != "bar");
+
+  ConstString null;
+  EXPECT_FALSE(null == "foo");
+  EXPECT_TRUE(null != "");
+  EXPECT_TRUE(null == static_cast(nullptr));
+  EXPECT_TRUE(null != "bar");
+}
Index: lldb/source/Plugins/SystemRuntime/MacOSX/SystemRuntimeMacOSX.cpp
===
--- lldb/source/Plugins/SystemRuntime/MacOSX/SystemRuntimeMacOSX.cpp
+++ lldb/source/Plugins/SystemRuntime/MacOSX/SystemRuntimeMacOSX.cpp
@@ -454,8 +454,7 @@
 ThreadSP SystemRuntimeMacOSX::GetExtendedBacktraceThread(ThreadSP real_thread,
  ConstString type) {
   ThreadSP originating_thread_sp;
-  if (BacktraceRecordingHeadersInitialized() &&
-  type == ConstString("libdispatch")) {
+  if (BacktraceRecordingHeadersInitialized() && type == "libdispatch") {
 Status error;
 
 // real_thread is either an actual, live thread (in which case we need to
@@ -554,7 +553,7 @@
 SystemRuntimeMacOSX::GetExtendedBacktraceForQueueItem(QueueItemSP queue_item_sp,
   ConstString type) {
   ThreadSP extended_thread_sp;
-  if (type != ConstString("libdispatch"))
+  if (type != "libdispatch")
 return extended_thread_sp;
 
   bool stop_id_is_valid = true;
Index: lldb/source/Plugins/Platform/Android/PlatformAndroid.cpp
===
--- lldb/source/Plugins/Platform/Android/PlatformAndroid.cpp
+++ lldb/source/Plugins/Platform/Android/PlatformAndroid.cpp
@@ -302,7 +302,7 @@
const FileSpec &dst_file_spec) {
   // For oat file we can try to fetch additional debug info from the device
   ConstString extension = module_sp->GetFileSpec().GetFileNameExtension();
-  if (extension != ConstString(".oat") && extension != ConstString(".odex"))
+  if (extension != ".oat" && extension != ".odex")
 return Status(
 "Symbol file downloading only supported for oat and odex files");
 
Index: lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
===
--- lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
+++ lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
@@ -1996,8 +1996,8 @@
   //

[Lldb-commits] [PATCH] D60667: Allow direct comparison of ConstString against StringRef

2019-04-25 Thread Raphael Isemann via Phabricator via lldb-commits
teemperor added a comment.

> I didn't mean to imply that `strlen` is called twice.  My point was that 
> there are two linear passes over the string literal:  The first is the call 
> to `strlen` to make the StringRef, and the second is the actual string 
> comparison.

Thanks for the explanation. I reverted the changes that introduce the new 
operator for non-literal values and I'll see if I can replace those by making 
ConstString variables. So this patch now only introduces comparisons against 
literals where the strlen call can be optimized out (which means we only do a 
direct size cmp for both strings and then a strcmp).


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

https://reviews.llvm.org/D60667



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


[Lldb-commits] [lldb] r359249 - [TestTemplateFunction] Add a missing debug info variant.

2019-04-25 Thread Davide Italiano via lldb-commits
Author: davide
Date: Thu Apr 25 15:53:10 2019
New Revision: 359249

URL: http://llvm.org/viewvc/llvm-project?rev=359249&view=rev
Log:
[TestTemplateFunction] Add a missing debug info variant.

Modified:

lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/template-function/TestTemplateFunctions.py

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/template-function/TestTemplateFunctions.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/template-function/TestTemplateFunctions.py?rev=359249&r1=359248&r2=359249&view=diff
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/template-function/TestTemplateFunctions.py
 (original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/template-function/TestTemplateFunctions.py
 Thu Apr 25 15:53:10 2019
@@ -27,6 +27,6 @@ class TemplateFunctionsTestCase(TestBase
 self.do_test_template_function(True)
 
 @skipIfWindows
-@expectedFailureAll(debug_info=["dwarf", "gmodules"])
+@expectedFailureAll(debug_info=["dwarf", "gmodules", "dwo"])
 def test_template_function_without_cast(self):
 self.do_test_template_function(False)


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


[Lldb-commits] [PATCH] D61128: Fix stack unwinding for struct methods

2019-04-25 Thread Adrian McCarthy via Phabricator via lldb-commits
amccarth added a comment.

Please add some detail to the commit message and consider re-titling it.  It 
looks like this patch is actually adding missing functionality rather than 
"fixing" a bug in how structs are handled.  If that's correct, then please make 
the commit message reflect that.

Sorry I didn't get a chance to finish reviewing this today, but I'll try to get 
it done tomorrow.


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D61128



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


[Lldb-commits] [PATCH] D60957: Read ObjC class names in one large read, instead of reading them individually

2019-04-25 Thread Jason Molenda via Phabricator via lldb-commits
jasonmolenda updated this revision to Diff 196776.
jasonmolenda added a comment.

Fix one small bug in the jitted expressions.  Increase the estimated size of 
class names that lldb uses to pre-allocate the string pool buffer.  Added a 
method to read the string pool out of the inferior, to reduce code duplication, 
and have it read the last name to get the full size of the string pool correct.


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D60957

Files:
  AppleObjCRuntimeV2.cpp
  AppleObjCRuntimeV2.h

Index: AppleObjCRuntimeV2.h
===
--- AppleObjCRuntimeV2.h
+++ AppleObjCRuntimeV2.h
@@ -297,7 +297,8 @@
   UpdateISAToDescriptorMapDynamic(RemoteNXMapTable &hash_table);
 
   uint32_t ParseClassInfoArray(const lldb_private::DataExtractor &data,
-   uint32_t num_class_infos);
+   uint32_t num_class_infos, 
+   lldb::DataBufferSP strpool_buffer_sp);
 
   DescriptorMapUpdateResult UpdateISAToDescriptorMapSharedCache();
 
@@ -314,6 +315,10 @@
 
   friend class ClassDescriptorV2;
 
+  lldb::DataBufferSP ReadClassNameStringPool (lldb::addr_t string_pool_addr, 
+ lldb_private::DataExtractor *class_data,
+ uint32_t num_class_infos);
+
   std::unique_ptr m_get_class_info_code;
   lldb::addr_t m_get_class_info_args;
   std::mutex m_get_class_info_args_mutex;
Index: AppleObjCRuntimeV2.cpp
===
--- AppleObjCRuntimeV2.cpp
+++ AppleObjCRuntimeV2.cpp
@@ -79,10 +79,11 @@
 extern "C"
 {
 size_t strlen(const char *);
-char *strncpy (char * s1, const char * s2, size_t n);
+char *strcpy (char * dst, const char * src);
 int printf(const char * format, ...);
 }
 #define DEBUG_PRINTF(fmt, ...) if (should_log) printf(fmt, ## __VA_ARGS__)
+#define UINT32_MAX 0x
 
 typedef struct _NXMapTable {
 void *prototype;
@@ -103,17 +104,22 @@
 {
 Class isa;
 uint32_t hash;
+uint32_t stroffset;
 } __attribute__((__packed__));
 
 uint32_t
 __lldb_apple_objc_v2_get_dynamic_class_info (void *gdb_objc_realized_classes_ptr,
  void *class_infos_ptr,
  uint32_t class_infos_byte_size,
+ void *string_pool_ptr,
+ uint32_t string_pool_byte_size,
  uint32_t should_log)
 {
 DEBUG_PRINTF ("gdb_objc_realized_classes_ptr = %p\n", gdb_objc_realized_classes_ptr);
 DEBUG_PRINTF ("class_infos_ptr = %p\n", class_infos_ptr);
 DEBUG_PRINTF ("class_infos_byte_size = %u\n", class_infos_byte_size);
+DEBUG_PRINTF ("string_pool_ptr = %p\n", string_pool_ptr);
+DEBUG_PRINTF ("string_pool_byte_size = %u\n", string_pool_byte_size);
 const NXMapTable *grc = (const NXMapTable *)gdb_objc_realized_classes_ptr;
 if (grc)
 {
@@ -123,7 +129,8 @@
 const size_t max_class_infos = class_infos_byte_size/sizeof(ClassInfo);
 ClassInfo *class_infos = (ClassInfo *)class_infos_ptr;
 BucketInfo *buckets = (BucketInfo *)grc->buckets;
-
+char *string_pool_base = (char *)string_pool_ptr;
+uint32_t current_strpool_offset = 0;
 uint32_t idx = 0;
 for (unsigned i=0; i<=grc->num_buckets_minus_one; ++i)
 {
@@ -131,12 +138,27 @@
 {
 if (idx < max_class_infos)
 {
-const char *s = buckets[i].name_ptr;
+const char *name = buckets[i].name_ptr;
+const char *s = name;
 uint32_t h = 5381;
 for (unsigned char c = *s; c; c = *++s)
 h = ((h << 5) + h) + c;
 class_infos[idx].hash = h;
 class_infos[idx].isa = buckets[i].isa;
+class_infos[idx].stroffset = UINT32_MAX; // default to no strpool offset
+if (string_pool_base && string_pool_byte_size != 0 && name && h != 0)
+{
+const int name_len = strlen (name);
+const int remaining_strpool = string_pool_byte_size - current_strpool_offset;
+
+if (name_len > 0 && remaining_strpool > (name_len + 1))
+{
+DEBUG_PRINTF ("[%u] name %s copied into stringpool offset %u\n", idx, name, current_strpool_offset);
+strcpy (string_pool_base + current_strpool_offset, name);
+class_infos[idx].stroffset = current_strpool_offset;
+

[Lldb-commits] [PATCH] D61172: [ScriptInterpreter] Pass the debugger instead of the command interpreter

2019-04-25 Thread Jonas Devlieghere via Phabricator via lldb-commits
JDevlieghere created this revision.
JDevlieghere added reviewers: labath, clayborg, jingham.
Herald added a project: LLDB.

As discussed in D61090 , there's no good 
reason for the script interpreter to depend on the command interpreter. When 
looking at the code, it becomes clear that we mostly use the command 
interpreter as a way to access the debugger. Hence, it makes more sense to just 
pass that to the script interpreter directly.

This is part 1 out of 2. I have another patch in the pipeline that changes the 
ownership of the script interpreter to the debugger as well, but I didn't get 
around to finish that today.


Repository:
  rLLDB LLDB

https://reviews.llvm.org/D61172

Files:
  lldb/include/lldb/Core/PluginManager.h
  lldb/include/lldb/Interpreter/ScriptInterpreter.h
  lldb/include/lldb/lldb-private-interfaces.h
  lldb/source/Core/PluginManager.cpp
  lldb/source/Interpreter/CommandInterpreter.cpp
  lldb/source/Interpreter/ScriptInterpreter.cpp
  lldb/source/Plugins/ScriptInterpreter/None/ScriptInterpreterNone.cpp
  lldb/source/Plugins/ScriptInterpreter/None/ScriptInterpreterNone.h
  lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
  lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.h
  lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPythonImpl.h

Index: lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPythonImpl.h
===
--- lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPythonImpl.h
+++ lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPythonImpl.h
@@ -29,7 +29,7 @@
 public:
   friend class IOHandlerPythonInterpreter;
 
-  ScriptInterpreterPythonImpl(CommandInterpreter &interpreter);
+  ScriptInterpreterPythonImpl(Debugger &debugger);
 
   ~ScriptInterpreterPythonImpl() override;
 
@@ -273,8 +273,7 @@
   void IOHandlerInputComplete(IOHandler &io_handler,
   std::string &data) override;
 
-  static lldb::ScriptInterpreterSP
-  CreateInstance(CommandInterpreter &interpreter);
+  static lldb::ScriptInterpreterSP CreateInstance(Debugger &debugger);
 
   // PluginInterface protocol
   lldb_private::ConstString GetPluginName() override;
Index: lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.h
===
--- lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.h
+++ lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.h
@@ -36,8 +36,8 @@
 }
   };
 
-  ScriptInterpreterPython(CommandInterpreter &interpreter)
-  : ScriptInterpreter(interpreter, lldb::eScriptLanguagePython),
+  ScriptInterpreterPython(Debugger &debugger)
+  : ScriptInterpreter(debugger, lldb::eScriptLanguagePython),
 IOHandlerDelegateMultiline("DONE") {}
 
   static void Initialize();
Index: lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
===
--- lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
+++ lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
@@ -441,15 +441,13 @@
   DoFreeLock();
 }
 
-ScriptInterpreterPythonImpl::ScriptInterpreterPythonImpl(
-CommandInterpreter &interpreter)
-: ScriptInterpreterPython(interpreter), m_saved_stdin(), m_saved_stdout(),
+ScriptInterpreterPythonImpl::ScriptInterpreterPythonImpl(Debugger &debugger)
+: ScriptInterpreterPython(debugger), m_saved_stdin(), m_saved_stdout(),
   m_saved_stderr(), m_main_module(),
   m_session_dict(PyInitialValue::Invalid),
   m_sys_module_dict(PyInitialValue::Invalid), m_run_one_line_function(),
   m_run_one_line_str_global(),
-  m_dictionary_name(
-  interpreter.GetDebugger().GetInstanceName().AsCString()),
+  m_dictionary_name(m_debugger.GetInstanceName().AsCString()),
   m_terminal_state(), m_active_io_handler(eIOHandlerNone),
   m_session_is_active(false), m_pty_slave_is_open(false),
   m_valid_session(true), m_lock_count(0), m_command_thread_state(nullptr) {
@@ -495,8 +493,7 @@
 
   run_string.Printf("run_one_line (%s, 'lldb.debugger_unique_id = %" PRIu64
 "; pydoc.pager = pydoc.plainpager')",
-m_dictionary_name.c_str(),
-interpreter.GetDebugger().GetID());
+m_dictionary_name.c_str(), m_debugger.GetID());
   PyRun_SimpleString(run_string.GetData());
 }
 
@@ -549,7 +546,7 @@
 void ScriptInterpreterPythonImpl::IOHandlerInputComplete(IOHandler &io_handler,
  std::string &data) {
   io_handler.SetIsDone(true);
-  bool batch_mode = m_interpreter.GetBatchCommandMode();
+  bool batch_mode = m_debugger.GetCommandInterpreter().GetBatchCommandMode();
 
   switch (m_active_io_handler) {
   case eIOHandlerNone:
@@ -6