[Lldb-commits] [PATCH] D121844: Applying clang-tidy modernize-use-equals-default over LLDB

[Pavel Labath via Phabricator via lldb-commits]

labath accepted this revision.
labath added inline comments.



Comment at: lldb/source/Core/Value.cpp:667
 
-const ValueList &ValueList::operator=(const ValueList &rhs) {
+const ValueList &ValueList::operator=(const ValueList &rhs) {  // 
NOLINT(modernize-use-equals-default)
   m_values = rhs.m_values;

shafik wrote:
> I have to look into why we return a `const &` here. We do this in a few other 
> places too.
I don't think there's a good reason for that. Most people aren't aware that 
built-in assignment operators return lvalues. And some of the people who are 
aware of that think that it's a bad idea, so they make sure their operators 
don't do it...



Comment at: lldb/source/Host/macosx/cfcpp/CFCMutableArray.cpp:18
 CFCMutableArray::CFCMutableArray(const CFCMutableArray &rhs)
-: CFCReleaser(rhs) // NOTE: this won't make a copy of 
the
+: CFCReleaser(rhs) // 
NOLINT(modernize-use-equals-default)
+  // NOTE: this won't make a copy of 
the

Why suppress this?



Comment at: lldb/source/Target/ExecutionContext.cpp:416
 ExecutionContextRef::ExecutionContextRef(const ExecutionContextRef &rhs)
-: m_target_wp(rhs.m_target_wp), m_process_wp(rhs.m_process_wp),
-  m_thread_wp(rhs.m_thread_wp), m_tid(rhs.m_tid),
-  m_stack_id(rhs.m_stack_id) {}
+
+  = default;

You may need to manually delete this line to get sensible clang-formatting.


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

https://reviews.llvm.org/D121844

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

[Lldb-commits] [PATCH] D121844: Applying clang-tidy modernize-use-equals-default over LLDB

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

(Please run clang-format before submitting)


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

https://reviews.llvm.org/D121844

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

[Lldb-commits] [PATCH] D121900: [lldb] Add more documentation on test variants

[Pavel Labath via Phabricator via lldb-commits]

labath created this revision.
labath added reviewers: JDevlieghere, clayborg, jingham.
Herald added a project: All.
labath requested review of this revision.
Herald added a project: LLDB.

This formalizes some of the discussion on D121631 
.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D121900

Files:
  lldb/docs/resources/test.rst


Index: lldb/docs/resources/test.rst
===
--- lldb/docs/resources/test.rst
+++ lldb/docs/resources/test.rst
@@ -185,10 +185,22 @@
 to increase test coverage. It doesn't scale. It's easy to set up, but increases
 the runtime of the tests and has a large ongoing cost.
 
-The key take away is that the different variants don't obviate the need for
-focused tests. So relying on it to test say DWARF5 is a really bad idea.
-Instead you should write tests that check the specific DWARF5 feature, and have
-the variant as a nice-to-have.
+The test variants are most useful when developing a larger feature (e.g. 
support
+for a new DWARF version). The test suite contains a large number of fairly
+generic tests, so running the test suite with the feature enabled is a good way
+to gain confidence that you haven't missed an important aspect. However, this
+genericness makes them poor regression tests. Because it's not clear what a
+specific test covers, a random modification to the test case can make it start
+(or stop) testing a completely different part of your feature. And since these
+tests tend to look very similar, it's easy for a simple bug to cause hundreds 
of
+tests to fail in the same way.
+
+For this reason, we recommend using test variants only while developing a new
+feature. This can often be done by running the test suite with different
+arguments -- without any modifications to the code. You can create a focused
+test for any bug found that way. Often, there will be many tests failing, but a
+lot of then will have the same root cause.  These tests will be easier to debug
+and will not put undue burden on all other bots and developers.
 
 In conclusion, you'll want to opt for an API test to test the API itself or
 when you need the expressivity, either for the test case itself or for the


Index: lldb/docs/resources/test.rst
===
--- lldb/docs/resources/test.rst
+++ lldb/docs/resources/test.rst
@@ -185,10 +185,22 @@
 to increase test coverage. It doesn't scale. It's easy to set up, but increases
 the runtime of the tests and has a large ongoing cost.
 
-The key take away is that the different variants don't obviate the need for
-focused tests. So relying on it to test say DWARF5 is a really bad idea.
-Instead you should write tests that check the specific DWARF5 feature, and have
-the variant as a nice-to-have.
+The test variants are most useful when developing a larger feature (e.g. support
+for a new DWARF version). The test suite contains a large number of fairly
+generic tests, so running the test suite with the feature enabled is a good way
+to gain confidence that you haven't missed an important aspect. However, this
+genericness makes them poor regression tests. Because it's not clear what a
+specific test covers, a random modification to the test case can make it start
+(or stop) testing a completely different part of your feature. And since these
+tests tend to look very similar, it's easy for a simple bug to cause hundreds of
+tests to fail in the same way.
+
+For this reason, we recommend using test variants only while developing a new
+feature. This can often be done by running the test suite with different
+arguments -- without any modifications to the code. You can create a focused
+test for any bug found that way. Often, there will be many tests failing, but a
+lot of then will have the same root cause.  These tests will be easier to debug
+and will not put undue burden on all other bots and developers.
 
 In conclusion, you'll want to opt for an API test to test the API itself or
 when you need the expressivity, either for the test case itself or for the
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D121912: [lldb] Fix ^C handling in IOHandlerProcessSTDIO

[Pavel Labath via Phabricator via lldb-commits]

labath created this revision.
labath added a reviewer: JDevlieghere.
Herald added a project: All.
labath requested review of this revision.
Herald added a project: LLDB.

D120762  accidentally moved the interrupt 
check into the block which was
reading stdio. This meant that a ^C only took effect after a regular
character has been pressed.

This patch fixes that and adds a (pexpect) test.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D121912

Files:
  lldb/source/Target/Process.cpp
  lldb/test/API/iohandler/sigint/Makefile
  lldb/test/API/iohandler/sigint/TestProcessIOHandlerInterrupt.py
  lldb/test/API/iohandler/sigint/cat.cpp

Index: lldb/test/API/iohandler/sigint/cat.cpp
===
--- /dev/null
+++ lldb/test/API/iohandler/sigint/cat.cpp
@@ -0,0 +1,12 @@
+#include 
+
+void input_copy_loop() {
+  std::string str;
+  while (std::getline(std::cin, str))
+std::cout << "read: " << str << std::endl;
+}
+
+int main() {
+  input_copy_loop();
+  return 0;
+}
Index: lldb/test/API/iohandler/sigint/TestProcessIOHandlerInterrupt.py
===
--- /dev/null
+++ lldb/test/API/iohandler/sigint/TestProcessIOHandlerInterrupt.py
@@ -0,0 +1,42 @@
+"""
+Test sending SIGINT Process IOHandler
+"""
+
+import os
+
+import lldb
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test.lldbpexpect import PExpectTest
+
+class TestCase(PExpectTest):
+
+mydir = TestBase.compute_mydir(__file__)
+
+def test(self):
+self.build(dictionary={"CXX_SOURCES":"cat.cpp"})
+self.launch(executable=self.getBuildArtifact(), timeout=5)
+
+self.child.sendline("process launch")
+self.child.expect("Process .* launched")
+
+self.child.sendline("Hello cat")
+self.child.expect_exact("read: Hello cat")
+
+self.child.sendintr()
+self.child.expect("Process .* stopped")
+self.expect_prompt()
+
+self.expect("bt", substrs=["input_copy_loop"])
+
+self.child.sendline("continue")
+self.child.expect("Process .* resuming")
+
+self.child.sendline("Goodbye cat")
+self.child.expect_exact("read: Goodbye cat")
+
+self.child.sendeof()
+self.child.expect("Process .* exited")
+self.expect_prompt()
+
+self.quit()
Index: lldb/test/API/iohandler/sigint/Makefile
===
--- /dev/null
+++ lldb/test/API/iohandler/sigint/Makefile
@@ -0,0 +1 @@
+include Makefile.rules
Index: lldb/source/Target/Process.cpp
===
--- lldb/source/Target/Process.cpp
+++ lldb/source/Target/Process.cpp
@@ -4361,18 +4361,18 @@
 break;
 } else
   break;
+  }
 
-if (select_helper.FDIsSetRead(pipe_read_fd)) {
-  size_t bytes_read;
-  // Consume the interrupt byte
-  Status error = m_pipe.Read(&ch, 1, bytes_read);
-  if (error.Success()) {
-if (ch == 'q')
-  break;
-if (ch == 'i')
-  if (StateIsRunningState(m_process->GetState()))
-m_process->SendAsyncInterrupt();
-  }
+  if (select_helper.FDIsSetRead(pipe_read_fd)) {
+size_t bytes_read;
+// Consume the interrupt byte
+Status error = m_pipe.Read(&ch, 1, bytes_read);
+if (error.Success()) {
+  if (ch == 'q')
+break;
+  if (ch == 'i')
+if (StateIsRunningState(m_process->GetState()))
+  m_process->SendAsyncInterrupt();
 }
   }
 }
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D121912: [lldb] Fix ^C handling in IOHandlerProcessSTDIO

[David Spickett via Phabricator via lldb-commits]

DavidSpickett added a comment.

I also found this in the process of looking at 
https://github.com/llvm/llvm-project/issues/53673 (different issue same area).

Bisected it to the same change you got, and this fixes things for me too.

Do you know if the pexpect test will cleanup the debugee process if some part 
of the test fails? Or will we have that hanging around in its infinite loop?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121912

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

[Lldb-commits] [PATCH] D121912: [lldb] Fix ^C handling in IOHandlerProcessSTDIO

[Jonas Devlieghere via Phabricator via lldb-commits]

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

Thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121912

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

[Lldb-commits] [lldb] 7ed1abd - [lldb] Skip invalid-condition.test on Windows

[Jonas Devlieghere via lldb-commits]

Author: Jonas Devlieghere
Date: 2022-03-17T08:34:12-07:00
New Revision: 7ed1abd4a6c1fd506423723932ca7dc70efc5a99

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

LOG: [lldb] Skip invalid-condition.test on Windows

This test is making the Windows bot unhappy. Unfortunately the output
doesn't tell me much about what exactly is wrong.

Added: 


Modified: 
lldb/test/Shell/Breakpoint/invalid-condition.test

Removed: 




diff  --git a/lldb/test/Shell/Breakpoint/invalid-condition.test 
b/lldb/test/Shell/Breakpoint/invalid-condition.test
index 5990600a9560c..91ae2ca05428a 100644
--- a/lldb/test/Shell/Breakpoint/invalid-condition.test
+++ b/lldb/test/Shell/Breakpoint/invalid-condition.test
@@ -1,3 +1,4 @@
+# UNSUPPORTED: system-windows
 # RUN: %clang_host %p/Inputs/dummy-target.c -o %t.out
 # RUN: %lldb -b -o "br s -n main -c 'bogus'" -o "run" %t.out 2>&1 | FileCheck 
%s
 



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

[Lldb-commits] [PATCH] D121831: Modifying expression code in MakeLoadImageUtilityFunction to be more consistent

[Shafik Yaghmour via Phabricator via lldb-commits]

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG33d74170a36e: [LLDB] Modifying expression code in 
MakeLoadImageUtilityFunction to be more… (authored by shafik).
Herald added a project: LLDB.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121831

Files:
  lldb/source/Plugins/Platform/POSIX/PlatformPOSIX.cpp


Index: lldb/source/Plugins/Platform/POSIX/PlatformPOSIX.cpp
===
--- lldb/source/Plugins/Platform/POSIX/PlatformPOSIX.cpp
+++ lldb/source/Plugins/Platform/POSIX/PlatformPOSIX.cpp
@@ -560,8 +560,8 @@
 const char *error_str;
   };
   
-  extern void *memcpy(void *, const void *, size_t size);
-  extern size_t strlen(const char *);
+  extern "C" void *memcpy(void *, const void *, size_t size);
+  extern "C" size_t strlen(const char *);
   
 
   void * __lldb_dlopen_wrapper (const char *name, 
@@ -608,7 +608,7 @@
   DiagnosticManager diagnostics;
 
   auto utility_fn_or_error = process->GetTarget().CreateUtilityFunction(
-  std::move(expr), dlopen_wrapper_name, eLanguageTypeObjC, exe_ctx);
+  std::move(expr), dlopen_wrapper_name, eLanguageTypeC_plus_plus, exe_ctx);
   if (!utility_fn_or_error) {
 std::string error_str = llvm::toString(utility_fn_or_error.takeError());
 error.SetErrorStringWithFormat("dlopen error: could not create utility"


Index: lldb/source/Plugins/Platform/POSIX/PlatformPOSIX.cpp
===
--- lldb/source/Plugins/Platform/POSIX/PlatformPOSIX.cpp
+++ lldb/source/Plugins/Platform/POSIX/PlatformPOSIX.cpp
@@ -560,8 +560,8 @@
 const char *error_str;
   };
   
-  extern void *memcpy(void *, const void *, size_t size);
-  extern size_t strlen(const char *);
+  extern "C" void *memcpy(void *, const void *, size_t size);
+  extern "C" size_t strlen(const char *);
   
 
   void * __lldb_dlopen_wrapper (const char *name, 
@@ -608,7 +608,7 @@
   DiagnosticManager diagnostics;
 
   auto utility_fn_or_error = process->GetTarget().CreateUtilityFunction(
-  std::move(expr), dlopen_wrapper_name, eLanguageTypeObjC, exe_ctx);
+  std::move(expr), dlopen_wrapper_name, eLanguageTypeC_plus_plus, exe_ctx);
   if (!utility_fn_or_error) {
 std::string error_str = llvm::toString(utility_fn_or_error.takeError());
 error.SetErrorStringWithFormat("dlopen error: could not create utility"
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] 33d7417 - [LLDB] Modifying expression code in MakeLoadImageUtilityFunction to be more consistent

[Shafik Yaghmour via lldb-commits]

Author: Shafik Yaghmour
Date: 2022-03-17T08:52:56-07:00
New Revision: 33d74170a36e3b801e93152effa59f19d9abb3a0

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

LOG: [LLDB] Modifying expression code in MakeLoadImageUtilityFunction to be 
more consistent

MakeLoadImageUtilityFunction() is not using extern "C" for external C functions
and it is not using eLanguageTypeC_plus_plus. So I am modifying it to be 
consistent.

Also see: rdar://87544782

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

Added: 


Modified: 
lldb/source/Plugins/Platform/POSIX/PlatformPOSIX.cpp

Removed: 




diff  --git a/lldb/source/Plugins/Platform/POSIX/PlatformPOSIX.cpp 
b/lldb/source/Plugins/Platform/POSIX/PlatformPOSIX.cpp
index a25fd1f2678eb..42de703e8ed07 100644
--- a/lldb/source/Plugins/Platform/POSIX/PlatformPOSIX.cpp
+++ b/lldb/source/Plugins/Platform/POSIX/PlatformPOSIX.cpp
@@ -560,8 +560,8 @@ 
PlatformPOSIX::MakeLoadImageUtilityFunction(ExecutionContext &exe_ctx,
 const char *error_str;
   };
   
-  extern void *memcpy(void *, const void *, size_t size);
-  extern size_t strlen(const char *);
+  extern "C" void *memcpy(void *, const void *, size_t size);
+  extern "C" size_t strlen(const char *);
   
 
   void * __lldb_dlopen_wrapper (const char *name, 
@@ -608,7 +608,7 @@ 
PlatformPOSIX::MakeLoadImageUtilityFunction(ExecutionContext &exe_ctx,
   DiagnosticManager diagnostics;
 
   auto utility_fn_or_error = process->GetTarget().CreateUtilityFunction(
-  std::move(expr), dlopen_wrapper_name, eLanguageTypeObjC, exe_ctx);
+  std::move(expr), dlopen_wrapper_name, eLanguageTypeC_plus_plus, exe_ctx);
   if (!utility_fn_or_error) {
 std::string error_str = llvm::toString(utility_fn_or_error.takeError());
 error.SetErrorStringWithFormat("dlopen error: could not create utility"



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

[Lldb-commits] [PATCH] D121900: [lldb] Add more documentation on test variants

[Jonas Devlieghere via Phabricator via lldb-commits]

JDevlieghere accepted this revision.
JDevlieghere added a comment.

LGTM. Thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121900

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

[Lldb-commits] [PATCH] D121935: added intel-pt build instructions for lldb

[Alisamar Husain via Phabricator via lldb-commits]

zrthxn created this revision.
Herald added a project: All.
zrthxn requested review of this revision.
Herald added a project: LLDB.
Herald added a subscriber: lldb-commits.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D121935

Files:
  lldb/source/Plugins/Trace/intel-pt/README.md


Index: lldb/source/Plugins/Trace/intel-pt/README.md
===
--- /dev/null
+++ lldb/source/Plugins/Trace/intel-pt/README.md
@@ -0,0 +1,90 @@
+## Instructions to build LLDB with Intel® PT Support
+
+### Before you get started
+
+1. Confirm that your processor is an Intel® x86_64 based processor.
+
+2. Check for the existance of this particular file on your Linux system
+```bash
+cat /sys/bus/event_source/devices/intel_pt/type
+```
+The output of this should be a number greater than ...?
+
+### Build Instructions
+
+1. Clone [LibIPT library](https://github.com/intel/libipt). The Intel® 
Processor Trace Decoder Library is Intel's® reference implementation for 
decoding Intel® PT. 
+```bash
+git clone g...@github.com:intel/libipt.git
+```
+
+2. Clone [the LLVM Project](https://github.com/llvm/llvm-project) in its 
entirety from Github or Phabricator.
+```bash
+git clone g...@github.com:llvm/llvm-project.git
+```
+
+3. Create build directories for both of these projects, outside the 
repositories.
+```bash
+mkdir lldb-build libipt-build
+```
+
+4. Start by building the libipt library first. LibIPT uses CMake and Make so 
*make* sure you have those. From here we will use `` and 
`` to represent the full paths of these directories. Change this 
in the following commands to the full path for your system.
+```bash
+cmake -S libipt -B 
+```
+Run make in the LibIPT build directory
+```bash
+cd 
+make
+cd ..
+```
+This will generate a few files in the `/lib` and 
`/libipt/include` directories.
+
+5. Now it is time to build LLDB and link the LibIPT build and header files 
into it. Start by configuring all the build files for LLDB from LLVM.
+```bash
+cmake \
+  -B lldb-build \
+  -G Ninja \
+-DLLVM_ENABLE_PROJECTS="clang;libcxx;lldb;libcxxabi" \
+-DLLDB_BUILD_INTEL_PT=ON \
+-DLIBIPT_INCLUDE_PATH="/libipt/include" \
+-DLIBIPT_LIBRARY_PATH="/lib" \
+  -S llvm-project/llvm
+```
+If this step goes right, you should see no errors and **no warnings for 
unused variables.**
+We have now configured the LLDB build to be built with Ninja. Make sure 
you have `ninja` installed.
+
+6. Build LLDB. This will take a while.
+```bash
+cd 
+ninja lldb lldb-server
+```
+
+7. When the build completes after a few decades, test it by running the 
version you just built.
+```bash
+./bin/lldb 
+```
+Inside LLDB, set a breakpoint and start the process runnning
+```lldb
+(lldb) break main
+(lldb) run
+```
+Now, if everything went well, when you run the following command, you 
should see no errors.
+```lldb
+(lldb) process trace start
+```
+You should also be able to see the instructions for any line.
+```lldb
+(lldb) next
+(lldb) thread trace dump instructions
+```
+
+Congratulations, you can now trace away!
+
+### References
+
+Some details about how Intel® Processor Trace works are in [this great 
blog 
post](https://engineering.fb.com/2021/04/27/developer-tools/reverse-debugging/).
+Other things about how LLDB works with this are included in [the RFC 
document](https://docs.google.com/document/d/1cOVTGp1sL_HBXjP9eB7qjVtDNr5xnuZvUUtv43G5eVI/edit#)
 for this.
+
+- https://easyperf.net/blog/2019/08/23/Intel-Processor-Trace
+- 
https://easyperf.net/blog/2019/08/30/Intel-PT-part2#appendix-how-to-build-gdb-with-intel-pt-support
+- https://reviews.llvm.org/D91679
\ No newline at end of file


Index: lldb/source/Plugins/Trace/intel-pt/README.md
===
--- /dev/null
+++ lldb/source/Plugins/Trace/intel-pt/README.md
@@ -0,0 +1,90 @@
+## Instructions to build LLDB with Intel® PT Support
+
+### Before you get started
+
+1. Confirm that your processor is an Intel® x86_64 based processor.
+
+2. Check for the existance of this particular file on your Linux system
+```bash
+cat /sys/bus/event_source/devices/intel_pt/type
+```
+The output of this should be a number greater than ...?
+
+### Build Instructions
+
+1. Clone [LibIPT library](https://github.com/intel/libipt). The Intel® Processor Trace Decoder Library is Intel's® reference implementation for decoding Intel® PT. 
+```bash
+git clone g...@github.com:intel/libipt.git
+```
+
+2. Clone [the LLVM Project](https://github.com/llvm/llvm-project) in its entirety from Github or Phabricator.
+```bash
+git clone g...@github.com:llvm/llvm-project.git
+```
+
+3. Create build directories for bo

[Lldb-commits] [PATCH] D121935: added intel-pt build instructions for lldb

[Jonas Devlieghere via Phabricator via lldb-commits]

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

Can we include this in the `docs` folder instead? Having READMEs spread 
throughout the sources isn't going to be particularly discoverable.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121935

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

[Lldb-commits] [PATCH] D121935: added intel-pt build instructions for lldb

[Alisamar Husain via Phabricator via lldb-commits]

zrthxn added a comment.

In D121935#3389954 , @JDevlieghere 
wrote:

> Can we include this in the `docs` folder instead? Having READMEs spread 
> throughout the sources isn't going to be particularly discoverable.

Sure can. Should I also use RST instead of MD? Also which particular folder in 
docs?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121935

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

[Lldb-commits] [PATCH] D121935: added intel-pt build instructions for lldb

[walter erquinigo via Phabricator via lldb-commits]

wallace requested changes to this revision.
wallace added a comment.

Thank you very much for helping out with the documentaiton!

As Jonas said, move the file to lldb/docs/intel_pt.rst and modify the necessary 
bits (some CMake changes) so that the documentation eventually appears in 
https://lldb.llvm.org/index.html as an "Tracing with Intel PT" section under 
the "Testing LLDB using QEMU" section. 
You can follow the format of https://lldb.llvm.org/use/qemu-testing.html for 
the document.




Comment at: lldb/source/Plugins/Trace/intel-pt/README.md:1
+## Instructions to build LLDB with Intel® PT Support
+

Tracing with Intel Processor Trace (Intel PT)



Comment at: lldb/source/Plugins/Trace/intel-pt/README.md:2
+## Instructions to build LLDB with Intel® PT Support
+
+### Before you get started

Intel PT is a technology available in modern Intel CPUs that allows efficient 
tracing of all the instructions executed by a process. LLDB can collect traces 
and dump them using its symbolication stack. You can read more here 
https://easyperf.net/blog/2019/08/23/Intel-Processor-Trace.



Comment at: lldb/source/Plugins/Trace/intel-pt/README.md:3
+
+### Before you get started
+

Prerequisites



Comment at: lldb/source/Plugins/Trace/intel-pt/README.md:5
+
+1. Confirm that your processor is an Intel® x86_64 based processor.
+





Comment at: lldb/source/Plugins/Trace/intel-pt/README.md:11
+```
+The output of this should be a number greater than ...?
+





Comment at: lldb/source/Plugins/Trace/intel-pt/README.md:15
+
+1. Clone [LibIPT library](https://github.com/intel/libipt). The Intel® 
Processor Trace Decoder Library is Intel's® reference implementation for 
decoding Intel® PT. 
+```bash





Comment at: lldb/source/Plugins/Trace/intel-pt/README.md:15-40
+1. Clone [LibIPT library](https://github.com/intel/libipt). The Intel® 
Processor Trace Decoder Library is Intel's® reference implementation for 
decoding Intel® PT. 
+```bash
+git clone g...@github.com:intel/libipt.git
+```
+
+2. Clone [the LLVM Project](https://github.com/llvm/llvm-project) in its 
entirety from Github or Phabricator.
+```bash

wallace wrote:
> 
Let's keep it concise and direct



Comment at: lldb/source/Plugins/Trace/intel-pt/README.md:20-23
+2. Clone [the LLVM Project](https://github.com/llvm/llvm-project) in its 
entirety from Github or Phabricator.
+```bash
+git clone g...@github.com:llvm/llvm-project.git
+```

remove this, because you can assume the developer already knows how to build 
lldb



Comment at: lldb/source/Plugins/Trace/intel-pt/README.md:25-27
+3. Create build directories for both of these projects, outside the 
repositories.
+```bash
+mkdir lldb-build libipt-build

only keep libipt-build



Comment at: lldb/source/Plugins/Trace/intel-pt/README.md:42-60
+5. Now it is time to build LLDB and link the LibIPT build and header files 
into it. Start by configuring all the build files for LLDB from LLVM.
+```bash
+cmake \
+  -B lldb-build \
+  -G Ninja \
+-DLLVM_ENABLE_PROJECTS="clang;libcxx;lldb;libcxxabi" \
+-DLLDB_BUILD_INTEL_PT=ON \





Comment at: lldb/source/Plugins/Trace/intel-pt/README.md:62-81
+7. When the build completes after a few decades, test it by running the 
version you just built.
+```bash
+./bin/lldb 
+```
+Inside LLDB, set a breakpoint and start the process runnning
+```lldb
+(lldb) break main

Instead of these instructions, you can use the internal documentation I have 
for using Intel PT.

https://pastebin.com/UiJJ32uh

Copy paste it here and add the appropriate formatting as a "How to use" section 
:)



Comment at: lldb/source/Plugins/Trace/intel-pt/README.md:85-86
+
+Some details about how Intel® Processor Trace works are in [this great 
blog 
post](https://engineering.fb.com/2021/04/27/developer-tools/reverse-debugging/).
+Other things about how LLDB works with this are included in [the RFC 
document](https://docs.google.com/document/d/1cOVTGp1sL_HBXjP9eB7qjVtDNr5xnuZvUUtv43G5eVI/edit#)
 for this.
+





Comment at: lldb/source/Plugins/Trace/intel-pt/README.md:90
+- 
https://easyperf.net/blog/2019/08/30/Intel-PT-part2#appendix-how-to-build-gdb-with-intel-pt-support
+- https://reviews.llvm.org/D91679

just delete this one


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121935

___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https:/

[Lldb-commits] [PATCH] D121631: Introduce new symbol on-demand for debug info

[jeffrey tan via Phabricator via lldb-commits]

yinghuitan added a comment.

Re @labath

> How many tests/bugs are we talking about here? Were there more than say ten 
> distinct bugs caught there?

It found 2~3 bugs, like source regex breakpoint (breakpoint set -p "source"), 
regex breakpoint filter by language (breakpoint set -r  -L c++) etc.

> running tests to new features vs find /regressions

Running all tests offline once to discover bugs is a good exericse. Since 
failing tests are understood we can put them into new tests with on-demand 
explicitly enabled then ondemand test category is unnecessary. This sounds good 
to me if Greg agrees.

> Please don't take this personally

None taken :-)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121631

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

[Lldb-commits] [PATCH] D121912: [lldb] Fix ^C handling in IOHandlerProcessSTDIO

[Jonas Devlieghere via Phabricator via lldb-commits]

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rGf93d861349f9: [lldb] Fix ^C handling in 
IOHandlerProcessSTDIO (authored by labath, committed by JDevlieghere).

Changed prior to commit:
  https://reviews.llvm.org/D121912?vs=416172&id=416274#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121912

Files:
  lldb/lldb/test/API/iohandler/sigint/Makefile
  lldb/lldb/test/API/iohandler/sigint/TestProcessIOHandlerInterrupt.py
  lldb/lldb/test/API/iohandler/sigint/cat.cpp


Index: lldb/lldb/test/API/iohandler/sigint/cat.cpp
===
--- /dev/null
+++ lldb/lldb/test/API/iohandler/sigint/cat.cpp
@@ -0,0 +1,12 @@
+#include 
+
+void input_copy_loop() {
+  std::string str;
+  while (std::getline(std::cin, str))
+std::cout << "read: " << str << std::endl;
+}
+
+int main() {
+  input_copy_loop();
+  return 0;
+}
Index: lldb/lldb/test/API/iohandler/sigint/TestProcessIOHandlerInterrupt.py
===
--- /dev/null
+++ lldb/lldb/test/API/iohandler/sigint/TestProcessIOHandlerInterrupt.py
@@ -0,0 +1,42 @@
+"""
+Test sending SIGINT Process IOHandler
+"""
+
+import os
+
+import lldb
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test.lldbpexpect import PExpectTest
+
+class TestCase(PExpectTest):
+
+mydir = TestBase.compute_mydir(__file__)
+
+def test(self):
+self.build(dictionary={"CXX_SOURCES":"cat.cpp"})
+self.launch(executable=self.getBuildArtifact(), timeout=5)
+
+self.child.sendline("process launch")
+self.child.expect("Process .* launched")
+
+self.child.sendline("Hello cat")
+self.child.expect_exact("read: Hello cat")
+
+self.child.sendintr()
+self.child.expect("Process .* stopped")
+self.expect_prompt()
+
+self.expect("bt", substrs=["input_copy_loop"])
+
+self.child.sendline("continue")
+self.child.expect("Process .* resuming")
+
+self.child.sendline("Goodbye cat")
+self.child.expect_exact("read: Goodbye cat")
+
+self.child.sendeof()
+self.child.expect("Process .* exited")
+self.expect_prompt()
+
+self.quit()
Index: lldb/lldb/test/API/iohandler/sigint/Makefile
===
--- /dev/null
+++ lldb/lldb/test/API/iohandler/sigint/Makefile
@@ -0,0 +1 @@
+include Makefile.rules


Index: lldb/lldb/test/API/iohandler/sigint/cat.cpp
===
--- /dev/null
+++ lldb/lldb/test/API/iohandler/sigint/cat.cpp
@@ -0,0 +1,12 @@
+#include 
+
+void input_copy_loop() {
+  std::string str;
+  while (std::getline(std::cin, str))
+std::cout << "read: " << str << std::endl;
+}
+
+int main() {
+  input_copy_loop();
+  return 0;
+}
Index: lldb/lldb/test/API/iohandler/sigint/TestProcessIOHandlerInterrupt.py
===
--- /dev/null
+++ lldb/lldb/test/API/iohandler/sigint/TestProcessIOHandlerInterrupt.py
@@ -0,0 +1,42 @@
+"""
+Test sending SIGINT Process IOHandler
+"""
+
+import os
+
+import lldb
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test.lldbpexpect import PExpectTest
+
+class TestCase(PExpectTest):
+
+mydir = TestBase.compute_mydir(__file__)
+
+def test(self):
+self.build(dictionary={"CXX_SOURCES":"cat.cpp"})
+self.launch(executable=self.getBuildArtifact(), timeout=5)
+
+self.child.sendline("process launch")
+self.child.expect("Process .* launched")
+
+self.child.sendline("Hello cat")
+self.child.expect_exact("read: Hello cat")
+
+self.child.sendintr()
+self.child.expect("Process .* stopped")
+self.expect_prompt()
+
+self.expect("bt", substrs=["input_copy_loop"])
+
+self.child.sendline("continue")
+self.child.expect("Process .* resuming")
+
+self.child.sendline("Goodbye cat")
+self.child.expect_exact("read: Goodbye cat")
+
+self.child.sendeof()
+self.child.expect("Process .* exited")
+self.expect_prompt()
+
+self.quit()
Index: lldb/lldb/test/API/iohandler/sigint/Makefile
===
--- /dev/null
+++ lldb/lldb/test/API/iohandler/sigint/Makefile
@@ -0,0 +1 @@
+include Makefile.rules
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] f93d861 - [lldb] Fix ^C handling in IOHandlerProcessSTDIO

[Jonas Devlieghere via lldb-commits]

Author: Pavel Labath
Date: 2022-03-17T11:52:19-07:00
New Revision: f93d861349f923f6b7ca1a425d3632eec1ff2a72

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

LOG: [lldb] Fix ^C handling in IOHandlerProcessSTDIO

D120762 accidentally moved the interrupt check into the block which was
reading stdio. This meant that a ^C only took effect after a regular
character has been pressed.

This patch fixes that and adds a (pexpect) test.

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

Added: 
lldb/lldb/test/API/iohandler/sigint/Makefile
lldb/lldb/test/API/iohandler/sigint/TestProcessIOHandlerInterrupt.py
lldb/lldb/test/API/iohandler/sigint/cat.cpp

Modified: 


Removed: 




diff  --git a/lldb/lldb/test/API/iohandler/sigint/Makefile 
b/lldb/lldb/test/API/iohandler/sigint/Makefile
new file mode 100644
index 0..22f1051530f87
--- /dev/null
+++ b/lldb/lldb/test/API/iohandler/sigint/Makefile
@@ -0,0 +1 @@
+include Makefile.rules

diff  --git 
a/lldb/lldb/test/API/iohandler/sigint/TestProcessIOHandlerInterrupt.py 
b/lldb/lldb/test/API/iohandler/sigint/TestProcessIOHandlerInterrupt.py
new file mode 100644
index 0..f1bd76e348caf
--- /dev/null
+++ b/lldb/lldb/test/API/iohandler/sigint/TestProcessIOHandlerInterrupt.py
@@ -0,0 +1,42 @@
+"""
+Test sending SIGINT Process IOHandler
+"""
+
+import os
+
+import lldb
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test.lldbpexpect import PExpectTest
+
+class TestCase(PExpectTest):
+
+mydir = TestBase.compute_mydir(__file__)
+
+def test(self):
+self.build(dictionary={"CXX_SOURCES":"cat.cpp"})
+self.launch(executable=self.getBuildArtifact(), timeout=5)
+
+self.child.sendline("process launch")
+self.child.expect("Process .* launched")
+
+self.child.sendline("Hello cat")
+self.child.expect_exact("read: Hello cat")
+
+self.child.sendintr()
+self.child.expect("Process .* stopped")
+self.expect_prompt()
+
+self.expect("bt", substrs=["input_copy_loop"])
+
+self.child.sendline("continue")
+self.child.expect("Process .* resuming")
+
+self.child.sendline("Goodbye cat")
+self.child.expect_exact("read: Goodbye cat")
+
+self.child.sendeof()
+self.child.expect("Process .* exited")
+self.expect_prompt()
+
+self.quit()

diff  --git a/lldb/lldb/test/API/iohandler/sigint/cat.cpp 
b/lldb/lldb/test/API/iohandler/sigint/cat.cpp
new file mode 100644
index 0..5a3d9380e3826
--- /dev/null
+++ b/lldb/lldb/test/API/iohandler/sigint/cat.cpp
@@ -0,0 +1,12 @@
+#include 
+
+void input_copy_loop() {
+  std::string str;
+  while (std::getline(std::cin, str))
+std::cout << "read: " << str << std::endl;
+}
+
+int main() {
+  input_copy_loop();
+  return 0;
+}



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

[Lldb-commits] [PATCH] D121831: Modifying expression code in MakeLoadImageUtilityFunction to be more consistent

[Adrian Prantl via Phabricator via lldb-commits]

aprantl added a comment.

Did you check if we have other helper expressions with the same problem?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121831

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

[Lldb-commits] [PATCH] D121942: Switched to RST

[Alisamar Husain via Phabricator via lldb-commits]

zrthxn created this revision.
Herald added a project: All.
zrthxn requested review of this revision.
Herald added a project: LLDB.
Herald added a subscriber: lldb-commits.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D121942

Files:
  lldb/docs/intel_pt.rst
  lldb/source/Plugins/Trace/intel-pt/README.md

Index: lldb/source/Plugins/Trace/intel-pt/README.md
===
--- lldb/source/Plugins/Trace/intel-pt/README.md
+++ /dev/null
@@ -1,90 +0,0 @@
-## Instructions to build LLDB with Intel® PT Support
-
-### Before you get started
-
-1. Confirm that your processor is an Intel® x86_64 based processor.
-
-2. Check for the existance of this particular file on your Linux system
-```bash
-cat /sys/bus/event_source/devices/intel_pt/type
-```
-The output of this should be a number greater than ...?
-
-### Build Instructions
-
-1. Clone [LibIPT library](https://github.com/intel/libipt). The Intel® Processor Trace Decoder Library is Intel's® reference implementation for decoding Intel® PT. 
-```bash
-git clone g...@github.com:intel/libipt.git
-```
-
-2. Clone [the LLVM Project](https://github.com/llvm/llvm-project) in its entirety from Github or Phabricator.
-```bash
-git clone g...@github.com:llvm/llvm-project.git
-```
-
-3. Create build directories for both of these projects, outside the repositories.
-```bash
-mkdir lldb-build libipt-build
-```
-
-4. Start by building the libipt library first. LibIPT uses CMake and Make so *make* sure you have those. From here we will use `` and `` to represent the full paths of these directories. Change this in the following commands to the full path for your system.
-```bash
-cmake -S libipt -B 
-```
-Run make in the LibIPT build directory
-```bash
-cd 
-make
-cd ..
-```
-This will generate a few files in the `/lib` and `/libipt/include` directories.
-
-5. Now it is time to build LLDB and link the LibIPT build and header files into it. Start by configuring all the build files for LLDB from LLVM.
-```bash
-cmake \
-  -B lldb-build \
-  -G Ninja \
--DLLVM_ENABLE_PROJECTS="clang;libcxx;lldb;libcxxabi" \
--DLLDB_BUILD_INTEL_PT=ON \
--DLIBIPT_INCLUDE_PATH="/libipt/include" \
--DLIBIPT_LIBRARY_PATH="/lib" \
-  -S llvm-project/llvm
-```
-If this step goes right, you should see no errors and **no warnings for unused variables.**
-We have now configured the LLDB build to be built with Ninja. Make sure you have `ninja` installed.
-
-6. Build LLDB. This will take a while.
-```bash
-cd 
-ninja lldb lldb-server
-```
-
-7. When the build completes after a few decades, test it by running the version you just built.
-```bash
-./bin/lldb 
-```
-Inside LLDB, set a breakpoint and start the process runnning
-```lldb
-(lldb) break main
-(lldb) run
-```
-Now, if everything went well, when you run the following command, you should see no errors.
-```lldb
-(lldb) process trace start
-```
-You should also be able to see the instructions for any line.
-```lldb
-(lldb) next
-(lldb) thread trace dump instructions
-```
-
-Congratulations, you can now trace away!
-
-### References
-
-Some details about how Intel® Processor Trace works are in [this great blog post](https://engineering.fb.com/2021/04/27/developer-tools/reverse-debugging/).
-Other things about how LLDB works with this are included in [the RFC document](https://docs.google.com/document/d/1cOVTGp1sL_HBXjP9eB7qjVtDNr5xnuZvUUtv43G5eVI/edit#) for this.
-
-- https://easyperf.net/blog/2019/08/23/Intel-Processor-Trace
-- https://easyperf.net/blog/2019/08/30/Intel-PT-part2#appendix-how-to-build-gdb-with-intel-pt-support
-- https://reviews.llvm.org/D91679
\ No newline at end of file
Index: lldb/docs/intel_pt.rst
===
--- /dev/null
+++ lldb/docs/intel_pt.rst
@@ -0,0 +1,210 @@
+Tracing with Intel Processor Trace (Intel PT)
+=
+
+.. contents::
+  :local:
+
+Intel PT is a technology available in modern Intel CPUs that allows efficient 
+tracing of all the instructions executed by a process. LLDB can collect traces and dump 
+them using its symbolication stack. You can read more here https://easyperf.net/blog/2019/08/23/Intel-Processor-Trace.
+
+Prerequisites
+-
+
+Confirm that your CPU supports Intel PT (see https://www.intel.com/content/www/us/en/support/articles/56730/processors.html) 
+and that your operating system is Linux.
+
+Check for the existance of this particular file on your Linux system
+:: 
+
+  $ cat /sys/bus/event_source/devices/intel_pt/type
+
+The output should be a number. Otherwise, try upgrading your kernel.
+
+
+Build Instructions
+--
+
+Clone and build the lo

[Lldb-commits] [PATCH] D121935: added intel-pt build instructions for lldb

[Alisamar Husain via Phabricator via lldb-commits]

zrthxn updated this revision to Diff 416287.
zrthxn added a comment.

Switched to RST


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121935

Files:
  lldb/docs/intel_pt.rst

Index: lldb/docs/intel_pt.rst
===
--- /dev/null
+++ lldb/docs/intel_pt.rst
@@ -0,0 +1,210 @@
+Tracing with Intel Processor Trace (Intel PT)
+=
+
+.. contents::
+  :local:
+
+Intel PT is a technology available in modern Intel CPUs that allows efficient 
+tracing of all the instructions executed by a process. LLDB can collect traces and dump 
+them using its symbolication stack. You can read more here https://easyperf.net/blog/2019/08/23/Intel-Processor-Trace.
+
+Prerequisites
+-
+
+Confirm that your CPU supports Intel PT (see https://www.intel.com/content/www/us/en/support/articles/56730/processors.html) 
+and that your operating system is Linux.
+
+Check for the existance of this particular file on your Linux system
+:: 
+
+  $ cat /sys/bus/event_source/devices/intel_pt/type
+
+The output should be a number. Otherwise, try upgrading your kernel.
+
+
+Build Instructions
+--
+
+Clone and build the low level Intel PT decoder library [LibIPT library](https://github.com/intel/libipt).
+:: 
+
+  $ git clone g...@github.com:intel/libipt.git
+  $ mkdir libipt-build
+  $ cmake -S libipt -B libipt-build
+  $ cd libipt-build
+  $ make
+
+This will generate a few files in the `/lib` and `/libipt/include` directories.
+
+Configure and build LLDB with Intel PT support
+:: 
+
+  $ cmake \
+  -DLLDB_BUILD_INTEL_PT=ON \
+  -DLIBIPT_INCLUDE_PATH="/libipt/include" \
+  -DLIBIPT_LIBRARY_PATH="/lib" \
+  ... other common configuration parameters 
+
+If this step goes correctly, you should see no errors and **no warnings for unused variables.**
+:: 
+
+  $ cd lldb-build 
+  $ ninja lldb lldb-server # if using Ninja
+
+How to Use
+--
+
+When you are debugging a process, you can turn on intel-pt tracing, which will “record” all the instructions 
+that the process will execute. After turning it on, you can continue debugging, and at any breakpoint, 
+you can inspect the instruction list.
+ 
+For example:
+::
+  lldb 
+  > b main
+  > run
+  > process trace start # start tracing on all threads, including future ones
+  # keep debugging until you hit a breakpoint
+  
+  > thread trace dump instructions
+  # this should output something like
+
+  thread #2: tid = 2861133, total instructions = 5305673
+libc.so.6`__GI___libc_read + 45 at read.c:25:1
+  [4962255] 0x7fffeb64c63dsubq   $0x10, %rsp
+  [4962256] 0x7fffeb64c641movq   %rdi, -0x18(%rbp)
+libc.so.6`__GI___libc_read + 53 [inlined] __libc_read at read.c:26:10
+  [4962257] 0x7fffeb64c645callq  0x7fffeb66b640; __libc_enable_asynccancel
+libc.so.6`__libc_enable_asynccancel
+  [4962258] 0x7fffeb66b640movl   %fs:0x308, %eax
+libc.so.6`__libc_enable_asynccancel + 8
+  [4962259] 0x7fffeb66b648movl   %eax, %r11d
+
+  # you can keep pressing ENTER to see more and more instructions
+ 
+The number between brackets is the instruction index, and by default the current thread will be picked.
+ 
+Configuring the trace size
+--
+ 
+The CPU stores the instruction list in a compressed format in a ring buffer, which keeps the latest information. By default, LLDB uses a buffer of 4KB per thread, but you can change it by running. The size must be a power of 2 and at least 4KB.
+::
+  thread trace start all -s 
+ 
+For reference, a 1MB trace buffer can easily store around 5M instructions.
+ 
+Printing more instructions
+--
+ 
+If you want to dump more instructions at a time, you can run
+::
+  thread trace dump instructions -c 
+ 
+Printing the instructions of another thread
+---
+
+By default the current thread will be picked when dumping instructions, but you can do
+:: 
+  thread trace dump instructions <#thread index>
+  #e.g.
+  thread trace dump instructions 8
+ 
+to select another thread.
+ 
+Crash Analysis
+--
+ 
+What if you are debugging + tracing a process that crashes? Then you can just do
+::
+  thread trace dump instructions
+ 
+To inspect how it crashed! There's nothing special that you need to do. For example
+ 
+* thread #1, name = 'a.out', stop reason = signal SIGFPE: integer divide by zero
+frame #0: 0x004009f1 a.out`main at main.cpp:8:14
+  6   int x;
+  7   cin >> x;
+-> 8   cout << 12 / x << endl;
+  9   return 0;
+  10  }
+(lldb) thread trace dump instructions -c 5
+thread #1: tid = 604302, total instructions = 8388
+  libstdc++.so.6`std::istream::operator>>(int&) + 181
+[8383] 0x000

[Lldb-commits] [PATCH] D121631: Introduce new symbol on-demand for debug info

[jeffrey tan via Phabricator via lldb-commits]

yinghuitan marked 19 inline comments as done.
yinghuitan added inline comments.



Comment at: lldb/source/Symbol/SymbolFileOnDemand.cpp:28
+
+uint32_t SymbolFileOnDemand::CalculateAbilities() {
+  if (!this->m_debug_info_enabled) {

clayborg wrote:
> We might consider letting this call always go through to the underlying 
> symbol file and report the abilities from it.
Sure. It does not matter much in real world because ability is never calculated 
on SymbolFileOnDemand. 



Comment at: lldb/source/Symbol/SymbolFileOnDemand.cpp:97
+
+bool SymbolFileOnDemand::ParseLineTable(CompileUnit &comp_unit) {
+  if (!this->m_debug_info_enabled) {

clayborg wrote:
> We might be able to always let this call through since the line tables will 
> be parsed if the user sets a file and line breakpoint. We are mainly trying 
> to stop the global name lookups in SymbolFileOnDemand
If the user sets a file and line breakpoint and a compile unit/supported file 
is matched against the breakpoint file its parent module's SymbolFileOnDemand 
will be hydrated before ParseLineTable() is called anyway so manual call 
through is unnecessary.
I prefer to keep things not pass through by default to prevent any accidental 
leaking. 



Comment at: lldb/source/Symbol/SymbolFileOnDemand.cpp:514-516
+lldb::UnwindPlanSP
+SymbolFileOnDemand::GetUnwindPlan(const Address &address,
+  const RegisterInfoResolver &resolver) {

clayborg wrote:
> We might consider letting this always go through as unwind info doesn't 
> involve any indexing of debug info.
Yes, we could. But I would like to keep all functions guarded by default unless 
explicitly required by a hydration scenario to prevent any accidental leakage.



Comment at: lldb/source/Target/Statistics.cpp:66
+  module.try_emplace("debugInfoEnabled", debug_info_enabled);
+  module.try_emplace("symtab_stripped", symtab_stripped);
   if (!symfile_path.empty())

clayborg wrote:
> Other key/value pairs for symbol table stuff start with "symbolTable",
Ah, thanks! Bad auto replace for variable name.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121631

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

[Lldb-commits] [PATCH] D121631: Introduce new symbol on-demand for debug info

[jeffrey tan via Phabricator via lldb-commits]

yinghuitan updated this revision to Diff 416333.
yinghuitan marked 4 inline comments as done.
yinghuitan added a comment.

Address review feedback.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121631

Files:
  lldb/include/lldb/Core/ModuleList.h
  lldb/include/lldb/Symbol/SymbolFile.h
  lldb/include/lldb/Symbol/SymbolFileOnDemand.h
  lldb/include/lldb/Target/Statistics.h
  lldb/include/lldb/Utility/LLDBLog.h
  lldb/packages/Python/lldbsuite/test/builders/builder.py
  lldb/packages/Python/lldbsuite/test/lldbtest.py
  lldb/packages/Python/lldbsuite/test/test_categories.py
  lldb/source/Core/CoreProperties.td
  lldb/source/Core/Module.cpp
  lldb/source/Core/ModuleList.cpp
  lldb/source/Plugins/SymbolFile/DWARF/DWARFIndex.cpp
  lldb/source/Plugins/SymbolFile/DWARF/DebugNamesDWARFIndex.cpp
  lldb/source/Symbol/CMakeLists.txt
  lldb/source/Symbol/CompileUnit.cpp
  lldb/source/Symbol/SymbolFile.cpp
  lldb/source/Symbol/SymbolFileOnDemand.cpp
  lldb/source/Target/Statistics.cpp
  lldb/source/Utility/LLDBLog.cpp
  lldb/test/API/functionalities/breakpoint/breakpoint_ids/TestBreakpointIDs.py
  lldb/test/API/functionalities/find-line-entry/TestFindLineEntry.py
  lldb/test/API/functionalities/limit-debug-info/TestLimitDebugInfo.py
  lldb/test/API/functionalities/show_location/TestShowLocationDwarf5.py
  lldb/test/API/functionalities/type_get_module/TestTypeGetModule.py
  lldb/test/API/lang/c/enum_types/TestEnumTypes.py
  lldb/test/API/lang/c/global_variables/TestGlobalVariables.py
  lldb/test/API/lang/c/shared_lib/TestSharedLib.py
  
lldb/test/API/lang/c/shared_lib_stripped_symbols/TestSharedLibStrippedSymbols.py
  lldb/test/API/lang/c/sizeof/TestCSizeof.py
  lldb/test/API/lang/c/unicode/TestUnicodeSymbols.py
  lldb/test/API/lang/cpp/breakpoint-commands/TestCPPBreakpointCommands.py
  lldb/test/API/lang/cpp/enum_types/TestCPP11EnumTypes.py
  lldb/test/API/lang/cpp/namespace_definitions/TestNamespaceDefinitions.py
  lldb/test/API/lang/cpp/sizeof/TestCPPSizeof.py
  lldb/test/API/lang/cpp/template-function/TestTemplateFunctions.py
  lldb/test/Shell/SymbolFile/OnDemand/Inputs/basic.cpp
  lldb/test/Shell/SymbolFile/OnDemand/Inputs/lib.cpp
  lldb/test/Shell/SymbolFile/OnDemand/Inputs/lib.h
  lldb/test/Shell/SymbolFile/OnDemand/Inputs/shared.cpp
  lldb/test/Shell/SymbolFile/OnDemand/shared-lib-globals.test
  lldb/test/Shell/SymbolFile/OnDemand/shared-lib.test
  lldb/test/Shell/SymbolFile/OnDemand/source-breakpoint.test
  lldb/test/Shell/SymbolFile/OnDemand/symbolic-breakpoint.test

Index: lldb/test/Shell/SymbolFile/OnDemand/symbolic-breakpoint.test
===
--- /dev/null
+++ lldb/test/Shell/SymbolFile/OnDemand/symbolic-breakpoint.test
@@ -0,0 +1,24 @@
+
+# Test shows that symbolic function breakpoint works with LLDB on demand symbol loading.
+
+# RUN: mkdir -p %t
+# RUN: cd %t
+# RUN: %build %p/Inputs/basic.cpp -o basic.out
+# RUN: %lldb -b -O "settings set symbols.load-on-demand true" -s %s basic.out | FileCheck %s
+
+breakpoint list
+# CHECK: No breakpoints currently set
+
+b bar
+# CHECK: where = {{.*}}`bar(int, int) + {{.*}} at basic.cpp:1
+
+breakpoint list
+# CHECK: where = {{.*}}`bar(int, int) + {{.*}} at basic.cpp:1
+
+run
+# CHECK: stop reason = breakpoint
+
+bt
+# CHECK: {{.*}}`bar(x=33, y=78) at basic.cpp:1
+# CHECK: {{.*}}`foo(x=33, y=78) at basic.cpp:3
+# CHECK: {{.*}}`main(argc=1, argv={{.*}}) at basic.cpp:5
Index: lldb/test/Shell/SymbolFile/OnDemand/source-breakpoint.test
===
--- /dev/null
+++ lldb/test/Shell/SymbolFile/OnDemand/source-breakpoint.test
@@ -0,0 +1,23 @@
+# Test shows that source line breakpoint works with LLDB on demand symbol loading.
+
+# RUN: mkdir -p %t
+# RUN: cd %t
+# RUN: %build %p/Inputs/basic.cpp -o basic.out
+# RUN: %lldb -b -O "settings set symbols.load-on-demand true" -s %s basic.out | FileCheck %s
+
+breakpoint list
+# CHECK: No breakpoints currently set
+
+breakpoint set -f basic.cpp -l 1
+# CHECK: where = {{.*}}`bar(int, int) + {{.*}} at basic.cpp:1
+
+breakpoint list
+# CHECK: file = 'basic.cpp'
+
+run
+# CHECK: stop reason = breakpoint
+
+bt
+# CHECK: {{.*}}`bar(x=33, y=78) at basic.cpp:1
+# CHECK: {{.*}}`foo(x=33, y=78) at basic.cpp:3
+# CHECK: {{.*}}`main(argc=1, argv={{.*}}) at basic.cpp:5
Index: lldb/test/Shell/SymbolFile/OnDemand/shared-lib.test
===
--- /dev/null
+++ lldb/test/Shell/SymbolFile/OnDemand/shared-lib.test
@@ -0,0 +1,37 @@
+# Test shows that source line breakpoint works in multiple shared libraries with LLDB on demand symbol loading.
+
+# REQUIRES: system-linux
+
+# RUN: mkdir -p %t
+# RUN: cd %t
+# RUN: %clang_host -shared -g -fpic %p/Inputs/lib.cpp -o libFoo.so
+# RUN: %clang_host -L%t -g -o shared.out %p/Inputs/shared.cpp -lFoo -Wl,-rpath=%t
+# RUN: %lldb -b -O "settings set symbols.load-on

[Lldb-commits] [PATCH] D120948: Disable LLDB index cache for .o files with no UUID.

[Greg Clayton via Phabricator via lldb-commits]

clayborg updated this revision to Diff 416334.
clayborg added a comment.

Address operator == inline suggestion for CacheSignature


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120948

Files:
  lldb/include/lldb/Core/DataFileCache.h
  lldb/source/Core/DataFileCache.cpp
  lldb/test/API/functionalities/module_cache/bsd/TestModuleCacheBSD.py
  lldb/unittests/SymbolFile/DWARF/DWARFIndexCachingTest.cpp

Index: lldb/unittests/SymbolFile/DWARF/DWARFIndexCachingTest.cpp
===
--- lldb/unittests/SymbolFile/DWARF/DWARFIndexCachingTest.cpp
+++ lldb/unittests/SymbolFile/DWARF/DWARFIndexCachingTest.cpp
@@ -196,3 +196,75 @@
   DIERef(llvm::None, DIERef::Section::DebugInfo, ++die_offset));
   EncodeDecode(set);
 }
+
+static void EncodeDecode(const CacheSignature &object, ByteOrder byte_order,
+ bool encode_result) {
+  const uint8_t addr_size = 8;
+  DataEncoder encoder(byte_order, addr_size);
+  EXPECT_EQ(encode_result, object.Encode(encoder));
+  if (!encode_result)
+return;
+  llvm::ArrayRef bytes = encoder.GetData();
+  DataExtractor data(bytes.data(), bytes.size(), byte_order, addr_size);
+  offset_t data_offset = 0;
+  CacheSignature decoded_object;
+  EXPECT_TRUE(decoded_object.Decode(data, &data_offset));
+  EXPECT_EQ(object, decoded_object);
+}
+
+static void EncodeDecode(const CacheSignature &object, bool encode_result) {
+  EncodeDecode(object, eByteOrderLittle, encode_result);
+  EncodeDecode(object, eByteOrderBig, encode_result);
+}
+
+TEST(DWARFIndexCachingTest, CacheSignatureTests) {
+  CacheSignature sig;
+  // A cache signature is only considered valid if it has a UUID.
+  sig.m_mod_time = 0x12345678;
+  EXPECT_FALSE(sig.IsValid());
+  EncodeDecode(sig, /*encode_result=*/false);
+  sig.Clear();
+
+  sig.m_obj_mod_time = 0x12345678;
+  EXPECT_FALSE(sig.IsValid());
+  EncodeDecode(sig, /*encode_result=*/false);
+  sig.Clear();
+
+  sig.m_uuid = UUID::fromData("@\x00\x11\x22\x33\x44\x55\x66\x77", 8);
+  EXPECT_TRUE(sig.IsValid());
+  EncodeDecode(sig, /*encode_result=*/true);
+  sig.m_mod_time = 0x12345678;
+  EXPECT_TRUE(sig.IsValid());
+  EncodeDecode(sig, /*encode_result=*/true);
+  sig.m_obj_mod_time = 0x456789ab;
+  EXPECT_TRUE(sig.IsValid());
+  EncodeDecode(sig, /*encode_result=*/true);
+  sig.m_mod_time = llvm::None;
+  EXPECT_TRUE(sig.IsValid());
+  EncodeDecode(sig, /*encode_result=*/true);
+
+  // Recent changes do not allow cache signatures with only a modification time
+  // or object modification time, so make sure if we try to decode such a cache
+  // file that we fail. This verifies that if we try to load an previously
+  // valid cache file where the signature is insufficient, that we will fail to
+  // decode and load these cache files.
+  DataEncoder encoder(eByteOrderLittle, /*addr_size=*/8);
+  encoder.AppendU8(2); // eSignatureModTime
+  encoder.AppendU32(0x12345678);
+  encoder.AppendU8(255); // eSignatureEnd
+
+  llvm::ArrayRef bytes = encoder.GetData();
+  DataExtractor data(bytes.data(), bytes.size(), eByteOrderLittle,
+ /*addr_size=*/8);
+  offset_t data_offset = 0;
+
+  // Make sure we fail to decode a CacheSignature with only a mod time
+  EXPECT_FALSE(sig.Decode(data, &data_offset));
+
+  // Change the signature data to contain only a eSignatureObjectModTime and
+  // make sure decoding fails as well.
+  encoder.PutU8(/*offset=*/0, 3); // eSignatureObjectModTime
+  data_offset = 0;
+  EXPECT_FALSE(sig.Decode(data, &data_offset));
+
+}
Index: lldb/test/API/functionalities/module_cache/bsd/TestModuleCacheBSD.py
===
--- lldb/test/API/functionalities/module_cache/bsd/TestModuleCacheBSD.py
+++ lldb/test/API/functionalities/module_cache/bsd/TestModuleCacheBSD.py
@@ -41,6 +41,25 @@
 @skipUnlessDarwin
 def test(self):
 """
+This test has been modified to make sure .o files that don't have
+UUIDs are not cached after discovering build systems that play with
+modification times of .o files that the modification times are not
+unique enough to ensure the .o file within the .a file are the right
+files as this was causing older cache files to be accepted for new
+updated .o files.
+
+ELF .o files do calculate a UUID from the contents of the file,
+which is expensive, but no one loads .o files into a debug sessions
+when using ELF files. Mach-o .o files do not have UUID values and do
+no calculate one as they _are_ used during debug sessions when no
+dSYM file is generated. If we can find a way to uniquely and cheaply
+create UUID values for mach-o .o files in the future, this test will
+be updated to test this functionality. This test will now make sure
+

[Lldb-commits] [lldb] 74b45f9 - [lldb] Migrate ProcessGDBRemote to ReportWarning

[Jonas Devlieghere via lldb-commits]

Author: Jonas Devlieghere
Date: 2022-03-17T15:13:48-07:00
New Revision: 74b45f91b8bf7231f76c5676c4bedc9a667012e8

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

LOG: [lldb] Migrate ProcessGDBRemote to ReportWarning

Added: 


Modified: 
lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp

Removed: 




diff  --git a/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp 
b/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
index d8dc229161c6b..2e652e11ea110 100644
--- a/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
+++ b/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
@@ -410,13 +410,13 @@ void ProcessGDBRemote::BuildDynamicRegisterInfo(bool 
force) {
   }
   if (target_definition_fspec) {
 // See if we can get register definitions from a python file
-if (ParsePythonTargetDefinition(target_definition_fspec)) {
+if (ParsePythonTargetDefinition(target_definition_fspec))
   return;
-} else {
-  StreamSP stream_sp = GetTarget().GetDebugger().GetAsyncOutputStream();
-  stream_sp->Printf("ERROR: target description file %s failed to parse.\n",
-target_definition_fspec.GetPath().c_str());
-}
+
+Debugger::ReportError("target description file " +
+  target_definition_fspec.GetPath() +
+  " failed to parse",
+  GetTarget().GetDebugger().GetID());
   }
 
   const ArchSpec &target_arch = GetTarget().GetArchitecture();



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

[Lldb-commits] [PATCH] D121967: [LLDB][NativePDB] Create inline function decls

[Zequan Wu via Phabricator via lldb-commits]

zequanwu created this revision.
Herald added a project: All.
zequanwu requested review of this revision.
Herald added a project: LLDB.
Herald added a subscriber: lldb-commits.

This creates inline functions decls in the TUs where the funcitons are inlined.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D121967

Files:
  lldb/source/Plugins/SymbolFile/NativePDB/PdbAstBuilder.cpp
  lldb/source/Plugins/SymbolFile/NativePDB/PdbAstBuilder.h
  lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.cpp
  lldb/test/Shell/SymbolFile/NativePDB/Inputs/inline_sites.lldbinit
  lldb/test/Shell/SymbolFile/NativePDB/inline_sites.s

Index: lldb/test/Shell/SymbolFile/NativePDB/inline_sites.s
===
--- lldb/test/Shell/SymbolFile/NativePDB/inline_sites.s
+++ lldb/test/Shell/SymbolFile/NativePDB/inline_sites.s
@@ -7,121 +7,199 @@
 # RUN: %p/Inputs/inline_sites.lldbinit 2>&1 | FileCheck %s
 
 # Compiled from the following files, but replaced the call to abort with nop.
+# clang-cl -fuse-ld=lld-link /Z7 /O1 /Faa.asm /winsysroot~/win_toolchain a.cpp
 # a.cpp:
-# #include "stdlib.h"
 # #include "a.h"
 # int main(int argc, char** argv) {
-#   Namespace1::foo(2);
+#   volatile int main_local = Namespace1::foo(2);
 #   return 0;
 # }
 # a.h:
+# #include 
 # #include "b.h"
 # namespace Namespace1 {
-# inline void foo(int x) {
-#   static volatile int gv_foo;
-#   ++gv_foo;
-#   if (!gv_foo)
+# inline int foo(int x) {
+#   volatile int foo_local = x + 1;
+#   ++foo_local;
+#   if (!foo_local)
 # abort();
-#   Class1::bar(x + 1);
-# }
+#   return Class1::bar(foo_local);
 # }
+# } // namespace Namespace1
 # b.h:
 # #include "c.h"
 # class Class1 {
 # public:
-#   inline static void bar(int x) {
-# static volatile int gv_bar;
-# ++gv_bar;
-# Namespace2::Class2::func(x + 1);
+#   inline static int bar(int x) {
+# volatile int bar_local = x + 1;
+# ++bar_local;
+# return Namespace2::Class2::func(bar_local);
 #   }
 # };
 # c.h:
-# namespace Namespace2{
-#   class Class2{
-# public:
-# inline static void func(int x) {
-#   static volatile int gv_func;
-#   gv_func += x;
-# }
-#   };
-# }
+# namespace Namespace2 {
+# class Class2 {
+# public:
+#   inline static int func(int x) {
+# volatile int func_local = x + 1;
+# func_local += x;
+# return func_local;
+#   }
+# };
+# } // namespace Namespace2
 
 # CHECK:  (lldb) image dump line-table a.cpp -v
-# CHECK-NEXT: Line table for {{.*}}a.cpp in
-# CHECK-NEXT: 0x000140001000: {{.*}}a.cpp:3
-# CHECK-NEXT: 0x000140001004: {{.*}}a.h:5, is_start_of_statement = TRUE, is_prologue_end = TRUE
-# CHECK-NEXT: 0x00014000100a: {{.*}}a.h:6
-# CHECK-NEXT: 0x000140001014: {{.*}}b.h:6, is_start_of_statement = TRUE, is_prologue_end = TRUE
-# CHECK-NEXT: 0x00014000101a: {{.*}}c.h:6, is_start_of_statement = TRUE, is_prologue_end = TRUE
-# CHECK-NEXT: 0x000140001021: {{.*}}a.cpp:5
-# CHECK-NEXT: 0x000140001028: {{.*}}a.h:7, is_start_of_statement = TRUE
-# CHECK-NEXT: 0x00014000102a: {{.*}}a.cpp:5, is_terminal_entry = TRUE
+# CHECK-NEXT: Line table
+# CHECK-NEXT: 0x000140001000: /tmp/a.cpp:2
+# CHECK-NEXT: 0x000140001004: /tmp/a.h:5, is_start_of_statement = TRUE, is_prologue_end = TRUE
+# CHECK-NEXT: 0x00014000100c: /tmp/a.h:6
+# CHECK-NEXT: 0x000140001010: /tmp/a.h:7
+# CHECK-NEXT: 0x000140001018: /tmp/a.h:9
+# CHECK-NEXT: 0x00014000101c: /tmp/b.h:5, is_start_of_statement = TRUE, is_prologue_end = TRUE
+# CHECK-NEXT: 0x000140001022: /tmp/b.h:6
+# CHECK-NEXT: 0x000140001026: /tmp/b.h:7
+# CHECK-NEXT: 0x00014000102a: /tmp/c.h:5, is_start_of_statement = TRUE, is_prologue_end = TRUE
+# CHECK-NEXT: 0x000140001031: /tmp/c.h:6
+# CHECK-NEXT: 0x000140001035: /tmp/c.h:7
+# CHECK-NEXT: 0x000140001039: /tmp/a.cpp:3
+# CHECK-NEXT: 0x00014000103d: /tmp/a.cpp:4
+# CHECK-NEXT: 0x000140001044: /tmp/a.h:8, is_start_of_statement = TRUE
+# CHECK-NEXT: 0x000140001046: /tmp/a.cpp:4, is_terminal_entry = TRUE
 
-# CEHCK: (lldb) b a.cpp:5
-# CHECK: Breakpoint 1: where = {{.*}}`main + 33 at a.cpp:5, address = 0x000140001021
-# CEHCK: (lldb) b a.h:5
-# CHECK: Breakpoint 2: where = {{.*}}`main + 4 [inlined] Namespace1::foo at a.h:5, address = 0x000140001004
-# CEHCK: (lldb) b a.h:6
-# CHECK: Breakpoint 3: where = {{.*}}`main + 10 [inlined] Namespace1::foo + 6 at a.h:6, address = 0x00014000100a
-# CEHCK: (lldb) b a.h:7
-# CHECK: Breakpoint 4: where = {{.*}}`main + 40 [inlined] Namespace1::foo at a.h:7, address = 0x000140001028
-# CEHCK: (lldb) b b.h:6
-# CHECK: Breakpoint 5: where = {{.*}}`main + 20 [inlined] Class1::bar at b.h:6, address = 0x000140001014
-# CEHCK: (lldb) b c.h:6
-# CHECK: Breakpoint 6: where = {{.*}}`main + 26 [inlined] Namespace2::Class2::func at c.h:6, address = 0x00014000101a
+#CHECK: (lldb) b a.h:5
+#CHECK: Breakpoint 1: where = {{.*}}`main + 4 [inlined] Na

[Lldb-commits] [PATCH] D121631: Introduce new symbol on-demand for debug info

[jeffrey tan via Phabricator via lldb-commits]

yinghuitan added a comment.

I will remove ondemand test flavor/category and add more new testcases next.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121631

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

[Lldb-commits] [PATCH] D121831: Modifying expression code in MakeLoadImageUtilityFunction to be more consistent

[Shafik Yaghmour via Phabricator via lldb-commits]

shafik added a comment.

In D121831#3390152 , @aprantl wrote:

> Did you check if we have other helper expressions with the same problem?

Yes, I could not find any other instances like this. They are not straight 
forward to find but I think I found all the places this could matter.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121831

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

[Lldb-commits] [PATCH] D121078: Replace links to archived mailing lists by links to Discourse forums

[Louis Dionne via Phabricator via lldb-commits]

ldionne accepted this revision.
ldionne added a comment.

LGTM, thanks for fixing the documentation quirks in libc++/libunwind! And sorry 
this went under my Radar last week :-).

@tonic Is this OK with you? I don't want to override your "request for changes" 
by committing this.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121078

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

[Lldb-commits] [PATCH] D121935: added intel-pt build instructions for lldb

[walter erquinigo via Phabricator via lldb-commits]

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

Pretty nice improvement! Now you need to reference this doc from the main page. 
See this reference patch https://reviews.llvm.org/D82064. According to it, you 
need to move this doc to `lldb/docs/use/intel_pt.rst` and reference it from 
`lldb/docs/index.rst`.

Besides that, you should generate the documentation and make sure that the 
output html looks correct. I haven't done that myself, but according to 
https://reviews.llvm.org/D55376, you should be able to do `ninja 
docs-lldb-html` after setting as true the cmake flag -DLLVM_ENABLE_SPHINX. 
Then, include a screenshot of the generated documentation.




Comment at: lldb/docs/intel_pt.rst:17
+
+Check for the existance of this particular file on your Linux system
+:: 





Comment at: lldb/docs/intel_pt.rst:48
+
+If this step goes correctly, you should see no errors and **no warnings for 
unused variables.**
+:: 

just remove this, as it's a little bit obvious



Comment at: lldb/docs/intel_pt.rst:51
+
+  $ cd lldb-build 
+  $ ninja lldb lldb-server # if using Ninja

let's put this as a one liner as it's common to everyone


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121935

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

[Lldb-commits] [PATCH] D121977: [lldb/test] Add progress events listener helper class to lldbutil

[Med Ismail Bennani via Phabricator via lldb-commits]

mib created this revision.
mib added reviewers: labath, JDevlieghere.
mib added a project: LLDB.
Herald added a project: All.
mib requested review of this revision.
Herald added a subscriber: lldb-commits.

This patch introduces a generic helper class that will listen for
progress event in a background thread and match it against a source
broadcaster.

If the event received matches the source broadcaster, the event is queue
up in a list that the user can access later on.

The motivation behind this is to easily test new kinds of progress
events (i.e. Swift type-system progress events). However, this patch
also update TestProgressReporting.py to make use of this new helper class.

Signed-off-by: Med Ismail Bennani 


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D121977

Files:
  lldb/packages/Python/lldbsuite/test/lldbutil.py
  lldb/test/API/functionalities/progress_reporting/TestProgressReporting.py

Index: lldb/test/API/functionalities/progress_reporting/TestProgressReporting.py
===
--- lldb/test/API/functionalities/progress_reporting/TestProgressReporting.py
+++ lldb/test/API/functionalities/progress_reporting/TestProgressReporting.py
@@ -5,54 +5,23 @@
 from lldbsuite.test.lldbtest import *
 from lldbsuite.test.decorators import *
 import lldbsuite.test.lldbutil as lldbutil
-import threading
 
 class TestProgressReporting(TestBase):
 
 mydir = TestBase.compute_mydir(__file__)
 
-eBroadcastBitStopProgressThread = (1 << 0)
-
 def setUp(self):
 TestBase.setUp(self)
-self.progress_events = []
-
-def fetch_events(self):
-event = lldb.SBEvent()
-
-done = False
-while not done:
-if self.listener.WaitForEvent(1, event):
-event_mask = event.GetType();
-if event.BroadcasterMatchesRef(self.test_broadcaster):
-if event_mask & self.eBroadcastBitStopProgressThread:
-done = True;
-elif event.BroadcasterMatchesRef(self.progress_broadcaster):
-ret_args = lldb.SBDebugger().GetProgressFromEvent(event);
-self.assertGreater(len(ret_args), 1)
-
-message = ret_args[0]
-if message:
-self.progress_events.append((message, event))
 
 def test_dwarf_symbol_loading_progress_report(self):
 """Test that we are able to fetch dwarf symbol loading progress events"""
 self.build()
 
-self.listener = lldb.SBListener("lldb.progress.listener")
-self.test_broadcaster = lldb.SBBroadcaster('lldb.broadcaster.test')
-self.listener.StartListeningForEvents(self.test_broadcaster,
-  self.eBroadcastBitStopProgressThread)
-
-self.progress_broadcaster = self.dbg.GetBroadcaster()
-self.progress_broadcaster.AddListener(self.listener, lldb.SBDebugger.eBroadcastBitProgress)
-
-listener_thread = threading.Thread(target=self.fetch_events)
-listener_thread.start()
+progress_events_listener = lldbutil.ProgressEventListener()
+progress_events_listener.start(self.dbg.GetBroadcaster(),
+   lldb.SBDebugger.eBroadcastBitProgress)
 
 lldbutil.run_to_source_breakpoint(self, 'break here', lldb.SBFileSpec('main.c'))
 
-self.test_broadcaster.BroadcastEventByType(self.eBroadcastBitStopProgressThread)
-listener_thread.join()
-
-self.assertGreater(len(self.progress_events), 0)
+progress_events = progress_events_listener.stop()
+self.assertGreater(len(progress_events), 0)
Index: lldb/packages/Python/lldbsuite/test/lldbutil.py
===
--- lldb/packages/Python/lldbsuite/test/lldbutil.py
+++ lldb/packages/Python/lldbsuite/test/lldbutil.py
@@ -1619,3 +1619,51 @@
 expect_dylib_info_response = True
 
 return dylib_info
+
+# ==
+# Utility functions to setup a progress event listener
+# ==
+
+import threading
+
+class ProgressEventListener:
+
+eBroadcastBitStopProgressThread = (1 << 0)
+
+progress_events = []
+
+def __fetch_events__(self):
+event = lldb.SBEvent()
+
+done = False
+while not done:
+if self.listener.WaitForEvent(1, event):
+event_mask = event.GetType();
+if event.BroadcasterMatchesRef(self.broadcaster):
+if event_mask & self.eBroadcastBitStopProgressThread:
+done = True;
+elif event.BroadcasterMatchesRef(self.src_broadcaster):
+ret_args = lldb.SBDebugger().GetProgressFromEvent(event);
+if not len(ret_args):
+continue
+
+   

[Lldb-commits] [PATCH] D121977: [lldb/test] Add progress events listener helper class to lldbutil

[Med Ismail Bennani via Phabricator via lldb-commits]

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

Reformat


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

https://reviews.llvm.org/D121977

Files:
  lldb/packages/Python/lldbsuite/test/lldbutil.py
  lldb/test/API/functionalities/progress_reporting/TestProgressReporting.py

Index: lldb/test/API/functionalities/progress_reporting/TestProgressReporting.py
===
--- lldb/test/API/functionalities/progress_reporting/TestProgressReporting.py
+++ lldb/test/API/functionalities/progress_reporting/TestProgressReporting.py
@@ -5,54 +5,23 @@
 from lldbsuite.test.lldbtest import *
 from lldbsuite.test.decorators import *
 import lldbsuite.test.lldbutil as lldbutil
-import threading
 
 class TestProgressReporting(TestBase):
 
 mydir = TestBase.compute_mydir(__file__)
 
-eBroadcastBitStopProgressThread = (1 << 0)
-
 def setUp(self):
 TestBase.setUp(self)
-self.progress_events = []
-
-def fetch_events(self):
-event = lldb.SBEvent()
-
-done = False
-while not done:
-if self.listener.WaitForEvent(1, event):
-event_mask = event.GetType();
-if event.BroadcasterMatchesRef(self.test_broadcaster):
-if event_mask & self.eBroadcastBitStopProgressThread:
-done = True;
-elif event.BroadcasterMatchesRef(self.progress_broadcaster):
-ret_args = lldb.SBDebugger().GetProgressFromEvent(event);
-self.assertGreater(len(ret_args), 1)
-
-message = ret_args[0]
-if message:
-self.progress_events.append((message, event))
 
 def test_dwarf_symbol_loading_progress_report(self):
 """Test that we are able to fetch dwarf symbol loading progress events"""
 self.build()
 
-self.listener = lldb.SBListener("lldb.progress.listener")
-self.test_broadcaster = lldb.SBBroadcaster('lldb.broadcaster.test')
-self.listener.StartListeningForEvents(self.test_broadcaster,
-  self.eBroadcastBitStopProgressThread)
-
-self.progress_broadcaster = self.dbg.GetBroadcaster()
-self.progress_broadcaster.AddListener(self.listener, lldb.SBDebugger.eBroadcastBitProgress)
-
-listener_thread = threading.Thread(target=self.fetch_events)
-listener_thread.start()
+progress_events_listener = lldbutil.ProgressEventListener()
+progress_events_listener.start(self.dbg.GetBroadcaster(),
+   lldb.SBDebugger.eBroadcastBitProgress)
 
 lldbutil.run_to_source_breakpoint(self, 'break here', lldb.SBFileSpec('main.c'))
 
-self.test_broadcaster.BroadcastEventByType(self.eBroadcastBitStopProgressThread)
-listener_thread.join()
-
-self.assertGreater(len(self.progress_events), 0)
+progress_events = progress_events_listener.stop()
+self.assertGreater(len(progress_events), 0)
Index: lldb/packages/Python/lldbsuite/test/lldbutil.py
===
--- lldb/packages/Python/lldbsuite/test/lldbutil.py
+++ lldb/packages/Python/lldbsuite/test/lldbutil.py
@@ -1619,3 +1619,51 @@
 expect_dylib_info_response = True
 
 return dylib_info
+
+# ==
+# Utility class to setup a progress event listener
+# ==
+
+import threading
+
+class ProgressEventListener:
+
+eBroadcastBitStopProgressThread = (1 << 0)
+
+progress_events = []
+
+def __fetch_events__(self):
+event = lldb.SBEvent()
+
+done = False
+while not done:
+if self.listener.WaitForEvent(1, event):
+event_mask = event.GetType();
+if event.BroadcasterMatchesRef(self.broadcaster):
+if event_mask & self.eBroadcastBitStopProgressThread:
+done = True;
+elif event.BroadcasterMatchesRef(self.src_broadcaster):
+ret_args = lldb.SBDebugger().GetProgressFromEvent(event);
+if not len(ret_args):
+continue
+
+message = ret_args[0]
+if message:
+self.progress_events.append((message, event))
+
+def start(self, src_broadcaster, event_mask, callback=self.__fetch_events__):
+self.src_broadcaster = src_broadcaster
+self.broadcaster = lldb.SBBroadcaster('lldb.progress.broadcaster')
+self.listener = lldb.SBListener("lldb.progress.listener")
+self.listener.StartListeningForEvents(self.test_broadcaster,
+  self.eBroadcastBitStopProgressThread)
+
+src_broadcaster.AddListener(self.listener, event_mask)
+
+

[Lldb-commits] [PATCH] D121977: [lldb/test] Add progress events listener helper class to lldbutil

[Pavel Labath via Phabricator via lldb-commits]

labath accepted this revision.
labath added inline comments.
This revision is now accepted and ready to land.



Comment at: lldb/packages/Python/lldbsuite/test/lldbutil.py:1635
+
+def __fetch_events__(self):
+event = lldb.SBEvent()

This contains way too many underscores. An [[ 
https://dbader.org/blog/meaning-of-underscores-in-python | appropriate name]] 
for a private function would be `_fetch_events`.



Comment at: lldb/packages/Python/lldbsuite/test/lldbutil.py:1640
+while not done:
+if self.listener.WaitForEvent(1, event):
+event_mask = event.GetType();

If you're doing an infinite loop, you might as well use a blocking call.


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

https://reviews.llvm.org/D121977

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