[Lldb-commits] [PATCH] D69555: [zorg] Fix LLDBCmakeBuildFactory

[Pavel Labath via Phabricator via lldb-commits]

labath marked an inline comment as done.
labath added a comment.

In D69555#1727882 , @stella.stamenova 
wrote:

> Sadly, I think this broke the windows bot now (assuming it got applied to 
> staging, otherwise I have to figure out what did):
>
> http://lab.llvm.org:8014/builders/lldb-x64-windows-ninja/builds/46/steps/cmake-configure/logs/stdio


I am afraid that was due to 425eeb1b 
 (or 
its combination with this patch, if you will).  I am afraid we have too many 
quotes now :(

In an separate email, @gkistanova wrote:

> In D69555  the problem of quotations around 
> -DLLVM_ENABLE_PROJECTS remains.
>
> > "-DLLVM_ENABLE_PROJECTS=" + ";".join(f.depends_on_projects),


Actually, that's not true. :( The way that this patch resolved the quoting 
problem is by passing the command as an array. You'll notice that originally 
the command was being passed as a string, while now it's an array of strings. 
One does not need to add extra quotes when passing commands as arrays, as the 
array already provides the information about argument boundaries. Adding the 
extra quotes is not necessary and it seems to break stuff in some situations. 
The linux bot does not seem to be affected by this (which actually surprises me 
a lot), but the windows bot gets utterly confused by that.

I think that just removing the extra quotes should make everything happy.




Comment at: zorg/buildbot/builders/LLDBBuilder.py:110
 
-cmake_cmd = [
-"cmake", "-G", "Ninja", os.path.join(os.pardir, f.monorepo_dir, 
"llvm"),
+path = os.path.join(os.pardir, f.monorepo_dir, "llvm")
+cmake_options = [

gkistanova wrote:
> This would build a path per notations on master. Which could be different 
> than what a builder expects. Think of master running on Windows, for example.
> 
> Better use a "/" path separator as these days it seems supported by all 
> platforms we care about.
Thanks. I didn't know about the `LLVMBuildFactory.pathRelativeToBuild` stuff.


Repository:
  rZORG LLVM Github Zorg

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

https://reviews.llvm.org/D69555



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

[Lldb-commits] [PATCH] D69502: [LLDB] [PECOFF] Don't crash in ReadImageDataByRVA for addresses out of range

[Pavel Labath via Phabricator via lldb-commits]

labath accepted this revision.
labath added inline comments.



Comment at: lldb/test/Shell/Minidump/Windows/Inputs/broken-unwind.exe.yaml:29
+  ExceptionTable:  
+RelativeVirtualAddress: 12303
+Size:12

Maybe add a comment that this is the thing which points outside the .pdata (or 
any other) section.


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

https://reviews.llvm.org/D69502



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

[Lldb-commits] [PATCH] D69646: [LLDB] [PECOFF] Fix error handling for executables that object::createBinary error out on

[Pavel Labath via Phabricator via lldb-commits]

labath accepted this revision.
labath added inline comments.



Comment at: lldb/source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp:175-179
+std::string msg = errorToErrorCode(binary.takeError()).message();
+LLDB_LOGF(log,
+  "ObjectFilePECOFF::GetModuleSpecifications() - failed to create 
binary "
+  "for file (%s): %s",
+  file ? file.GetPath().c_str() : "", msg.c_str());

There's an LLDB_LOG_ERROR macro, which makes sure to "handle" the error even if 
logging is disabled. It also handles all the `.c_str()` stuff *and* is able to 
prepend the name of the caller to the log message (if one requests that when 
enabling logging). So, overall, this could just be:
`LLDB_LOG_ERROR(log, binary.takeError(), "Failed to create binary for file 
({1}): {0}", file)`


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D69646



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

[Lldb-commits] [PATCH] D69641: [Symbol] Change ClangASTContext::GetCXXClassName return type

[Pavel Labath via Phabricator via lldb-commits]

labath accepted this revision.
labath added a comment.

awesome


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69641



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

[Lldb-commits] [PATCH] D69646: [LLDB] [PECOFF] Fix error handling for executables that object::createBinary error out on

[Martin Storsjö via Phabricator via lldb-commits]

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



Comment at: lldb/source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp:175-179
+std::string msg = errorToErrorCode(binary.takeError()).message();
+LLDB_LOGF(log,
+  "ObjectFilePECOFF::GetModuleSpecifications() - failed to create 
binary "
+  "for file (%s): %s",
+  file ? file.GetPath().c_str() : "", msg.c_str());

labath wrote:
> There's an LLDB_LOG_ERROR macro, which makes sure to "handle" the error even 
> if logging is disabled. It also handles all the `.c_str()` stuff *and* is 
> able to prepend the name of the caller to the log message (if one requests 
> that when enabling logging). So, overall, this could just be:
> `LLDB_LOG_ERROR(log, binary.takeError(), "Failed to create binary for file 
> ({1}): {0}", file)`
Oh, awesome, that's much neater.


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D69646



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

[Lldb-commits] [PATCH] D69646: [LLDB] [PECOFF] Fix error handling for executables that object::createBinary error out on

[Martin Storsjö via Phabricator via lldb-commits]

mstorsjo updated this revision to Diff 227236.
mstorsjo edited the summary of this revision.
mstorsjo added a comment.

Using LLDB_LOG_ERROR instead of formatting the error to a string before 
invoking logging macros.


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

https://reviews.llvm.org/D69646

Files:
  lldb/source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp
  lldb/test/Shell/ObjectFile/PECOFF/invalid-export-table.yaml

Index: lldb/test/Shell/ObjectFile/PECOFF/invalid-export-table.yaml
===
--- /dev/null
+++ lldb/test/Shell/ObjectFile/PECOFF/invalid-export-table.yaml
@@ -0,0 +1,81 @@
+## Test that errors in loading an exe doesn't crash lldb.
+## The ExportTable RelativeVirtualAddress is out of bounds here.
+
+# RUN: yaml2obj %s > %t.exe
+# RUN: %lldb %t.exe 2>&1 | FileCheck %s
+
+# CHECK: error: '{{.*}}' doesn't contain any {{.*}} platform architectures
+--- !COFF
+OptionalHeader:
+  AddressOfEntryPoint: 4096
+  ImageBase:   1073741824
+  SectionAlignment: 4096
+  FileAlignment:   512
+  MajorOperatingSystemVersion: 6
+  MinorOperatingSystemVersion: 0
+  MajorImageVersion: 0
+  MinorImageVersion: 0
+  MajorSubsystemVersion: 6
+  MinorSubsystemVersion: 0
+  Subsystem:   IMAGE_SUBSYSTEM_WINDOWS_CUI
+  DLLCharacteristics: [ IMAGE_DLL_CHARACTERISTICS_HIGH_ENTROPY_VA, IMAGE_DLL_CHARACTERISTICS_DYNAMIC_BASE, IMAGE_DLL_CHARACTERISTICS_NX_COMPAT, IMAGE_DLL_CHARACTERISTICS_TERMINAL_SERVER_AWARE ]
+  SizeOfStackReserve: 1048576
+  SizeOfStackCommit: 4096
+  SizeOfHeapReserve: 1048576
+  SizeOfHeapCommit: 4096
+  ExportTable:
+RelativeVirtualAddress: 12345678
+Size:100
+  ImportTable:
+RelativeVirtualAddress: 0
+Size:0
+  ResourceTable:
+RelativeVirtualAddress: 0
+Size:0
+  ExceptionTable:
+RelativeVirtualAddress: 0
+Size:0
+  CertificateTable:
+RelativeVirtualAddress: 0
+Size:0
+  BaseRelocationTable:
+RelativeVirtualAddress: 0
+Size:0
+  Debug:
+RelativeVirtualAddress: 0
+Size:0
+  Architecture:
+RelativeVirtualAddress: 0
+Size:0
+  GlobalPtr:
+RelativeVirtualAddress: 0
+Size:0
+  TlsTable:
+RelativeVirtualAddress: 0
+Size:0
+  LoadConfigTable:
+RelativeVirtualAddress: 0
+Size:0
+  BoundImport:
+RelativeVirtualAddress: 0
+Size:0
+  IAT:
+RelativeVirtualAddress: 0
+Size:0
+  DelayImportDescriptor:
+RelativeVirtualAddress: 0
+Size:0
+  ClrRuntimeHeader:
+RelativeVirtualAddress: 0
+Size:0
+header:
+  Machine: IMAGE_FILE_MACHINE_AMD64
+  Characteristics: [ IMAGE_FILE_EXECUTABLE_IMAGE, IMAGE_FILE_LARGE_ADDRESS_AWARE ]
+sections:
+  - Name:.text
+Characteristics: [ IMAGE_SCN_CNT_CODE, IMAGE_SCN_MEM_EXECUTE, IMAGE_SCN_MEM_READ ]
+VirtualAddress:  4096
+VirtualSize: 1
+SectionData: C3
+symbols: []
+...
Index: lldb/source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp
===
--- lldb/source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp
+++ lldb/source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp
@@ -167,9 +167,15 @@
   if (!data_sp || !ObjectFilePECOFF::MagicBytesMatch(data_sp))
 return initial_count;
 
+  Log *log(GetLogIfAllCategoriesSet(LIBLLDB_LOG_OBJECT));
+
   auto binary = llvm::object::createBinary(file.GetPath());
-  if (!binary)
+
+  if (!binary) {
+LLDB_LOG_ERROR(log, binary.takeError(),
+   "Failed to create binary for file ({1}): {0}", file);
 return initial_count;
+  }
 
   if (!binary->getBinary()->isCOFF() &&
   !binary->getBinary()->isCOFFImportFile())
@@ -242,11 +248,8 @@
 
   auto binary = llvm::object::createBinary(m_file.GetPath());
   if (!binary) {
-LLDB_LOGF(log,
-  "ObjectFilePECOFF::CreateBinary() - failed to create binary "
-  "for file (%s): %s",
-  m_file ? m_file.GetPath().c_str() : "",
-  errorToErrorCode(binary.takeError()).message().c_str());
+LLDB_LOG_ERROR(log, binary.takeError(),
+   "Failed to create binary for file ({1}): {0}", m_file);
 return false;
   }
 
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D69589: [lldb] Refactor all POST_BUILD commands into targets

[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 great to me. Maybe wait a while to see if anyone else has any 
thoughts on this?

This not your fault, but the thing that bothers me about this build process 
(and which this patch makes visible) is how the locations of the python files 
in source bear absolutely no resemblance to the locations the files will end up 
installed.  For instance, I would never have expected that something from the 
"examples" folder ends up in an actual shippable artifact. I think it would be 
great if we could rearrange the sources so that their source layout roughly 
matches the way in which they are going to be used...




Comment at: lldb/CMakeLists.txt:133
+  add_copy_file_target(lldb_python_init
+FILES  "${lldb_scripts_dir}/lldb.py"
+DEST_DIR   "${lldb_python_build_path}"

hhb wrote:
> labath wrote:
> > Would it be possible to just make the swig step place this file into the 
> > correct place directly?
> The difficulty is that, there is a config time path dependency like this:
> 
> swig_wrapper -> liblldb -> finish_swig (renamed to lldb_python_packages in 
> this change)
> 
> Where liblldb uses the path of LLDBWrapPython.cpp in swig_wrapper. And here 
> we reference the path of liblldb, to calculate the right path for python 
> packages.
> 
> That means when swig_wrapper is created, we don't have a good way to figure 
> out the right path for python packages and put the file there directly.
> 
> The best way to solve this is to hard code liblldb path for framework build. 
> I.e. replace line 92 here:
> 
> ```
> get_target_property(liblldb_build_dir liblldb LIBRARY_OUTPUT_DIRECTORY)
> ```
> 
> With something more constant. This removes the liblldb -> finish_swig 
> dependency. Then all the code here can be moved to scripts/CMakeLists.txt (I 
> think they belong there better anyway). And swig_wrapper can get access to 
> python package path.
> 
> The only question is whether we can / should "predict" liblldb path for 
> framework... I'll look more into this. But it probably deserves a separate 
> change.
Ok, that sounds fair. I think it would be great if this stuff could be moved to 
the scripts folder.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69589



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

[Lldb-commits] [PATCH] D69503: [LLDB] [Windows] Don't crash if the debugged process is unable to start up

[Martin Storsjö via Phabricator via lldb-commits]

mstorsjo updated this revision to Diff 227242.
mstorsjo edited the summary of this revision.
mstorsjo added a comment.

Changed to use Adrian's fix suggestion, and added a testcase for it (which only 
is executed on x86_64, as it uses a pre-canned exe in yaml form, but a similar 
testcase for arm64 also runs fine).


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

https://reviews.llvm.org/D69503

Files:
  lldb/source/Plugins/Process/Windows/Common/ProcessDebugger.cpp
  lldb/source/Plugins/Process/Windows/Common/ProcessDebugger.h
  lldb/source/Plugins/Process/Windows/Common/ProcessWindows.cpp
  lldb/test/Shell/Process/Windows/launch_failure.yaml

Index: lldb/test/Shell/Process/Windows/launch_failure.yaml
===
--- /dev/null
+++ lldb/test/Shell/Process/Windows/launch_failure.yaml
@@ -0,0 +1,90 @@
+## Test that we don't crash when the process fails to launch before reaching
+## the initial stop. This test exe has a dependency on NonExistent.dll.
+
+# REQUIRES: system-windows
+# REQUIRES: native && target-x86_64
+
+# RUN: yaml2obj %s > %t.exe
+# RUN: %lldb %t.exe -o run 2>&1 | FileCheck %s
+
+# CHECK: error: process launch failed: unknown error
+
+--- !COFF
+OptionalHeader:
+  AddressOfEntryPoint: 4096
+  ImageBase:   1073741824
+  SectionAlignment: 4096
+  FileAlignment:   512
+  MajorOperatingSystemVersion: 6
+  MinorOperatingSystemVersion: 0
+  MajorImageVersion: 0
+  MinorImageVersion: 0
+  MajorSubsystemVersion: 6
+  MinorSubsystemVersion: 0
+  Subsystem:   IMAGE_SUBSYSTEM_WINDOWS_CUI
+  DLLCharacteristics: [ IMAGE_DLL_CHARACTERISTICS_HIGH_ENTROPY_VA, IMAGE_DLL_CHARACTERISTICS_DYNAMIC_BASE, IMAGE_DLL_CHARACTERISTICS_NX_COMPAT, IMAGE_DLL_CHARACTERISTICS_TERMINAL_SERVER_AWARE ]
+  SizeOfStackReserve: 1048576
+  SizeOfStackCommit: 4096
+  SizeOfHeapReserve: 1048576
+  SizeOfHeapCommit: 4096
+  ExportTable:
+RelativeVirtualAddress: 0
+Size:0
+  ImportTable:
+RelativeVirtualAddress: 8192
+Size:40
+  ResourceTable:
+RelativeVirtualAddress: 0
+Size:0
+  ExceptionTable:
+RelativeVirtualAddress: 0
+Size:0
+  CertificateTable:
+RelativeVirtualAddress: 0
+Size:0
+  BaseRelocationTable:
+RelativeVirtualAddress: 0
+Size:0
+  Debug:
+RelativeVirtualAddress: 0
+Size:0
+  Architecture:
+RelativeVirtualAddress: 0
+Size:0
+  GlobalPtr:
+RelativeVirtualAddress: 0
+Size:0
+  TlsTable:
+RelativeVirtualAddress: 0
+Size:0
+  LoadConfigTable:
+RelativeVirtualAddress: 0
+Size:0
+  BoundImport:
+RelativeVirtualAddress: 0
+Size:0
+  IAT:
+RelativeVirtualAddress: 8248
+Size:16
+  DelayImportDescriptor:
+RelativeVirtualAddress: 0
+Size:0
+  ClrRuntimeHeader:
+RelativeVirtualAddress: 0
+Size:0
+header:
+  Machine: IMAGE_FILE_MACHINE_AMD64
+  Characteristics: [ IMAGE_FILE_EXECUTABLE_IMAGE, IMAGE_FILE_LARGE_ADDRESS_AWARE ]
+sections:
+  - Name:.text
+Characteristics: [ IMAGE_SCN_CNT_CODE, IMAGE_SCN_MEM_EXECUTE, IMAGE_SCN_MEM_READ ]
+VirtualAddress:  4096
+VirtualSize: 7
+SectionData: 48FF253110
+  - Name:.rdata
+Characteristics: [ IMAGE_SCN_CNT_INITIALIZED_DATA, IMAGE_SCN_MEM_READ ]
+VirtualAddress:  8192
+VirtualSize: 96
+SectionData: 2820502038204820482066756E634E6F6E4578697374656E742E646C6C00
+symbols: []
+...
Index: lldb/source/Plugins/Process/Windows/Common/ProcessWindows.cpp
===
--- lldb/source/Plugins/Process/Windows/Common/ProcessWindows.cpp
+++ lldb/source/Plugins/Process/Windows/Common/ProcessWindows.cpp
@@ -625,16 +625,7 @@
   SetProcessExitStatus(GetID(), true, 0, exit_code);
   SetPrivateState(eStateExited);
 
-  // If the process exits before any initial stop then notify the debugger
-  // of the error otherwise WaitForDebuggerConnection() will be blocked.
-  // An example of this issue is when a process fails to load a dependent DLL.
-  if (m_session_data && !m_session_data->m_initial_stop_received) {
-Status error(exit_code, eErrorTypeWin32);
-OnDebuggerError(error, 0);
-  }
-
-  // Reset the session.
-  m_session_data.reset();
+  ProcessDebugger::OnExitProcess(exit_code);
 }
 
 void ProcessWindows::OnDebuggerConnected(lldb::addr_t image_base) {
Index: lldb/source/Plugins/Process/Windows/Common/ProcessDebugger.h
===
--- lldb/source/Plugins/Process/Windows/Common/ProcessDebugger.h
+++ lldb/source/Plugins/Process/Windows/Common/ProcessDebugger.h
@@ -48,6 +48,8 @@
 class ProcessDebugger {
 

[Lldb-commits] [PATCH] D69619: [lldb/lit] Introduce %clang_host substitutions

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

Thanks guys.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69619



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

[Lldb-commits] [PATCH] D69502: [LLDB] [PECOFF] Don't crash in ReadImageDataByRVA for addresses out of range

[Martin Storsjö via Phabricator via lldb-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG7e1a3076419d: [LLDB] [PECOFF] Don't crash in 
ReadImageDataByRVA for addresses out of range (authored by mstorsjo).

Changed prior to commit:
  https://reviews.llvm.org/D69502?vs=227183&id=227246#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69502

Files:
  lldb/source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp
  lldb/test/Shell/Minidump/Windows/Inputs/broken-unwind.dmp.yaml
  lldb/test/Shell/Minidump/Windows/Inputs/broken-unwind.exe.yaml
  lldb/test/Shell/Minidump/Windows/broken-unwind.test

Index: lldb/test/Shell/Minidump/Windows/broken-unwind.test
===
--- /dev/null
+++ lldb/test/Shell/Minidump/Windows/broken-unwind.test
@@ -0,0 +1,7 @@
+Test that we can cope with broken unwind information that suggests
+reading out of bounds.
+
+RUN: yaml2obj %S/Inputs/broken-unwind.exe.yaml > %T/broken-unwind.exe
+RUN: yaml2obj %S/Inputs/broken-unwind.dmp.yaml > %T/broken-unwind.dmp
+RUN: %lldb -O "settings set target.exec-search-paths %T" \
+RUN:   -c %T/broken-unwind.dmp -o "image show-unwind -a 0xb1000" -o exit
Index: lldb/test/Shell/Minidump/Windows/Inputs/broken-unwind.exe.yaml
===
--- /dev/null
+++ lldb/test/Shell/Minidump/Windows/Inputs/broken-unwind.exe.yaml
@@ -0,0 +1,87 @@
+# The ExceptionTable RelativeVirtualAddress below points outside of allocated
+# sections.
+
+--- !COFF
+OptionalHeader:
+  AddressOfEntryPoint: 4224
+  ImageBase:   4194304
+  SectionAlignment: 4096
+  FileAlignment:   512
+  MajorOperatingSystemVersion: 6
+  MinorOperatingSystemVersion: 0
+  MajorImageVersion: 0
+  MinorImageVersion: 0
+  MajorSubsystemVersion: 6
+  MinorSubsystemVersion: 0
+  Subsystem:   IMAGE_SUBSYSTEM_WINDOWS_CUI
+  DLLCharacteristics: [ IMAGE_DLL_CHARACTERISTICS_DYNAMIC_BASE, IMAGE_DLL_CHARACTERISTICS_NX_COMPAT, IMAGE_DLL_CHARACTERISTICS_NO_SEH, IMAGE_DLL_CHARACTERISTICS_TERMINAL_SERVER_AWARE ]
+  SizeOfStackReserve: 1048576
+  SizeOfStackCommit: 4096
+  SizeOfHeapReserve: 1048576
+  SizeOfHeapCommit: 4096
+  ExportTable: 
+RelativeVirtualAddress: 8327
+Size:90
+  ImportTable: 
+RelativeVirtualAddress: 0
+Size:0
+  ResourceTable:   
+RelativeVirtualAddress: 0
+Size:0
+  ExceptionTable:  
+RelativeVirtualAddress: 12303
+Size:12
+  CertificateTable: 
+RelativeVirtualAddress: 0
+Size:0
+  BaseRelocationTable: 
+RelativeVirtualAddress: 0
+Size:0
+  Debug:   
+RelativeVirtualAddress: 8192
+Size:28
+  Architecture:
+RelativeVirtualAddress: 0
+Size:0
+  GlobalPtr:   
+RelativeVirtualAddress: 0
+Size:0
+  TlsTable:
+RelativeVirtualAddress: 0
+Size:0
+  LoadConfigTable: 
+RelativeVirtualAddress: 0
+Size:0
+  BoundImport: 
+RelativeVirtualAddress: 0
+Size:0
+  IAT: 
+RelativeVirtualAddress: 0
+Size:0
+  DelayImportDescriptor: 
+RelativeVirtualAddress: 0
+Size:0
+  ClrRuntimeHeader: 
+RelativeVirtualAddress: 0
+Size:0
+header:
+  Machine: IMAGE_FILE_MACHINE_I386
+  Characteristics: [ IMAGE_FILE_EXECUTABLE_IMAGE, IMAGE_FILE_32BIT_MACHINE ]
+sections:
+  - Name:.text
+Characteristics: [ IMAGE_SCN_CNT_CODE, IMAGE_SCN_MEM_EXECUTE, IMAGE_SCN_MEM_READ ]
+VirtualAddress:  4096
+VirtualSize: 22
+SectionData: 50894C24048B4C24040FAF4C2404890C248B042459C3
+  - Name:.rdata
+Characteristics: [ IMAGE_SCN_CNT_INITIALIZED_DATA, IMAGE_SCN_MEM_READ ]
+VirtualAddress:  8192
+VirtualSize: 236
+SectionData: A565B65C02006B001C201C0652534453E092B2141AD8F1B44C4C44205044422E0100443A5C757073747265616D5C6275696C645C746F6F6C735C6C6C64625C6C69745C4D6F64756C65735C5045434F46465C4F75747075745C6578706F72742D646C6C66756E632E79616D6C2E746D702E70646200AF2002000100CB20D320D7206578706F72742D646C6C66756E632E79616D6C2E746D702E646C6C10D9200100446C6C46756E63010101000102
+  - Name:.pdata
+Characteristics: [ IMAGE_SCN_CNT_INITIALIZED_DATA, IMAGE_SCN_MEM_READ ]
+VirtualAddress:  12288
+VirtualSize: 12
+SectionData: '00101610E420'
+symbols: []
+...
Index: lldb/test/Shell/Minidump/Windows/Inputs/broken-unwind.dmp.yaml
===
--- /dev/null
+++ lldb/test/Shell/Minidump/Windows/Inputs/broken-unwind.dmp.yaml
@@ -0,0 +1,35 @@
+--- !minidump
+Streams:
+  - Type:ModuleList
+Modules:
+  -

[Lldb-commits] [PATCH] D69646: [LLDB] [PECOFF] Fix error handling for executables that object::createBinary error out on

[Martin Storsjö via Phabricator via lldb-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG3db1d138b117: [LLDB] [PECOFF] Fix error handling for 
executables that object::createBinary… (authored by mstorsjo).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69646

Files:
  lldb/source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp
  lldb/test/Shell/ObjectFile/PECOFF/invalid-export-table.yaml

Index: lldb/test/Shell/ObjectFile/PECOFF/invalid-export-table.yaml
===
--- /dev/null
+++ lldb/test/Shell/ObjectFile/PECOFF/invalid-export-table.yaml
@@ -0,0 +1,81 @@
+## Test that errors in loading an exe doesn't crash lldb.
+## The ExportTable RelativeVirtualAddress is out of bounds here.
+
+# RUN: yaml2obj %s > %t.exe
+# RUN: %lldb %t.exe 2>&1 | FileCheck %s
+
+# CHECK: error: '{{.*}}' doesn't contain any {{.*}} platform architectures
+--- !COFF
+OptionalHeader:
+  AddressOfEntryPoint: 4096
+  ImageBase:   1073741824
+  SectionAlignment: 4096
+  FileAlignment:   512
+  MajorOperatingSystemVersion: 6
+  MinorOperatingSystemVersion: 0
+  MajorImageVersion: 0
+  MinorImageVersion: 0
+  MajorSubsystemVersion: 6
+  MinorSubsystemVersion: 0
+  Subsystem:   IMAGE_SUBSYSTEM_WINDOWS_CUI
+  DLLCharacteristics: [ IMAGE_DLL_CHARACTERISTICS_HIGH_ENTROPY_VA, IMAGE_DLL_CHARACTERISTICS_DYNAMIC_BASE, IMAGE_DLL_CHARACTERISTICS_NX_COMPAT, IMAGE_DLL_CHARACTERISTICS_TERMINAL_SERVER_AWARE ]
+  SizeOfStackReserve: 1048576
+  SizeOfStackCommit: 4096
+  SizeOfHeapReserve: 1048576
+  SizeOfHeapCommit: 4096
+  ExportTable:
+RelativeVirtualAddress: 12345678
+Size:100
+  ImportTable:
+RelativeVirtualAddress: 0
+Size:0
+  ResourceTable:
+RelativeVirtualAddress: 0
+Size:0
+  ExceptionTable:
+RelativeVirtualAddress: 0
+Size:0
+  CertificateTable:
+RelativeVirtualAddress: 0
+Size:0
+  BaseRelocationTable:
+RelativeVirtualAddress: 0
+Size:0
+  Debug:
+RelativeVirtualAddress: 0
+Size:0
+  Architecture:
+RelativeVirtualAddress: 0
+Size:0
+  GlobalPtr:
+RelativeVirtualAddress: 0
+Size:0
+  TlsTable:
+RelativeVirtualAddress: 0
+Size:0
+  LoadConfigTable:
+RelativeVirtualAddress: 0
+Size:0
+  BoundImport:
+RelativeVirtualAddress: 0
+Size:0
+  IAT:
+RelativeVirtualAddress: 0
+Size:0
+  DelayImportDescriptor:
+RelativeVirtualAddress: 0
+Size:0
+  ClrRuntimeHeader:
+RelativeVirtualAddress: 0
+Size:0
+header:
+  Machine: IMAGE_FILE_MACHINE_AMD64
+  Characteristics: [ IMAGE_FILE_EXECUTABLE_IMAGE, IMAGE_FILE_LARGE_ADDRESS_AWARE ]
+sections:
+  - Name:.text
+Characteristics: [ IMAGE_SCN_CNT_CODE, IMAGE_SCN_MEM_EXECUTE, IMAGE_SCN_MEM_READ ]
+VirtualAddress:  4096
+VirtualSize: 1
+SectionData: C3
+symbols: []
+...
Index: lldb/source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp
===
--- lldb/source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp
+++ lldb/source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp
@@ -167,9 +167,15 @@
   if (!data_sp || !ObjectFilePECOFF::MagicBytesMatch(data_sp))
 return initial_count;
 
+  Log *log(GetLogIfAllCategoriesSet(LIBLLDB_LOG_OBJECT));
+
   auto binary = llvm::object::createBinary(file.GetPath());
-  if (!binary)
+
+  if (!binary) {
+LLDB_LOG_ERROR(log, binary.takeError(),
+   "Failed to create binary for file ({1}): {0}", file);
 return initial_count;
+  }
 
   if (!binary->getBinary()->isCOFF() &&
   !binary->getBinary()->isCOFFImportFile())
@@ -242,11 +248,8 @@
 
   auto binary = llvm::object::createBinary(m_file.GetPath());
   if (!binary) {
-LLDB_LOGF(log,
-  "ObjectFilePECOFF::CreateBinary() - failed to create binary "
-  "for file (%s): %s",
-  m_file ? m_file.GetPath().c_str() : "",
-  errorToErrorCode(binary.takeError()).message().c_str());
+LLDB_LOG_ERROR(log, binary.takeError(),
+   "Failed to create binary for file ({1}): {0}", m_file);
 return false;
   }
 
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D69503: [LLDB] [Windows] Don't crash if the debugged process is unable to start up

[Martin Storsjö via Phabricator via lldb-commits]

This revision was not accepted when it landed; it landed in state "Needs 
Review".
This revision was automatically updated to reflect the committed changes.
Closed by commit rG403cd574b6d9: [LLDB] [Windows] Fix Windows-specific race 
condition in LLDB for session… (authored by mstorsjo).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69503

Files:
  lldb/source/Plugins/Process/Windows/Common/ProcessDebugger.cpp
  lldb/source/Plugins/Process/Windows/Common/ProcessDebugger.h
  lldb/source/Plugins/Process/Windows/Common/ProcessWindows.cpp
  lldb/test/Shell/Process/Windows/launch_failure.yaml

Index: lldb/test/Shell/Process/Windows/launch_failure.yaml
===
--- /dev/null
+++ lldb/test/Shell/Process/Windows/launch_failure.yaml
@@ -0,0 +1,90 @@
+## Test that we don't crash when the process fails to launch before reaching
+## the initial stop. This test exe has a dependency on NonExistent.dll.
+
+# REQUIRES: system-windows
+# REQUIRES: native && target-x86_64
+
+# RUN: yaml2obj %s > %t.exe
+# RUN: %lldb %t.exe -o run 2>&1 | FileCheck %s
+
+# CHECK: error: process launch failed: unknown error
+
+--- !COFF
+OptionalHeader:
+  AddressOfEntryPoint: 4096
+  ImageBase:   1073741824
+  SectionAlignment: 4096
+  FileAlignment:   512
+  MajorOperatingSystemVersion: 6
+  MinorOperatingSystemVersion: 0
+  MajorImageVersion: 0
+  MinorImageVersion: 0
+  MajorSubsystemVersion: 6
+  MinorSubsystemVersion: 0
+  Subsystem:   IMAGE_SUBSYSTEM_WINDOWS_CUI
+  DLLCharacteristics: [ IMAGE_DLL_CHARACTERISTICS_HIGH_ENTROPY_VA, IMAGE_DLL_CHARACTERISTICS_DYNAMIC_BASE, IMAGE_DLL_CHARACTERISTICS_NX_COMPAT, IMAGE_DLL_CHARACTERISTICS_TERMINAL_SERVER_AWARE ]
+  SizeOfStackReserve: 1048576
+  SizeOfStackCommit: 4096
+  SizeOfHeapReserve: 1048576
+  SizeOfHeapCommit: 4096
+  ExportTable:
+RelativeVirtualAddress: 0
+Size:0
+  ImportTable:
+RelativeVirtualAddress: 8192
+Size:40
+  ResourceTable:
+RelativeVirtualAddress: 0
+Size:0
+  ExceptionTable:
+RelativeVirtualAddress: 0
+Size:0
+  CertificateTable:
+RelativeVirtualAddress: 0
+Size:0
+  BaseRelocationTable:
+RelativeVirtualAddress: 0
+Size:0
+  Debug:
+RelativeVirtualAddress: 0
+Size:0
+  Architecture:
+RelativeVirtualAddress: 0
+Size:0
+  GlobalPtr:
+RelativeVirtualAddress: 0
+Size:0
+  TlsTable:
+RelativeVirtualAddress: 0
+Size:0
+  LoadConfigTable:
+RelativeVirtualAddress: 0
+Size:0
+  BoundImport:
+RelativeVirtualAddress: 0
+Size:0
+  IAT:
+RelativeVirtualAddress: 8248
+Size:16
+  DelayImportDescriptor:
+RelativeVirtualAddress: 0
+Size:0
+  ClrRuntimeHeader:
+RelativeVirtualAddress: 0
+Size:0
+header:
+  Machine: IMAGE_FILE_MACHINE_AMD64
+  Characteristics: [ IMAGE_FILE_EXECUTABLE_IMAGE, IMAGE_FILE_LARGE_ADDRESS_AWARE ]
+sections:
+  - Name:.text
+Characteristics: [ IMAGE_SCN_CNT_CODE, IMAGE_SCN_MEM_EXECUTE, IMAGE_SCN_MEM_READ ]
+VirtualAddress:  4096
+VirtualSize: 7
+SectionData: 48FF253110
+  - Name:.rdata
+Characteristics: [ IMAGE_SCN_CNT_INITIALIZED_DATA, IMAGE_SCN_MEM_READ ]
+VirtualAddress:  8192
+VirtualSize: 96
+SectionData: 2820502038204820482066756E634E6F6E4578697374656E742E646C6C00
+symbols: []
+...
Index: lldb/source/Plugins/Process/Windows/Common/ProcessWindows.cpp
===
--- lldb/source/Plugins/Process/Windows/Common/ProcessWindows.cpp
+++ lldb/source/Plugins/Process/Windows/Common/ProcessWindows.cpp
@@ -625,16 +625,7 @@
   SetProcessExitStatus(GetID(), true, 0, exit_code);
   SetPrivateState(eStateExited);
 
-  // If the process exits before any initial stop then notify the debugger
-  // of the error otherwise WaitForDebuggerConnection() will be blocked.
-  // An example of this issue is when a process fails to load a dependent DLL.
-  if (m_session_data && !m_session_data->m_initial_stop_received) {
-Status error(exit_code, eErrorTypeWin32);
-OnDebuggerError(error, 0);
-  }
-
-  // Reset the session.
-  m_session_data.reset();
+  ProcessDebugger::OnExitProcess(exit_code);
 }
 
 void ProcessWindows::OnDebuggerConnected(lldb::addr_t image_base) {
Index: lldb/source/Plugins/Process/Windows/Common/ProcessDebugger.h
===
--- lldb/source/Plugins/Process/Windows/Common/ProcessDebugger.h
+++ lldb/source/Plugins/Process/Windows/Common/ProcessDebugger.h
@@ -48,6 +48,8 @@
 class ProcessDe

[Lldb-commits] [lldb] 9c73925 - [lldb/lit] Introduce %clang_host substitutions

[Pavel Labath via lldb-commits]

Author: Pavel Labath
Date: 2019-10-31T10:40:37+01:00
New Revision: 9c739252261ea762d1bbbd8234d93c9038711fcd

URL: 
https://github.com/llvm/llvm-project/commit/9c739252261ea762d1bbbd8234d93c9038711fcd
DIFF: 
https://github.com/llvm/llvm-project/commit/9c739252261ea762d1bbbd8234d93c9038711fcd.diff

LOG: [lldb/lit] Introduce %clang_host substitutions

Summary:
This patch addresses an ambiguity in how our existing tests invoke the
compiler. Roughly two thirds of our current "shell" tests invoke the
compiler to build the executables for the host. However, there is also
a significant number of tests which don't build a host binary (because
they don't need to run it) and instead they hardcode a certain target.

We also have code which adds a bunch of default arguments to the %clang
substitutions. However, most of these arguments only really make sense
for the host compilation. So far, this has worked mostly ok, because the
arguments we were adding were not conflicting with the target-hardcoding
tests (though they did provoke an occasional "argument unused" warning).

However, this started to break down when we wanted to use
target-hardcoding clang-cl tests (D69031) because clang-cl has a
substantially different command line, and it was getting very confused
by some of the arguments we were adding on non-windows hosts.

This patch avoid this problem by creating separate %clang(xx,_cl)_host
substutitions, which are specifically meant to be used for compiling
host binaries. All funny host-specific options are moved there. To
ensure that the regular %clang substitutions are not used for compiling
host binaries (skipping the extra arguments) I employ a little
hac^H^H^Htrick -- I add an invalid --target argument to the %clang
substitution, which means that one has to use an explicit --target in
order for the compilation to succeed.

Reviewers: JDevlieghere, aprantl, mstorsjo, espindola

Subscribers: emaste, arichardson, MaskRay, jfb, lldb-commits

Tags: #lldb

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

Added: 


Modified: 
lldb/test/Shell/Commands/command-script-import.test
lldb/test/Shell/Driver/TestSingleQuote.test
lldb/test/Shell/Driver/TestTarget.test
lldb/test/Shell/ExecControl/StopHook/stop-hook-threads.test
lldb/test/Shell/ExecControl/StopHook/stop-hook.test
lldb/test/Shell/Expr/TestIRMemoryMap.test
lldb/test/Shell/Expr/TestIRMemoryMapWindows.test
lldb/test/Shell/Heap/heap-cstr.test
lldb/test/Shell/Host/TestCustomShell.test
lldb/test/Shell/ObjectFile/ELF/minidebuginfo-set-and-hit-breakpoint.test
lldb/test/Shell/Process/TestEnvironment.test
lldb/test/Shell/Register/aarch64-fp-read.test
lldb/test/Shell/Register/aarch64-gp-read.test
lldb/test/Shell/Register/arm-fp-read.test
lldb/test/Shell/Register/arm-gp-read.test
lldb/test/Shell/Register/x86-64-gp-read.test
lldb/test/Shell/Register/x86-64-gp-write.test
lldb/test/Shell/Register/x86-64-read.test
lldb/test/Shell/Register/x86-64-write.test
lldb/test/Shell/Register/x86-64-xmm16-read.test
lldb/test/Shell/Register/x86-64-xmm16-write.test
lldb/test/Shell/Register/x86-64-ymm-read.test
lldb/test/Shell/Register/x86-64-ymm-write.test
lldb/test/Shell/Register/x86-64-ymm16-read.test
lldb/test/Shell/Register/x86-64-ymm16-write.test
lldb/test/Shell/Register/x86-64-zmm-read.test
lldb/test/Shell/Register/x86-64-zmm-write.test
lldb/test/Shell/Register/x86-gp-read.test
lldb/test/Shell/Register/x86-gp-write.test
lldb/test/Shell/Register/x86-mm-xmm-read.test
lldb/test/Shell/Register/x86-mm-xmm-write.test
lldb/test/Shell/Register/x86-ymm-read.test
lldb/test/Shell/Register/x86-ymm-write.test
lldb/test/Shell/Register/x86-zmm-read.test
lldb/test/Shell/Register/x86-zmm-write.test
lldb/test/Shell/Reproducer/Functionalities/TestDataFormatter.test
lldb/test/Shell/Reproducer/Functionalities/TestImageList.test
lldb/test/Shell/Reproducer/Functionalities/TestStepping.test
lldb/test/Shell/Reproducer/Modules/TestModuleCXX.test
lldb/test/Shell/Reproducer/TestDump.test
lldb/test/Shell/Reproducer/TestFileRepro.test
lldb/test/Shell/Reproducer/TestGDBRemoteRepro.test
lldb/test/Shell/Reproducer/TestRelativePath.test
lldb/test/Shell/Reproducer/TestReuseDirectory.test
lldb/test/Shell/Reproducer/TestWorkingDir.test
lldb/test/Shell/Settings/TestFrameFormatColor.test
lldb/test/Shell/Settings/TestFrameFormatNoColor.test
lldb/test/Shell/SymbolFile/DWARF/anon_class_w_and_wo_export_symbols.ll

lldb/test/Shell/SymbolFile/DWARF/clang-ast-from-dwarf-unamed-and-anon-structs.cpp
lldb/test/Shell/SymbolFile/DWARF/debug-types-expressions.test
lldb/test/Shell/SymbolFile/DWARF/deterministic-build.cpp
lldb/test/Shell/SymbolFile/PDB/function-level-linking.test
lldb/test/Shell/SymbolFile/target-symbols-add-unwind.test
lldb/test/Shell/Unwind/eh-frame-dwarf-unwind.test
lldb/test/Shell/Unwind/eh

[Lldb-commits] [PATCH] D69031: [LLDB] [test] Use %clang_cl instead of build.py in a few tests

[Martin Storsjö via Phabricator via lldb-commits]

mstorsjo added a comment.

In D69031#1728380 , @labath wrote:

> Ok, https://reviews.llvm.org/D69619 should resolve the issues you 
> encountered, but I'd recommend waiting a while before building on top of 
> that, because it has the potential to cause problems for some configurations. 
> Also stella's bot is still down due to the github stuff, so we won't get 
> windows signal here (though I guess we've already established that this patch 
> works on windows in the previous attempt).


Great, thanks! I'll hold off for a bit to let the dust settle, and then try 
pushing this one e.g. tomorrow.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69031



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

[Lldb-commits] [PATCH] D69031: [LLDB] [test] Use %clang_cl instead of build.py in a few tests

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

Ok, https://reviews.llvm.org/D69619 should resolve the issues you encountered, 
but I'd recommend waiting a while before building on top of that, because it 
has the potential to cause problems for some configurations. Also stella's bot 
is still down due to the github stuff, so we won't get windows signal here 
(though I guess we've already established that this patch works on windows in 
the previous attempt).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69031



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

[Lldb-commits] [PATCH] D69619: [lldb/lit] Introduce %clang_host substitutions

[Pavel Labath via Phabricator via lldb-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG9c739252261e: [lldb/lit] Introduce %clang_host substitutions 
(authored by labath).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69619

Files:
  lldb/test/Shell/Commands/command-script-import.test
  lldb/test/Shell/Driver/TestSingleQuote.test
  lldb/test/Shell/Driver/TestTarget.test
  lldb/test/Shell/ExecControl/StopHook/stop-hook-threads.test
  lldb/test/Shell/ExecControl/StopHook/stop-hook.test
  lldb/test/Shell/Expr/TestIRMemoryMap.test
  lldb/test/Shell/Expr/TestIRMemoryMapWindows.test
  lldb/test/Shell/Heap/heap-cstr.test
  lldb/test/Shell/Host/TestCustomShell.test
  lldb/test/Shell/ObjectFile/ELF/minidebuginfo-set-and-hit-breakpoint.test
  lldb/test/Shell/Process/TestEnvironment.test
  lldb/test/Shell/Register/aarch64-fp-read.test
  lldb/test/Shell/Register/aarch64-gp-read.test
  lldb/test/Shell/Register/arm-fp-read.test
  lldb/test/Shell/Register/arm-gp-read.test
  lldb/test/Shell/Register/x86-64-gp-read.test
  lldb/test/Shell/Register/x86-64-gp-write.test
  lldb/test/Shell/Register/x86-64-read.test
  lldb/test/Shell/Register/x86-64-write.test
  lldb/test/Shell/Register/x86-64-xmm16-read.test
  lldb/test/Shell/Register/x86-64-xmm16-write.test
  lldb/test/Shell/Register/x86-64-ymm-read.test
  lldb/test/Shell/Register/x86-64-ymm-write.test
  lldb/test/Shell/Register/x86-64-ymm16-read.test
  lldb/test/Shell/Register/x86-64-ymm16-write.test
  lldb/test/Shell/Register/x86-64-zmm-read.test
  lldb/test/Shell/Register/x86-64-zmm-write.test
  lldb/test/Shell/Register/x86-gp-read.test
  lldb/test/Shell/Register/x86-gp-write.test
  lldb/test/Shell/Register/x86-mm-xmm-read.test
  lldb/test/Shell/Register/x86-mm-xmm-write.test
  lldb/test/Shell/Register/x86-ymm-read.test
  lldb/test/Shell/Register/x86-ymm-write.test
  lldb/test/Shell/Register/x86-zmm-read.test
  lldb/test/Shell/Register/x86-zmm-write.test
  lldb/test/Shell/Reproducer/Functionalities/TestDataFormatter.test
  lldb/test/Shell/Reproducer/Functionalities/TestImageList.test
  lldb/test/Shell/Reproducer/Functionalities/TestStepping.test
  lldb/test/Shell/Reproducer/Modules/TestModuleCXX.test
  lldb/test/Shell/Reproducer/TestDump.test
  lldb/test/Shell/Reproducer/TestFileRepro.test
  lldb/test/Shell/Reproducer/TestGDBRemoteRepro.test
  lldb/test/Shell/Reproducer/TestRelativePath.test
  lldb/test/Shell/Reproducer/TestReuseDirectory.test
  lldb/test/Shell/Reproducer/TestWorkingDir.test
  lldb/test/Shell/Settings/TestFrameFormatColor.test
  lldb/test/Shell/Settings/TestFrameFormatNoColor.test
  lldb/test/Shell/SymbolFile/DWARF/anon_class_w_and_wo_export_symbols.ll
  
lldb/test/Shell/SymbolFile/DWARF/clang-ast-from-dwarf-unamed-and-anon-structs.cpp
  lldb/test/Shell/SymbolFile/DWARF/debug-types-expressions.test
  lldb/test/Shell/SymbolFile/DWARF/deterministic-build.cpp
  lldb/test/Shell/SymbolFile/PDB/function-level-linking.test
  lldb/test/Shell/SymbolFile/target-symbols-add-unwind.test
  lldb/test/Shell/Unwind/eh-frame-dwarf-unwind.test
  lldb/test/Shell/Unwind/eh-frame-small-fde.test
  lldb/test/Shell/Unwind/prefer-debug-over-eh-frame.test
  lldb/test/Shell/Unwind/trap_frame_sym_ctx.test
  lldb/test/Shell/Unwind/unwind-plan-dwarf-dump.test
  lldb/test/Shell/Watchpoint/SetErrorCases.test
  lldb/test/Shell/helper/toolchain.py

Index: lldb/test/Shell/helper/toolchain.py
===
--- lldb/test/Shell/helper/toolchain.py
+++ lldb/test/Shell/helper/toolchain.py
@@ -85,7 +85,7 @@
 # Set up substitutions for support tools.  These tools can be overridden at the CMake
 # level (by specifying -DLLDB_LIT_TOOLS_DIR), installed, or as a last resort, we can use
 # the just-built version.
-flags = []
+host_flags = ['--target=' + config.host_triple]
 if platform.system() in ['Darwin']:
 try:
 out = subprocess.check_output(['xcrun', '--show-sdk-path']).strip()
@@ -95,26 +95,32 @@
 if res == 0 and out:
 sdk_path = lit.util.to_string(out)
 llvm_config.lit_config.note('using SDKROOT: %r' % sdk_path)
-flags = ['-isysroot', sdk_path]
+host_flags += ['-isysroot', sdk_path]
 elif platform.system() in ['NetBSD', 'OpenBSD', 'Linux']:
-flags = ['-pthread']
+host_flags += ['-pthread']
 
 if sys.platform.startswith('netbsd'):
 # needed e.g. to use freshly built libc++
-flags += ['-L' + config.llvm_libs_dir,
+host_flags += ['-L' + config.llvm_libs_dir,
   '-Wl,-rpath,' + config.llvm_libs_dir]
 
 # The clang module cache is used for building inferiors.
-flags += ['-fmodules-cache-path={}'.format(config.clang_module_cache)]
+host_flags += ['-fmodules-cache-path={}'.format(config.clang_module_cache)]
+
+host_flags = ' '.join(host_flags)
+config.substitutions.append(('%clang

[Lldb-commits] [lldb] e46c664 - [lldb] Fix offset intersection bug between MPX and AVX registers

[Pavel Labath via lldb-commits]

Author: Guilherme Andrade
Date: 2019-10-31T10:58:17+01:00
New Revision: e46c6644db8432584e82ef7ddfc9d0f36543f205

URL: 
https://github.com/llvm/llvm-project/commit/e46c6644db8432584e82ef7ddfc9d0f36543f205
DIFF: 
https://github.com/llvm/llvm-project/commit/e46c6644db8432584e82ef7ddfc9d0f36543f205.diff

LOG: [lldb] Fix offset intersection bug between MPX and AVX registers

Summary:
This change increases the offset of MPX registers (by 128) so they
do not overlap with the offset associated with AVX registers. That was
causing MPX data in GDBRemoteRegisterContext::m_reg_data to get overwritten.

Reviewers: labath

Reviewed By: labath

Subscribers: JDevlieghere, lldb-commits

Tags: #lldb

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

Added: 

lldb/packages/Python/lldbsuite/test/commands/register/register/intel_xtended_registers/mpx_offset_intersection/Makefile

lldb/packages/Python/lldbsuite/test/commands/register/register/intel_xtended_registers/mpx_offset_intersection/TestMPXOffsetIntersection.py

lldb/packages/Python/lldbsuite/test/commands/register/register/intel_xtended_registers/mpx_offset_intersection/main.cpp

Modified: 
lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux.cpp
lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux.h
lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_x86_64.cpp
lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_x86_64.h
lldb/source/Plugins/Process/Utility/RegisterInfos_x86_64.h

Removed: 




diff  --git 
a/lldb/packages/Python/lldbsuite/test/commands/register/register/intel_xtended_registers/mpx_offset_intersection/Makefile
 
b/lldb/packages/Python/lldbsuite/test/commands/register/register/intel_xtended_registers/mpx_offset_intersection/Makefile
new file mode 100644
index ..8b20bcb0
--- /dev/null
+++ 
b/lldb/packages/Python/lldbsuite/test/commands/register/register/intel_xtended_registers/mpx_offset_intersection/Makefile
@@ -0,0 +1,3 @@
+CXX_SOURCES := main.cpp
+
+include Makefile.rules

diff  --git 
a/lldb/packages/Python/lldbsuite/test/commands/register/register/intel_xtended_registers/mpx_offset_intersection/TestMPXOffsetIntersection.py
 
b/lldb/packages/Python/lldbsuite/test/commands/register/register/intel_xtended_registers/mpx_offset_intersection/TestMPXOffsetIntersection.py
new file mode 100644
index ..cca163576684
--- /dev/null
+++ 
b/lldb/packages/Python/lldbsuite/test/commands/register/register/intel_xtended_registers/mpx_offset_intersection/TestMPXOffsetIntersection.py
@@ -0,0 +1,73 @@
+"""
+Test Intel(R) MPX registers do not get overwritten by AVX data.
+"""
+
+from __future__ import print_function
+
+
+import lldb
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+
+
+class MPXOffsetIntersectionTestCase(TestBase):
+
+mydir = TestBase.compute_mydir(__file__)
+
+AVX_REGS = ('ymm' + str(i) for i in range(16))
+YMM_VALUE = '{' + ' '.join(('0x00' for _ in range(32))) + '}'
+
+MPX_REGULAR_REGS = ('bnd0', 'bnd1', 'bnd2', 'bnd3')
+MPX_CONFIG_REGS = ('bndcfgu', 'bndstatus')
+BND_VALUE = '{' + ' '.join(('0xff' for _ in range(16))) + '}'
+
+def setUp(self):
+TestBase.setUp(self)
+
+@skipIf(oslist=no_match(['linux']))
+@skipIf(archs=no_match(['x86_64']))
+def test_mpx_registers_offset_intersection(self):
+"""Test if AVX data does not overwrite MPX values."""
+self.build()
+self.mpx_registers_offset_intersection()
+
+def mpx_registers_offset_intersection(self):
+exe = self.getBuildArtifact('a.out')
+self.runCmd('file ' + exe, CURRENT_EXECUTABLE_SET)
+self.runCmd('run', RUN_SUCCEEDED)
+target = self.dbg.GetSelectedTarget()
+process = target.GetProcess()
+thread = process.GetThreadAtIndex(0)
+currentFrame = thread.GetFrameAtIndex(0)
+
+has_avx = False
+has_mpx = False
+for registerSet in currentFrame.GetRegisters():
+if 'advanced vector extensions' in registerSet.GetName().lower():
+has_avx = True
+if 'memory protection extension' in registerSet.GetName().lower():
+has_mpx = True
+if not (has_avx and has_mpx):
+self.skipTest('Both AVX and MPX registers must be supported.')
+
+for reg in self.AVX_REGS:
+self.runCmd('register write ' + reg + " '" + self.YMM_VALUE + " '")
+for reg in self.MPX_REGULAR_REGS + self.MPX_CONFIG_REGS:
+self.runCmd('register write ' + reg + " '" + self.BND_VALUE + " '")
+
+self.verify_mpx()
+self.verify_avx()
+self.verify_mpx()
+
+def verify_mpx(self):
+for reg in self.MPX_REGULAR_REGS:
+self.expect('register read ' + reg,
+substrs = [reg + ' = {0x

[Lldb-commits] [PATCH] D68874: [lldb] Fix offset intersection bug between MPX and AVX registers

[Pavel Labath via Phabricator via lldb-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGe46c6644db84: [lldb] Fix offset intersection bug between MPX 
and AVX registers (authored by guiandrade, committed by labath).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D68874

Files:
  
lldb/packages/Python/lldbsuite/test/commands/register/register/intel_xtended_registers/mpx_offset_intersection/Makefile
  
lldb/packages/Python/lldbsuite/test/commands/register/register/intel_xtended_registers/mpx_offset_intersection/TestMPXOffsetIntersection.py
  
lldb/packages/Python/lldbsuite/test/commands/register/register/intel_xtended_registers/mpx_offset_intersection/main.cpp
  lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux.cpp
  lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux.h
  lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_x86_64.cpp
  lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_x86_64.h
  lldb/source/Plugins/Process/Utility/RegisterInfos_x86_64.h

Index: lldb/source/Plugins/Process/Utility/RegisterInfos_x86_64.h
===
--- lldb/source/Plugins/Process/Utility/RegisterInfos_x86_64.h
+++ lldb/source/Plugins/Process/Utility/RegisterInfos_x86_64.h
@@ -25,15 +25,18 @@
LLVM_EXTENSION offsetof(FPR, xsave) +   \
LLVM_EXTENSION offsetof(XSAVE, ymmh[0]) + (32 * reg_index))
 
+// Guarantees BNDR/BNDC offsets do not overlap with YMM offsets.
+#define GDB_REMOTE_OFFSET 128
+
 #define BNDR_OFFSET(reg_index) \
   (LLVM_EXTENSION offsetof(UserArea, fpr) +\
LLVM_EXTENSION offsetof(FPR, xsave) +   \
-   LLVM_EXTENSION offsetof(XSAVE, mpxr[reg_index]))
+   LLVM_EXTENSION offsetof(XSAVE, mpxr[reg_index]) + GDB_REMOTE_OFFSET)
 
 #define BNDC_OFFSET(reg_index) \
   (LLVM_EXTENSION offsetof(UserArea, fpr) +\
LLVM_EXTENSION offsetof(FPR, xsave) +   \
-   LLVM_EXTENSION offsetof(XSAVE, mpxc[reg_index]))
+   LLVM_EXTENSION offsetof(XSAVE, mpxc[reg_index]) + GDB_REMOTE_OFFSET)
 
 #ifdef DECLARE_REGISTER_INFOS_X86_64_STRUCT
 
Index: lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_x86_64.h
===
--- lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_x86_64.h
+++ lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_x86_64.h
@@ -75,6 +75,8 @@
 
   Status WriteFPR() override;
 
+  uint32_t GetPtraceOffset(uint32_t reg_index) override;
+
 private:
   // Private member types.
   enum class XStateType { Invalid, FXSAVE, XSAVE };
Index: lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_x86_64.cpp
===
--- lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_x86_64.cpp
+++ lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_x86_64.cpp
@@ -1213,4 +1213,11 @@
   return 4;
 }
 
+uint32_t
+NativeRegisterContextLinux_x86_64::GetPtraceOffset(uint32_t reg_index) {
+  // If register is MPX, remove extra factor from gdb offset
+  return GetRegisterInfoAtIndex(reg_index)->byte_offset -
+ (IsMPX(reg_index) ? 128 : 0);
+}
+
 #endif // defined(__i386__) || defined(__x86_64__)
Index: lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux.h
===
--- lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux.h
+++ lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux.h
@@ -60,6 +60,10 @@
 
   virtual size_t GetFPRSize() = 0;
 
+  virtual uint32_t GetPtraceOffset(uint32_t reg_index) {
+return GetRegisterInfoAtIndex(reg_index)->byte_offset;
+  }
+
   // The Do*** functions are executed on the privileged thread and can perform
   // ptrace
   // operations directly.
Index: lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux.cpp
===
--- lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux.cpp
+++ lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux.cpp
@@ -34,7 +34,7 @@
   if (!reg_info)
 return Status("register %" PRIu32 " not found", reg_index);
 
-  return DoReadRegisterValue(reg_info->byte_offset, reg_info->name,
+  return DoReadRegisterValue(GetPtraceOffset(reg_index), reg_info->name,
  reg_info->byte_size, reg_value);
 }
 
@@ -91,7 +91,8 @@
   "for write register index %" PRIu32,
   __FUNCTION__, reg_to_write);
 
-  return DoWriteRegisterValue(reg_info->byte_offset, reg_info->name, reg_value);
+  return DoWriteRegisterValue(GetPtraceOffset(reg_index), reg_info->

[Lldb-commits] [PATCH] D69612: [lldb-vscod] fix build with NDEBUG on windows

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

In D69612#1726968 , @labath wrote:

> Yes, I used "arc patch". I did check that it preserved the authorship 
> information, but I did not go into the details of what's in the author field 
> TBH. I agree it would be better to have the full name there, but I don't know 
> if there's a way to change that (short of people doing "git commit --amend 
> --author=XXX" manually, which everyone is going to forget).


BTW, I've just done another "arc patch" and the author information came out 
right this time. So it looks like arc is able to fetch/set the git author 
correctly at least in some cases.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69612



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

[Lldb-commits] [lldb] 193a7bf - minidump: Create memory regions from the sections of loaded modules

[Pavel Labath via lldb-commits]

Author: Pavel Labath
Date: 2019-10-31T11:24:55+01:00
New Revision: 193a7bfb697b5d2adb1c3d37a9d624aa8131ec35

URL: 
https://github.com/llvm/llvm-project/commit/193a7bfb697b5d2adb1c3d37a9d624aa8131ec35
DIFF: 
https://github.com/llvm/llvm-project/commit/193a7bfb697b5d2adb1c3d37a9d624aa8131ec35.diff

LOG: minidump: Create memory regions from the sections of loaded modules

Summary:
Not all minidumps contain information about memory permissions. However,
it is still important to know which regions of memory contain
potentially executable code. This is particularly important for
unwinding on win32, as the default unwind method there relies on
scanning the stack for things which "look like" code pointers.

This patch enables ProcessMinidump to reconstruct the likely permissions
of memory regions using the sections of loaded object files. It only
does this if we don't have a better source (memory info list stream, or
linux /proc/maps) for this information, and only if the information in
the object files does not conflict with the information in the minidump.

Theoretically that last bit could be improved, since the permissions
obtained from the MemoryList streams is also only a very rough guess,
but it did not seem worthwhile to complicate the implementation because
of that because there will generally be no overlap in practice as the
MemoryList will contain the stack contents and not any module data.

The patch adds a test checking that the module section permissions are
entered into the memory region list, and also a test which demonstrate
that now the unwinder is able to correctly find return addresses even in
minidumps without memory info list streams.

There's one TODO left in this patch, which is that the "memory region"
output does not give any indication about the "don't know" values of
memory region permissions (it just prints them as if they permission bit
was set). I address this in a follow up.

Reviewers: amccarth, clayborg

Subscribers: mgrang, lldb-commits

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

Added: 
lldb/test/Shell/Minidump/Inputs/basic-elf.yaml
lldb/test/Shell/Minidump/memory-region-from-module.yaml
lldb/test/Shell/SymbolFile/Breakpad/unwind-via-stack-win-no-memory-info.yaml

Modified: 
lldb/source/Plugins/Process/minidump/ProcessMinidump.cpp

Removed: 




diff  --git a/lldb/source/Plugins/Process/minidump/ProcessMinidump.cpp 
b/lldb/source/Plugins/Process/minidump/ProcessMinidump.cpp
index 5dc34d91..5c090dc6e12f 100644
--- a/lldb/source/Plugins/Process/minidump/ProcessMinidump.cpp
+++ b/lldb/source/Plugins/Process/minidump/ProcessMinidump.cpp
@@ -334,32 +334,21 @@ ArchSpec ProcessMinidump::GetArchitecture() {
   return ArchSpec(triple);
 }
 
-void ProcessMinidump::BuildMemoryRegions() {
-  if (m_memory_regions)
-return;
-  m_memory_regions.emplace();
-  bool is_complete;
-  std::tie(*m_memory_regions, is_complete) =
-  m_minidump_parser->BuildMemoryRegions();
-  // TODO: Use loaded modules to complete the region list.
-}
-
-Status ProcessMinidump::GetMemoryRegionInfo(lldb::addr_t load_addr,
-MemoryRegionInfo ®ion) {
-  BuildMemoryRegions();
-  auto pos = llvm::upper_bound(*m_memory_regions, load_addr);
-  if (pos != m_memory_regions->begin() &&
+static MemoryRegionInfo GetMemoryRegionInfo(const MemoryRegionInfos ®ions,
+lldb::addr_t load_addr) {
+  MemoryRegionInfo region;
+  auto pos = llvm::upper_bound(regions, load_addr);
+  if (pos != regions.begin() &&
   std::prev(pos)->GetRange().Contains(load_addr)) {
-region = *std::prev(pos);
-return Status();
+return *std::prev(pos);
   }
 
-  if (pos == m_memory_regions->begin())
+  if (pos == regions.begin())
 region.GetRange().SetRangeBase(0);
   else
 region.GetRange().SetRangeBase(std::prev(pos)->GetRange().GetRangeEnd());
 
-  if (pos == m_memory_regions->end())
+  if (pos == regions.end())
 region.GetRange().SetRangeEnd(UINT64_MAX);
   else
 region.GetRange().SetRangeEnd(pos->GetRange().GetRangeBase());
@@ -368,6 +357,55 @@ Status ProcessMinidump::GetMemoryRegionInfo(lldb::addr_t 
load_addr,
   region.SetWritable(MemoryRegionInfo::eNo);
   region.SetExecutable(MemoryRegionInfo::eNo);
   region.SetMapped(MemoryRegionInfo::eNo);
+  return region;
+}
+
+void ProcessMinidump::BuildMemoryRegions() {
+  if (m_memory_regions)
+return;
+  m_memory_regions.emplace();
+  bool is_complete;
+  std::tie(*m_memory_regions, is_complete) =
+  m_minidump_parser->BuildMemoryRegions();
+
+  if (is_complete)
+return;
+
+  MemoryRegionInfos to_add;
+  ModuleList &modules = GetTarget().GetImages();
+  SectionLoadList &load_list = GetTarget().GetSectionLoadList();
+  modules.ForEach([&](const ModuleSP &module_sp) {
+SectionList *sections = module_sp->GetSectionList();
+for (size_t i = 0; i < section

[Lldb-commits] [PATCH] D69555: [zorg] Fix LLDBCmakeBuildFactory

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

In D69555#1728291 , @labath wrote:

> (which actually surprises me a lot)


Actually, nevermind. The linux bot fails now in the same way as the windows one 
(http://lab.llvm.org:8014/builders/lldb-x86_64-debian/builds/6262). Galina, 
will you remove the extra quotes, or should I?


Repository:
  rZORG LLVM Github Zorg

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

https://reviews.llvm.org/D69555



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

[Lldb-commits] [PATCH] D69105: minidump: Create memory regions from the sections of loaded modules

[Pavel Labath via Phabricator via lldb-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG193a7bfb697b: minidump: Create memory regions from the 
sections of loaded modules (authored by labath).
Herald added a project: LLDB.

Changed prior to commit:
  https://reviews.llvm.org/D69105?vs=225409&id=227257#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69105

Files:
  lldb/source/Plugins/Process/minidump/ProcessMinidump.cpp
  lldb/test/Shell/Minidump/Inputs/basic-elf.yaml
  lldb/test/Shell/Minidump/memory-region-from-module.yaml
  lldb/test/Shell/SymbolFile/Breakpad/unwind-via-stack-win-no-memory-info.yaml

Index: lldb/test/Shell/SymbolFile/Breakpad/unwind-via-stack-win-no-memory-info.yaml
===
--- /dev/null
+++ lldb/test/Shell/SymbolFile/Breakpad/unwind-via-stack-win-no-memory-info.yaml
@@ -0,0 +1,133 @@
+# RUN: yaml2obj --docnum=1 %s > %t.dmp
+# RUN: yaml2obj --docnum=2 %s > %t.exe
+# RUN: %lldb -c %t.dmp %t.exe \
+# RUN:   -o "target symbols add %S/Inputs/unwind-via-raSearch.syms" \
+# RUN:   -o "thread backtrace" -b | FileCheck %s
+
+# CHECK-LABEL: thread backtrace
+# CHECK: frame #0: 0x000b1092 unwind-via-stack-win.exe`many_pointer_args
+# CHECK: frame #1: 0x000b1079 unwind-via-stack-win.exe`call_many + 105
+# CHECK: frame #2: 0x000b1085 unwind-via-stack-win.exe`main + 5
+# CHECK: frame #3: 0x77278494 kernel32.dll
+# CHECK-NOT: frame
+
+--- !minidump
+Streams:
+  - Type:ThreadList
+Threads:
+  - Thread Id:   0x290C
+Priority Class:  0x0020
+Environment Block: 0x00A98000
+Context: 3F0001007F022B0053002B002B0080100B0080100B50A90080100B0080100B00E4FECF0092100B002300440301007CFECF002B007F02801F0200144E3D6C2100EA1E00F4C000E507FC012CE3C014D8E20201E507880F401D839DC60140007F00880F401D0A00900F401D0100EA1E9808E5077F009008E50799016002E5072CABC87708346474B423010044E3C014200020532777A80F401D4F346474D00F401D6F378CCC5C4CD5013AFCD72F90E3C01418CE3470B423B80F401DC00F401DC80F401DD00F401D
+Stack:
+  Start of Memory Range: 0x00CFFE78
+  Content: 79100B100B100B100B100B100B100B100B100B100B100B100B100B100B100B100B100B100B100B100B100B0085100B0094842777
+  - Type:ModuleList
+Modules:
+  - Base of Image:   0x000B1000
+Size of Image:   0x4000
+Module Name: 'unwind-via-stack-win.exe'
+CodeView Record: 525344533ED87D89C8A8184197F3A925EE4BF7410100433A5C70726F6A656374735C746573745F6170705C436F6E736F6C654170706C69636174696F6E315C44656275675C436F6E736F6C654170706C69636174696F6E312E70646200
+  - Base of Image:   0x7726
+Size of Image:   0x000E
+Module Name: 'C:\Windows\System32\kernel32.dll'
+CodeView Record: 5253445300F90A57CF8DED8A463A90390318CD440100776B65726E656C33322E
+  - Type:MemoryList
+Memory Ranges:
+  - Start of Memory Range: 0x00CFFE78
+Content: 79100B100B100B100B100B100B100B100B100B100B100B100B100B100B100B100B100B100B100B100B100B0085100B0094842777
+  - Type:SystemInfo
+Processor Arch:  X86
+Platform ID: Win32NT
+CPU:
+  Vendor ID:   AuthenticAMD
+  Version Info:0x00800F82
+  Feature Info:0x178BFBFF
+  - Type:MiscInfo
+Content: 5405F7030829C883495DAC0D9808AC0D020002200D000200C4FF430065006E007400720061006C0020004500750072006F007000650020005300740061006E0064006100720064002000540069006D0065000A0005000300430065006E007400720

[Lldb-commits] [PATCH] D68270: DWARFDebugLoc: Add a function to get the address range of an entry

[Jonas Devlieghere via Phabricator via lldb-commits]

JDevlieghere added inline comments.



Comment at: include/llvm/DebugInfo/DWARF/DWARFDebugLoc.h:138
+llvm::Optional BaseAddr;
+std::function(uint32_t)>
+AddrOffsetResolver;

labath wrote:
> Using a callback is consistent with what rnglists code does. This uses a 
> std::function instead of a function_ref because it's easier for iterators to 
> escape out of scopes. However, I've wondered if we shouldn't define an 
> AddrOffsetResolver interface that llvm, lldb DWARFUnits and anyone else who 
> wishes so (unit tests ?) can implement.
I like the idea, +1 from me.



Comment at: include/llvm/DebugInfo/DWARF/DWARFDebugLoc.h:147
   unsigned AddressSize, const MCRegisterInfo *RegInfo,
+  DIDumpOptions DumpOpts,
+  function_ref(uint32_t)>

Most dump methods give a default argument for DIDumpOptions (`DumpOpts = {}`). 
Should we do the same here?



Comment at: lib/BinaryFormat/Dwarf.cpp:479
+return StringRef();
+  case DW_LLE_end_of_list:
+return "DW_LLE_end_of_list";

Maybe this should go in in `DWARF.h`?



Comment at: lib/DebugInfo/DWARF/DWARFDebugLoc.cpp:291-295
+  EntryIterator Absolute =
+  getAbsoluteLocations(
+  SectionedAddress{BaseAddr, SectionedAddress::UndefSection},
+  LookupPooledAddress)
+  .begin();

labath wrote:
> dblaikie wrote:
> > labath wrote:
> > > dblaikie wrote:
> > > > labath wrote:
> > > > > dblaikie wrote:
> > > > > > labath wrote:
> > > > > > > dblaikie wrote:
> > > > > > > > labath wrote:
> > > > > > > > > This parallel iteration is not completely nice, but I think 
> > > > > > > > > it's worth being able to reuse the absolute range computation 
> > > > > > > > > code. I'm open to ideas for improvement though.
> > > > > > > > Ah, I see - this is what you meant about "In particular it 
> > > > > > > > makes it possible to reuse this stuff in the dumping code, 
> > > > > > > > which would have been pretty hard with callbacks.".
> > > > > > > > 
> > > > > > > > I'm wondering if that might be worth revisiting somewhat. A 
> > > > > > > > full iterator abstraction for one user here (well, two once you 
> > > > > > > > include lldb - but I assume it's likely going to build its own 
> > > > > > > > data structure from the iteration anyway, right? (it's not 
> > > > > > > > going to keep the iterator around, do anything interesting like 
> > > > > > > > partial iterations, re-iterate/etc - such that a callback would 
> > > > > > > > suffice))
> > > > > > > > 
> > > > > > > > I could imagine two callback APIs for this - one that gets 
> > > > > > > > entries and locations and one that only gets locations by 
> > > > > > > > filtering on the entry version.
> > > > > > > > 
> > > > > > > > eg:
> > > > > > > > 
> > > > > > > >   // for non-verbose output:
> > > > > > > >   LL.forEachEntry([&](const Entry &E, Expected 
> > > > > > > > L) {
> > > > > > > > if (Verbose && actually dumping debug_loc)
> > > > > > > >   print(E) // print any LLE_*, raw parameters, etc
> > > > > > > > if (L)
> > > > > > > >   print(*L) // print the resulting address range, section 
> > > > > > > > name (if verbose), 
> > > > > > > > else
> > > > > > > >   print(error stuff)
> > > > > > > >   });
> > > > > > > > 
> > > > > > > > One question would be "when/where do we print the DWARF 
> > > > > > > > expression" - if there's an error computing the address range, 
> > > > > > > > we can still print the expression, so maybe that happens 
> > > > > > > > unconditionally at the end of the callback, using the 
> > > > > > > > expression in the Entry? (then, arguably, the expression 
> > > > > > > > doesn't need to be in the DWARFLocation - and I'd say make the 
> > > > > > > > DWARFLocation a sectioned range, exactly the same type as for 
> > > > > > > > ranges so that part of the dumping code, etc, can be maximally 
> > > > > > > > reused)
> > > > > > > Actually, what lldb currently does is that it does not build any 
> > > > > > > data structures at all (except storing the pointer to the right 
> > > > > > > place in the debug_loc section. Then, whenever it wants to do 
> > > > > > > something to the loclist, it parses it afresh. I don't know why 
> > > > > > > it does this exactly, but I assume it has something to do with 
> > > > > > > most locations never being used, or being only a couple of times, 
> > > > > > > and the actual parsing being fairly fast. What this means is that 
> > > > > > > lldb is not really a single "user", but there are like four or 
> > > > > > > five places where it iterates through the list, depending on what 
> > > > > > > does it actually want to do with it. It also does partial 
> > > > > > > iteration where it stops as soon as it find the entry it was 
> > > > > > > interested in.
> > > > > > > Now, all of that is possible with a callback (though I am 
>

[Lldb-commits] [PATCH] D69667: [lldb] [Process/NetBSD] Add register info for missing register sets

[Michał Górny via Phabricator via lldb-commits]

mgorny created this revision.
mgorny added reviewers: labath, krytarowski, JDevlieghere.

Add info for all register sets supported in NetBSD, particularly for all
registers 'expected' by LLDB.  This is necessary in order to fix
python_api/lldbutil/iter/TestRegistersIterator.py test that currently
fails due to missing names of register sets (None).

This copies fpreg descriptions from Linux, and combines Linux' AVX
and MPX registers into a single XState group, to fit NetBSD register
group design.  Technically, we do not support MPX registers
at the moment but gdb-remote insists on passing their errors anyway,
and if we do not include it in any group, they end up in a separate
anonymous group that breaks the test.

While at it, swap the enums for XState and DBRegs to match register set
ordering.

This also adds a few consts to the lldb-x86-register-enums.h to provide
more consistency between user registers and debug registers.


https://reviews.llvm.org/D69667

Files:
  lldb/source/Plugins/Process/NetBSD/NativeRegisterContextNetBSD_x86_64.cpp
  lldb/source/Plugins/Process/NetBSD/NativeRegisterContextNetBSD_x86_64.h
  lldb/source/Plugins/Process/Utility/lldb-x86-register-enums.h

Index: lldb/source/Plugins/Process/Utility/lldb-x86-register-enums.h
===
--- lldb/source/Plugins/Process/Utility/lldb-x86-register-enums.h
+++ lldb/source/Plugins/Process/Utility/lldb-x86-register-enums.h
@@ -294,7 +294,8 @@
   lldb_bndstatus_x86_64,
   k_last_mpxc_x86_64 = lldb_bndstatus_x86_64,
 
-  lldb_dr0_x86_64,
+  k_first_dbr_x86_64,
+  lldb_dr0_x86_64 = k_first_dbr_x86_64,
   lldb_dr1_x86_64,
   lldb_dr2_x86_64,
   lldb_dr3_x86_64,
@@ -302,6 +303,7 @@
   lldb_dr5_x86_64,
   lldb_dr6_x86_64,
   lldb_dr7_x86_64,
+  k_last_dbr_x86_64 = lldb_dr7_x86_64,
 
   k_num_registers_x86_64,
   k_num_gpr_registers_x86_64 = k_last_gpr_x86_64 - k_first_gpr_x86_64 + 1,
@@ -312,6 +314,7 @@
 k_num_fpr_registers_x86_64 +
 k_num_avx_registers_x86_64 +
 k_num_mpx_registers_x86_64,
+  k_num_dbr_registers_x86_64 = k_last_dbr_x86_64 - k_first_dbr_x86_64 + 1,
 };
 }
 
Index: lldb/source/Plugins/Process/NetBSD/NativeRegisterContextNetBSD_x86_64.h
===
--- lldb/source/Plugins/Process/NetBSD/NativeRegisterContextNetBSD_x86_64.h
+++ lldb/source/Plugins/Process/NetBSD/NativeRegisterContextNetBSD_x86_64.h
@@ -73,7 +73,7 @@
 
 private:
   // Private member types.
-  enum { GPRegSet, FPRegSet, DBRegSet, XStateRegSet };
+  enum { GPRegSet, FPRegSet, XStateRegSet, DBRegSet };
 
   // Private member variables.
   struct reg m_gpr_x86_64;
Index: lldb/source/Plugins/Process/NetBSD/NativeRegisterContextNetBSD_x86_64.cpp
===
--- lldb/source/Plugins/Process/NetBSD/NativeRegisterContextNetBSD_x86_64.cpp
+++ lldb/source/Plugins/Process/NetBSD/NativeRegisterContextNetBSD_x86_64.cpp
@@ -84,13 +84,71 @@
   k_num_gpr_registers_x86_64,
   "g_gpr_regnums_x86_64 has wrong number of register infos");
 
+// x86 64-bit floating point registers.
+static const uint32_t g_fpu_regnums_x86_64[] = {
+lldb_fctrl_x86_64, lldb_fstat_x86_64, lldb_ftag_x86_64,
+lldb_fop_x86_64,   lldb_fiseg_x86_64, lldb_fioff_x86_64,
+lldb_foseg_x86_64, lldb_fooff_x86_64, lldb_mxcsr_x86_64,
+lldb_mxcsrmask_x86_64, lldb_st0_x86_64,   lldb_st1_x86_64,
+lldb_st2_x86_64,   lldb_st3_x86_64,   lldb_st4_x86_64,
+lldb_st5_x86_64,   lldb_st6_x86_64,   lldb_st7_x86_64,
+lldb_mm0_x86_64,   lldb_mm1_x86_64,   lldb_mm2_x86_64,
+lldb_mm3_x86_64,   lldb_mm4_x86_64,   lldb_mm5_x86_64,
+lldb_mm6_x86_64,   lldb_mm7_x86_64,   lldb_xmm0_x86_64,
+lldb_xmm1_x86_64,  lldb_xmm2_x86_64,  lldb_xmm3_x86_64,
+lldb_xmm4_x86_64,  lldb_xmm5_x86_64,  lldb_xmm6_x86_64,
+lldb_xmm7_x86_64,  lldb_xmm8_x86_64,  lldb_xmm9_x86_64,
+lldb_xmm10_x86_64, lldb_xmm11_x86_64, lldb_xmm12_x86_64,
+lldb_xmm13_x86_64, lldb_xmm14_x86_64, lldb_xmm15_x86_64,
+LLDB_INVALID_REGNUM // register sets need to end with this flag
+};
+static_assert((sizeof(g_fpu_regnums_x86_64) / sizeof(g_fpu_regnums_x86_64[0])) -
+  1 ==
+  k_num_fpr_registers_x86_64,
+  "g_fpu_regnums_x86_64 has wrong number of register infos");
+
+// x86 64-bit registers available via XState.
+static const uint32_t g_xstate_regnums_x86_64[] = {
+lldb_ymm0_x86_64,   lldb_ymm1_x86_64,  lldb_ymm2_x86_64,  lldb_ymm3_x86_64,
+lldb_ymm4_x86_64,   lldb_ymm5_x86_64,  lldb_ymm6_x86_64,  lldb_ymm7_x86_64,
+lldb_ymm8_x86_64,   lldb_ymm9_x86_64,  lldb_ymm10_x86_64, lldb_ymm11_x86_64,
+lldb_ymm12_x86_64,  lldb_ymm13_x86_64, lldb_ymm14_x86_64, lldb_ymm15_x86_64,
+// Note: we currently do not provide them but this is needed t

[Lldb-commits] [PATCH] D64647: [lldb] [Process/NetBSD] Multithread support

[Michał Górny via Phabricator via lldb-commits]

mgorny updated this revision to Diff 227295.
mgorny added a comment.

Another WIP update.


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

https://reviews.llvm.org/D64647

Files:
  
lldb/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/TestConcurrentBreakpointDelayBreakpointOneSignal.py
  
lldb/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/TestConcurrentBreakpointOneDelayBreakpointThreads.py
  
lldb/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/TestConcurrentCrashWithBreak.py
  
lldb/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/TestConcurrentCrashWithSignal.py
  
lldb/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/TestConcurrentDelaySignalBreak.py
  
lldb/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/TestConcurrentDelayedCrashWithBreakpointSignal.py
  
lldb/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/TestConcurrentManyCrash.py
  
lldb/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/TestConcurrentSignalBreak.py
  
lldb/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/TestConcurrentTwoBreakpointThreads.py
  
lldb/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/TestConcurrentTwoBreakpointsOneDelaySignal.py
  
lldb/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/TestConcurrentTwoBreakpointsOneSignal.py
  
lldb/packages/Python/lldbsuite/test/functionalities/thread/exit_during_break/TestExitDuringBreak.py
  
lldb/packages/Python/lldbsuite/test/functionalities/thread/exit_during_step/TestExitDuringStep.py
  
lldb/packages/Python/lldbsuite/test/functionalities/thread/num_threads/TestNumThreads.py
  
lldb/packages/Python/lldbsuite/test/functionalities/thread/step_out/TestThreadStepOut.py
  
lldb/packages/Python/lldbsuite/test/functionalities/thread/thread_exit/TestThreadExit.py
  
lldb/packages/Python/lldbsuite/test/python_api/lldbutil/iter/TestLLDBIterator.py
  lldb/source/Plugins/Process/NetBSD/NativeProcessNetBSD.cpp
  lldb/source/Plugins/Process/NetBSD/NativeProcessNetBSD.h
  lldb/source/Plugins/Process/NetBSD/NativeThreadNetBSD.cpp
  lldb/source/Plugins/Process/NetBSD/NativeThreadNetBSD.h

Index: lldb/source/Plugins/Process/NetBSD/NativeThreadNetBSD.h
===
--- lldb/source/Plugins/Process/NetBSD/NativeThreadNetBSD.h
+++ lldb/source/Plugins/Process/NetBSD/NativeThreadNetBSD.h
@@ -48,11 +48,16 @@
 private:
   // Interface for friend classes
 
+  Status Resume();
+  Status SingleStep();
+  Status Suspend();
+
   void SetStoppedBySignal(uint32_t signo, const siginfo_t *info = nullptr);
   void SetStoppedByBreakpoint();
   void SetStoppedByTrace();
   void SetStoppedByExec();
   void SetStoppedByWatchpoint(uint32_t wp_index);
+  void SetStoppedWithNoReason();
   void SetStopped();
   void SetRunning();
   void SetStepping();
Index: lldb/source/Plugins/Process/NetBSD/NativeThreadNetBSD.cpp
===
--- lldb/source/Plugins/Process/NetBSD/NativeThreadNetBSD.cpp
+++ lldb/source/Plugins/Process/NetBSD/NativeThreadNetBSD.cpp
@@ -17,6 +17,11 @@
 #include "lldb/Utility/RegisterValue.h"
 #include "lldb/Utility/State.h"
 
+// clang-format off
+#include 
+#include 
+// clang-format on
+
 #include 
 
 using namespace lldb;
@@ -30,6 +35,38 @@
 NativeRegisterContextNetBSD::CreateHostNativeRegisterContextNetBSD(process.GetArchitecture(), *this)
 ), m_stop_description() {}
 
+Status NativeThreadNetBSD::Resume() {
+  Status ret = NativeProcessNetBSD::PtraceWrapper(PT_RESUME, m_process.GetID(),
+  nullptr, GetID());
+  if (!ret.Success())
+return ret;
+  ret = NativeProcessNetBSD::PtraceWrapper(PT_CLEARSTEP, m_process.GetID(),
+   nullptr, GetID());
+  if (ret.Success())
+SetRunning();
+  return ret;
+}
+
+Status NativeThreadNetBSD::SingleStep() {
+  Status ret = NativeProcessNetBSD::PtraceWrapper(PT_RESUME, m_process.GetID(),
+  nullptr, GetID());
+  if (!ret.Success())
+return ret;
+  ret = NativeProcessNetBSD::PtraceWrapper(PT_SETSTEP, m_process.GetID(),
+   nullptr, GetID());
+  if (ret.Success())
+SetStepping();
+  return ret;
+}
+
+Status NativeThreadNetBSD::Suspend() {
+  Status ret = NativeProcessNetBSD::PtraceWrapper(PT_SUSPEND, m_process.GetID(),
+  nullptr, GetID());
+  if (ret.Success())
+SetStopped();
+  return ret;
+}
+
 void NativeThreadNetBSD::SetStoppedBySignal(uint32_t signo,
 const siginfo_t *info) {
   Log *log(ProcessPOSIXLog::GetLogIfAllCategoriesSet(POSIX_LOG_THREAD));
@@ -89,6 +126,13 @@
   m_stop_info.details.signal.s

[Lldb-commits] [lldb] aafe01f - Upstream diff from swift-lldb.

[Adrian Prantl via lldb-commits]

Author: Adrian Prantl
Date: 2019-10-31T09:25:36-07:00
New Revision: aafe01fed4a29090b86432e0356a47a249d5a106

URL: 
https://github.com/llvm/llvm-project/commit/aafe01fed4a29090b86432e0356a47a249d5a106
DIFF: 
https://github.com/llvm/llvm-project/commit/aafe01fed4a29090b86432e0356a47a249d5a106.diff

LOG: Upstream diff from swift-lldb.

This is very likely untested, but it looks like an obviously correct change.

Added: 


Modified: 
lldb/source/Commands/CommandObjectTarget.cpp

Removed: 




diff  --git a/lldb/source/Commands/CommandObjectTarget.cpp 
b/lldb/source/Commands/CommandObjectTarget.cpp
index 40e80bd7e94f..a63caab4dbd9 100644
--- a/lldb/source/Commands/CommandObjectTarget.cpp
+++ b/lldb/source/Commands/CommandObjectTarget.cpp
@@ -3749,7 +3749,7 @@ class CommandObjectTargetModulesLookup : public 
CommandObjectParsed {
   break;
 }
 
-return true;
+return false;
   }
 
   bool LookupInModule(CommandInterpreter &interpreter, Module *module,



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

[Lldb-commits] [PATCH] D68270: DWARFDebugLoc: Add a function to get the address range of an entry

[Pavel Labath via Phabricator via lldb-commits]

labath abandoned this revision.
labath marked an inline comment as done.
labath added a comment.

Abandoning. I'll create separate patches with the new implementation.




Comment at: lib/DebugInfo/DWARF/DWARFDebugLoc.cpp:291-295
+  EntryIterator Absolute =
+  getAbsoluteLocations(
+  SectionedAddress{BaseAddr, SectionedAddress::UndefSection},
+  LookupPooledAddress)
+  .begin();

JDevlieghere wrote:
> labath wrote:
> > dblaikie wrote:
> > > labath wrote:
> > > > dblaikie wrote:
> > > > > labath wrote:
> > > > > > dblaikie wrote:
> > > > > > > labath wrote:
> > > > > > > > dblaikie wrote:
> > > > > > > > > labath wrote:
> > > > > > > > > > This parallel iteration is not completely nice, but I think 
> > > > > > > > > > it's worth being able to reuse the absolute range 
> > > > > > > > > > computation code. I'm open to ideas for improvement though.
> > > > > > > > > Ah, I see - this is what you meant about "In particular it 
> > > > > > > > > makes it possible to reuse this stuff in the dumping code, 
> > > > > > > > > which would have been pretty hard with callbacks.".
> > > > > > > > > 
> > > > > > > > > I'm wondering if that might be worth revisiting somewhat. A 
> > > > > > > > > full iterator abstraction for one user here (well, two once 
> > > > > > > > > you include lldb - but I assume it's likely going to build 
> > > > > > > > > its own data structure from the iteration anyway, right? 
> > > > > > > > > (it's not going to keep the iterator around, do anything 
> > > > > > > > > interesting like partial iterations, re-iterate/etc - such 
> > > > > > > > > that a callback would suffice))
> > > > > > > > > 
> > > > > > > > > I could imagine two callback APIs for this - one that gets 
> > > > > > > > > entries and locations and one that only gets locations by 
> > > > > > > > > filtering on the entry version.
> > > > > > > > > 
> > > > > > > > > eg:
> > > > > > > > > 
> > > > > > > > >   // for non-verbose output:
> > > > > > > > >   LL.forEachEntry([&](const Entry &E, Expected 
> > > > > > > > > L) {
> > > > > > > > > if (Verbose && actually dumping debug_loc)
> > > > > > > > >   print(E) // print any LLE_*, raw parameters, etc
> > > > > > > > > if (L)
> > > > > > > > >   print(*L) // print the resulting address range, section 
> > > > > > > > > name (if verbose), 
> > > > > > > > > else
> > > > > > > > >   print(error stuff)
> > > > > > > > >   });
> > > > > > > > > 
> > > > > > > > > One question would be "when/where do we print the DWARF 
> > > > > > > > > expression" - if there's an error computing the address 
> > > > > > > > > range, we can still print the expression, so maybe that 
> > > > > > > > > happens unconditionally at the end of the callback, using the 
> > > > > > > > > expression in the Entry? (then, arguably, the expression 
> > > > > > > > > doesn't need to be in the DWARFLocation - and I'd say make 
> > > > > > > > > the DWARFLocation a sectioned range, exactly the same type as 
> > > > > > > > > for ranges so that part of the dumping code, etc, can be 
> > > > > > > > > maximally reused)
> > > > > > > > Actually, what lldb currently does is that it does not build 
> > > > > > > > any data structures at all (except storing the pointer to the 
> > > > > > > > right place in the debug_loc section. Then, whenever it wants 
> > > > > > > > to do something to the loclist, it parses it afresh. I don't 
> > > > > > > > know why it does this exactly, but I assume it has something to 
> > > > > > > > do with most locations never being used, or being only a couple 
> > > > > > > > of times, and the actual parsing being fairly fast. What this 
> > > > > > > > means is that lldb is not really a single "user", but there are 
> > > > > > > > like four or five places where it iterates through the list, 
> > > > > > > > depending on what does it actually want to do with it. It also 
> > > > > > > > does partial iteration where it stops as soon as it find the 
> > > > > > > > entry it was interested in.
> > > > > > > > Now, all of that is possible with a callback (though I am 
> > > > > > > > generally trying to avoid them), but it does resurface the 
> > > > > > > > issue of what should be the value of the second argument for 
> > > > > > > > DW_LLE_base_address entries (the thing which I originally used 
> > > > > > > > a error type for).
> > > > > > > > Maybe this should be actually one callback API, taking two 
> > > > > > > > callback functions, with one of them being invoked for 
> > > > > > > > base_address entries, and one for others? However, if we stick 
> > > > > > > > to the current approaches in both LLE and RLE of making the 
> > > > > > > > address pool resolution function a parameter (which I'd like to 
> > > > > > > > keep, as it makes my job in lldb easier), then this would 
> > > > > > > > actually be three callbacks, which starts to get unwieldy. 
> > > > > > > > Though one of those callbacks cou

Re: [Lldb-commits] [PATCH] D69555: [zorg] Fix LLDBCmakeBuildFactory

[Galina Kistanova via lldb-commits]

I have removed the extra quotation marks in
https://reviews.llvm.org/rZORGe249863ac732.
The change applied to staging and will wait the next master restart tonight.

Thanks

Galina


On Thu, Oct 31, 2019 at 3:35 AM Pavel Labath via Phabricator
 wrote:
>
> labath added a comment.
>
> In D69555#1728291 , @labath wrote:
>
> > (which actually surprises me a lot)
>
>
> Actually, nevermind. The linux bot fails now in the same way as the windows 
> one (http://lab.llvm.org:8014/builders/lldb-x86_64-debian/builds/6262). 
> Galina, will you remove the extra quotes, or should I?
>
>
> Repository:
>   rZORG LLVM Github Zorg
>
> CHANGES SINCE LAST ACTION
>   https://reviews.llvm.org/D69555/new/
>
> https://reviews.llvm.org/D69555
>
>
>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [PATCH] D69589: [lldb] Refactor all POST_BUILD commands into targets

[Jim Ingham via lldb-commits]

I see your concern about source and target paths for Python files, but I also 
think it is valuable that it is really easy to find examples of using lldb with 
the Python SB API's - both with toy examples and with fully worked examples.  I 
know people have found and copied from here to good effect, whereas if they 
were somewhere buried in the source tree, that would be less likely to happen.  
So however this ends up I don't want any of these scripts to be hard to find in 
the sources, and would rather they all stay in a common directory sub-tree to 
that end.

Jim

> On Oct 31, 2019, at 2:02 AM, Pavel Labath via Phabricator via lldb-commits 
>  wrote:
> 
> labath accepted this revision.
> labath added a comment.
> This revision is now accepted and ready to land.
> 
> This looks great to me. Maybe wait a while to see if anyone else has any 
> thoughts on this?
> 
> This not your fault, but the thing that bothers me about this build process 
> (and which this patch makes visible) is how the locations of the python files 
> in source bear absolutely no resemblance to the locations the files will end 
> up installed.  For instance, I would never have expected that something from 
> the "examples" folder ends up in an actual shippable artifact. I think it 
> would be great if we could rearrange the sources so that their source layout 
> roughly matches the way in which they are going to be used...
> 
> 
> 
> 
> Comment at: lldb/CMakeLists.txt:133
> +  add_copy_file_target(lldb_python_init
> +FILES  "${lldb_scripts_dir}/lldb.py"
> +DEST_DIR   "${lldb_python_build_path}"
> 
> hhb wrote:
>> labath wrote:
>>> Would it be possible to just make the swig step place this file into the 
>>> correct place directly?
>> The difficulty is that, there is a config time path dependency like this:
>> 
>> swig_wrapper -> liblldb -> finish_swig (renamed to lldb_python_packages in 
>> this change)
>> 
>> Where liblldb uses the path of LLDBWrapPython.cpp in swig_wrapper. And here 
>> we reference the path of liblldb, to calculate the right path for python 
>> packages.
>> 
>> That means when swig_wrapper is created, we don't have a good way to figure 
>> out the right path for python packages and put the file there directly.
>> 
>> The best way to solve this is to hard code liblldb path for framework build. 
>> I.e. replace line 92 here:
>> 
>> ```
>> get_target_property(liblldb_build_dir liblldb LIBRARY_OUTPUT_DIRECTORY)
>> ```
>> 
>> With something more constant. This removes the liblldb -> finish_swig 
>> dependency. Then all the code here can be moved to scripts/CMakeLists.txt (I 
>> think they belong there better anyway). And swig_wrapper can get access to 
>> python package path.
>> 
>> The only question is whether we can / should "predict" liblldb path for 
>> framework... I'll look more into this. But it probably deserves a separate 
>> change.
> Ok, that sounds fair. I think it would be great if this stuff could be moved 
> to the scripts folder.
> 
> 
> Repository:
> rG LLVM Github Monorepo
> 
> CHANGES SINCE LAST ACTION
> https://reviews.llvm.org/D69589/new/
> 
> https://reviews.llvm.org/D69589
> 
> 
> 
> ___
> lldb-commits mailing list
> lldb-commits@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

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

[Lldb-commits] [lldb] db54245 - [Symbol] Change ClangASTContext::GetCXXClassName return type

[Alex Langford via lldb-commits]

Author: Alex Langford
Date: 2019-10-31T11:57:37-07:00
New Revision: db542455dc0f5873851e220bf72a8394767c61fb

URL: 
https://github.com/llvm/llvm-project/commit/db542455dc0f5873851e220bf72a8394767c61fb
DIFF: 
https://github.com/llvm/llvm-project/commit/db542455dc0f5873851e220bf72a8394767c61fb.diff

LOG: [Symbol] Change ClangASTContext::GetCXXClassName return type

Summary:
Instead of filling out a std::string and returning a bool to indicate
success, returning a std::string directly and testing to see if it's
empty seems like a cleaner solution overall.

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

Added: 


Modified: 
lldb/include/lldb/Symbol/ClangASTContext.h
lldb/source/Core/ValueObject.cpp
lldb/source/Symbol/ClangASTContext.cpp

Removed: 




diff  --git a/lldb/include/lldb/Symbol/ClangASTContext.h 
b/lldb/include/lldb/Symbol/ClangASTContext.h
index e59e756276c8..9538deccbe04 100644
--- a/lldb/include/lldb/Symbol/ClangASTContext.h
+++ b/lldb/include/lldb/Symbol/ClangASTContext.h
@@ -601,8 +601,7 @@ class ClangASTContext : public TypeSystem {
 
   bool SupportsLanguage(lldb::LanguageType language) override;
 
-  static bool GetCXXClassName(const CompilerType &type,
-  std::string &class_name);
+  static llvm::Optional GetCXXClassName(const CompilerType &type);
 
   // Type Completion
 

diff  --git a/lldb/source/Core/ValueObject.cpp 
b/lldb/source/Core/ValueObject.cpp
index aa03e3b9f499..7b4034c06400 100644
--- a/lldb/source/Core/ValueObject.cpp
+++ b/lldb/source/Core/ValueObject.cpp
@@ -2023,15 +2023,14 @@ bool ValueObject::GetBaseClassPath(Stream &s) {
 bool parent_had_base_class =
 GetParent() && GetParent()->GetBaseClassPath(s);
 CompilerType compiler_type = GetCompilerType();
-std::string cxx_class_name;
-bool this_had_base_class =
-ClangASTContext::GetCXXClassName(compiler_type, cxx_class_name);
-if (this_had_base_class) {
+llvm::Optional cxx_class_name =
+ClangASTContext::GetCXXClassName(compiler_type);
+if (cxx_class_name) {
   if (parent_had_base_class)
 s.PutCString("::");
-  s.PutCString(cxx_class_name);
+  s.PutCString(cxx_class_name.getValue());
 }
-return parent_had_base_class || this_had_base_class;
+return parent_had_base_class || cxx_class_name;
   }
   return false;
 }

diff  --git a/lldb/source/Symbol/ClangASTContext.cpp 
b/lldb/source/Symbol/ClangASTContext.cpp
index 4a44ee0b1c73..61b08ab9f516 100644
--- a/lldb/source/Symbol/ClangASTContext.cpp
+++ b/lldb/source/Symbol/ClangASTContext.cpp
@@ -3850,20 +3850,20 @@ bool 
ClangASTContext::SupportsLanguage(lldb::LanguageType language) {
   return ClangASTContextSupportsLanguage(language);
 }
 
-bool ClangASTContext::GetCXXClassName(const CompilerType &type,
-  std::string &class_name) {
-  if (type) {
-clang::QualType qual_type(ClangUtil::GetCanonicalQualType(type));
-if (!qual_type.isNull()) {
-  clang::CXXRecordDecl *cxx_record_decl = qual_type->getAsCXXRecordDecl();
-  if (cxx_record_decl) {
-class_name.assign(cxx_record_decl->getIdentifier()->getNameStart());
-return true;
-  }
-}
-  }
-  class_name.clear();
-  return false;
+Optional
+ClangASTContext::GetCXXClassName(const CompilerType &type) {
+  if (!type)
+return llvm::None;
+
+  clang::QualType qual_type(ClangUtil::GetCanonicalQualType(type));
+  if (qual_type.isNull())
+return llvm::None;
+
+  clang::CXXRecordDecl *cxx_record_decl = qual_type->getAsCXXRecordDecl();
+  if (!cxx_record_decl)
+return llvm::None;
+
+  return std::string(cxx_record_decl->getIdentifier()->getNameStart());
 }
 
 bool ClangASTContext::IsCXXClassType(const CompilerType &type) {



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

[Lldb-commits] [PATCH] D69641: [Symbol] Change ClangASTContext::GetCXXClassName return type

[Alex Langford via Phabricator via lldb-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGdb542455dc0f: [Symbol] Change 
ClangASTContext::GetCXXClassName return type (authored by xiaobai).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69641

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


Index: lldb/source/Symbol/ClangASTContext.cpp
===
--- lldb/source/Symbol/ClangASTContext.cpp
+++ lldb/source/Symbol/ClangASTContext.cpp
@@ -3850,20 +3850,20 @@
   return ClangASTContextSupportsLanguage(language);
 }
 
-bool ClangASTContext::GetCXXClassName(const CompilerType &type,
-  std::string &class_name) {
-  if (type) {
-clang::QualType qual_type(ClangUtil::GetCanonicalQualType(type));
-if (!qual_type.isNull()) {
-  clang::CXXRecordDecl *cxx_record_decl = qual_type->getAsCXXRecordDecl();
-  if (cxx_record_decl) {
-class_name.assign(cxx_record_decl->getIdentifier()->getNameStart());
-return true;
-  }
-}
-  }
-  class_name.clear();
-  return false;
+Optional
+ClangASTContext::GetCXXClassName(const CompilerType &type) {
+  if (!type)
+return llvm::None;
+
+  clang::QualType qual_type(ClangUtil::GetCanonicalQualType(type));
+  if (qual_type.isNull())
+return llvm::None;
+
+  clang::CXXRecordDecl *cxx_record_decl = qual_type->getAsCXXRecordDecl();
+  if (!cxx_record_decl)
+return llvm::None;
+
+  return std::string(cxx_record_decl->getIdentifier()->getNameStart());
 }
 
 bool ClangASTContext::IsCXXClassType(const CompilerType &type) {
Index: lldb/source/Core/ValueObject.cpp
===
--- lldb/source/Core/ValueObject.cpp
+++ lldb/source/Core/ValueObject.cpp
@@ -2023,15 +2023,14 @@
 bool parent_had_base_class =
 GetParent() && GetParent()->GetBaseClassPath(s);
 CompilerType compiler_type = GetCompilerType();
-std::string cxx_class_name;
-bool this_had_base_class =
-ClangASTContext::GetCXXClassName(compiler_type, cxx_class_name);
-if (this_had_base_class) {
+llvm::Optional cxx_class_name =
+ClangASTContext::GetCXXClassName(compiler_type);
+if (cxx_class_name) {
   if (parent_had_base_class)
 s.PutCString("::");
-  s.PutCString(cxx_class_name);
+  s.PutCString(cxx_class_name.getValue());
 }
-return parent_had_base_class || this_had_base_class;
+return parent_had_base_class || cxx_class_name;
   }
   return false;
 }
Index: lldb/include/lldb/Symbol/ClangASTContext.h
===
--- lldb/include/lldb/Symbol/ClangASTContext.h
+++ lldb/include/lldb/Symbol/ClangASTContext.h
@@ -601,8 +601,7 @@
 
   bool SupportsLanguage(lldb::LanguageType language) override;
 
-  static bool GetCXXClassName(const CompilerType &type,
-  std::string &class_name);
+  static llvm::Optional GetCXXClassName(const CompilerType &type);
 
   // Type Completion
 


Index: lldb/source/Symbol/ClangASTContext.cpp
===
--- lldb/source/Symbol/ClangASTContext.cpp
+++ lldb/source/Symbol/ClangASTContext.cpp
@@ -3850,20 +3850,20 @@
   return ClangASTContextSupportsLanguage(language);
 }
 
-bool ClangASTContext::GetCXXClassName(const CompilerType &type,
-  std::string &class_name) {
-  if (type) {
-clang::QualType qual_type(ClangUtil::GetCanonicalQualType(type));
-if (!qual_type.isNull()) {
-  clang::CXXRecordDecl *cxx_record_decl = qual_type->getAsCXXRecordDecl();
-  if (cxx_record_decl) {
-class_name.assign(cxx_record_decl->getIdentifier()->getNameStart());
-return true;
-  }
-}
-  }
-  class_name.clear();
-  return false;
+Optional
+ClangASTContext::GetCXXClassName(const CompilerType &type) {
+  if (!type)
+return llvm::None;
+
+  clang::QualType qual_type(ClangUtil::GetCanonicalQualType(type));
+  if (qual_type.isNull())
+return llvm::None;
+
+  clang::CXXRecordDecl *cxx_record_decl = qual_type->getAsCXXRecordDecl();
+  if (!cxx_record_decl)
+return llvm::None;
+
+  return std::string(cxx_record_decl->getIdentifier()->getNameStart());
 }
 
 bool ClangASTContext::IsCXXClassType(const CompilerType &type) {
Index: lldb/source/Core/ValueObject.cpp
===
--- lldb/source/Core/ValueObject.cpp
+++ lldb/source/Core/ValueObject.cpp
@@ -2023,15 +2023,14 @@
 bool parent_had_base_class =
 GetParent() && GetParent()->GetBaseClassPath(s);
 CompilerType compiler_type = GetCompilerType();
-std::string cxx_class_name;
-bool this_had_base_class =
-ClangASTContext::GetCXXClassName(compiler_type, cxx_cl

[Lldb-commits] [lldb] 54a873b - Fix typeo in CPU_TYPE_ARM64_32 for older SDKs.

[Jason Molenda via lldb-commits]

Author: Jason Molenda
Date: 2019-10-31T14:13:57-07:00
New Revision: 54a873b158bd463db48829407f3939ff9a7be65a

URL: 
https://github.com/llvm/llvm-project/commit/54a873b158bd463db48829407f3939ff9a7be65a
DIFF: 
https://github.com/llvm/llvm-project/commit/54a873b158bd463db48829407f3939ff9a7be65a.diff

LOG: Fix typeo in CPU_TYPE_ARM64_32 for older SDKs.

Added: 


Modified: 
lldb/source/Host/macosx/objcxx/HostInfoMacOSX.mm

Removed: 




diff  --git a/lldb/source/Host/macosx/objcxx/HostInfoMacOSX.mm 
b/lldb/source/Host/macosx/objcxx/HostInfoMacOSX.mm
index ecff11f410c6..e73d2ffe9b9a 100644
--- a/lldb/source/Host/macosx/objcxx/HostInfoMacOSX.mm
+++ b/lldb/source/Host/macosx/objcxx/HostInfoMacOSX.mm
@@ -44,7 +44,7 @@
 
 #ifndef CPU_TYPE_ARM64_32
 #define CPU_ARCH_ABI64_32 0x0200
-#define (CPU_TYPE_ARM | CPU_ARCH_ABI64_32)
+#define CPU_TYPE_ARM64_32 (CPU_TYPE_ARM | CPU_ARCH_ABI64_32)
 #endif
 
 #include  // for TARGET_OS_TV, TARGET_OS_WATCH



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