[Lldb-commits] [PATCH] D92759: [lldb] Introduce separate scratch ASTs for debug info types and types imported from C++ modules.

[Sylvestre Ledru via Phabricator via lldb-commits]

sylvestre.ledru added a comment.

This change doesn't build with gcc 5.3.1.
More details: https://bugs.llvm.org/show_bug.cgi?id=48869

It would be great if you have could have a look! thanks


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92759

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

Re: [Lldb-commits] [PATCH] D92759: [lldb] Introduce separate scratch ASTs for debug info types and types imported from C++ modules.

[Raphael “Teemperor” Isemann via lldb-commits]

Yeah, that's an unfortunate bug in GCC 5.x. I actually just fixed that before 
the weekend in 
https://reviews.llvm.org/rG37510f69b4cb8d76064f108d57bebe95984a23ae 
 

+CC Tom (who is the release manager AFAIK), as that commit probably deserves to 
be cherry-picked to the 11 release branch (which contains D92759 so it won't 
build with GCC 5.x )

Thanks!
- Raphael

> On 25 Jan 2021, at 10:04, Sylvestre Ledru via Phabricator 
>  wrote:
> 
> sylvestre.ledru added a comment.
> 
> This change doesn't build with gcc 5.3.1.
> More details: https://bugs.llvm.org/show_bug.cgi?id=48869
> 
> It would be great if you have could have a look! thanks
> 
> 
> Repository:
>  rG LLVM Github Monorepo
> 
> CHANGES SINCE LAST ACTION
>  https://reviews.llvm.org/D92759/new/
> 
> https://reviews.llvm.org/D92759
> 

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

[Lldb-commits] [lldb] e9a3fac - [LLDB] Skip TestPlatformProcessConnect on arm/aarch64 buildbot

[Muhammad Omair Javaid via lldb-commits]

Author: Muhammad Omair Javaid
Date: 2021-01-25T20:48:16+05:00
New Revision: e9a3fac76cf199d902a746c2b2fc308dfe0ade26

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

LOG: [LLDB] Skip TestPlatformProcessConnect on arm/aarch64 buildbot

TestPlatformProcessConnect is randomly failing on LLDB Arm/AArch64
buildbot. I am disabling it temporarily untill problem is fixed.

Added: 


Modified: 

lldb/test/API/tools/lldb-server/platform-process-connect/TestPlatformProcessConnect.py

Removed: 




diff  --git 
a/lldb/test/API/tools/lldb-server/platform-process-connect/TestPlatformProcessConnect.py
 
b/lldb/test/API/tools/lldb-server/platform-process-connect/TestPlatformProcessConnect.py
index 8ddab260b494..74b5f2e16eeb 100644
--- 
a/lldb/test/API/tools/lldb-server/platform-process-connect/TestPlatformProcessConnect.py
+++ 
b/lldb/test/API/tools/lldb-server/platform-process-connect/TestPlatformProcessConnect.py
@@ -12,6 +12,7 @@ class 
TestPlatformProcessConnect(gdbremote_testcase.GdbRemoteTestCaseBase):
 @expectedFailureAll(hostoslist=["windows"], triple='.*-android')
 @skipIfWindows # lldb-server does not terminate correctly
 @skipIfDarwin # lldb-server not found correctly
+@skipIf(oslist=["linux"], archs=["arm", "aarch64"])  # Fails randomly
 def test_platform_process_connect(self):
 self.build()
 



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

[Lldb-commits] [lldb] 2fd4d92 - [LLDB] Define AUXV_AT_HWCAP2 in AuxVector.h

[Muhammad Omair Javaid via lldb-commits]

Author: Muhammad Omair Javaid
Date: 2021-01-25T20:48:16+05:00
New Revision: 2fd4d923a826c9563d587e1dafefe41b461ef3b8

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

LOG: [LLDB] Define AUXV_AT_HWCAP2 in AuxVector.h

This patch defines AUXV_AT_HWCAP2 for accessing Aux extensions.

Added: 


Modified: 
lldb/source/Plugins/Process/Utility/AuxVector.cpp
lldb/source/Plugins/Process/Utility/AuxVector.h

Removed: 




diff  --git a/lldb/source/Plugins/Process/Utility/AuxVector.cpp 
b/lldb/source/Plugins/Process/Utility/AuxVector.cpp
index 685d9d0824f6..c4f45f759a33 100644
--- a/lldb/source/Plugins/Process/Utility/AuxVector.cpp
+++ b/lldb/source/Plugins/Process/Utility/AuxVector.cpp
@@ -82,6 +82,7 @@ const char *AuxVector::GetEntryName(EntryType type) const {
 case ENTRY_NAME(AUXV_AT_SECURE); break;
 case ENTRY_NAME(AUXV_AT_BASE_PLATFORM);  break;
 case ENTRY_NAME(AUXV_AT_RANDOM); break;
+case ENTRY_NAME(AUXV_AT_HWCAP2); break;
 case ENTRY_NAME(AUXV_AT_EXECFN); break;
 case ENTRY_NAME(AUXV_AT_SYSINFO);break;
 case ENTRY_NAME(AUXV_AT_SYSINFO_EHDR);   break;

diff  --git a/lldb/source/Plugins/Process/Utility/AuxVector.h 
b/lldb/source/Plugins/Process/Utility/AuxVector.h
index c8c8b1249413..07a0010e198f 100644
--- a/lldb/source/Plugins/Process/Utility/AuxVector.h
+++ b/lldb/source/Plugins/Process/Utility/AuxVector.h
@@ -50,6 +50,7 @@ class AuxVector {
 AUXV_AT_SECURE = 23,///< Boolean, was exec setuid-like?
 AUXV_AT_BASE_PLATFORM = 24, ///< String identifying real platforms.
 AUXV_AT_RANDOM = 25,///< Address of 16 random bytes.
+AUXV_AT_HWCAP2 = 26,///< Extension of AT_HWCAP.
 AUXV_AT_EXECFN = 31,///< Filename of executable.
 AUXV_AT_SYSINFO = 32, ///< Pointer to the global system page used for 
system
   /// calls and other nice things.



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

[Lldb-commits] [lldb] b45020c - [LLDB] Remove leftovers and typos from RegisterInfos_arm64_sve.h

[Muhammad Omair Javaid via lldb-commits]

Author: Muhammad Omair Javaid
Date: 2021-01-25T20:48:15+05:00
New Revision: b45020cf63f6f3a1de0f8d2b8be3c527f6cbdfd5

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

LOG: [LLDB] Remove leftovers and typos from RegisterInfos_arm64_sve.h

This patch removes a couple of left-overs and a typo from
RegisterInfos_arm64_sve.h and RegisterInfoPOSIX_arm64.h.

Added: 


Modified: 
lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm64.h
lldb/source/Plugins/Process/Utility/RegisterInfos_arm64_sve.h

Removed: 




diff  --git a/lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm64.h 
b/lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm64.h
index 1cbed5acb41c..2929f2009dd9 100644
--- a/lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm64.h
+++ b/lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm64.h
@@ -85,7 +85,7 @@ class RegisterInfoPOSIX_arm64
 
   size_t GetRegisterSetFromRegisterIndex(uint32_t reg_index) const override;
 
-  uint32_t ConfigureVectorRegisterInfos(uint32_t mode);
+  uint32_t ConfigureVectorRegisterInfos(uint32_t sve_vq);
 
   bool VectorSizeIsValid(uint32_t vq) {
 if (vq >= eVectorQuadwordAArch64 && vq <= eVectorQuadwordAArch64SVEMax)

diff  --git a/lldb/source/Plugins/Process/Utility/RegisterInfos_arm64_sve.h 
b/lldb/source/Plugins/Process/Utility/RegisterInfos_arm64_sve.h
index ea43ef8fe457..9551db7e8ebf 100644
--- a/lldb/source/Plugins/Process/Utility/RegisterInfos_arm64_sve.h
+++ b/lldb/source/Plugins/Process/Utility/RegisterInfos_arm64_sve.h
@@ -9,9 +9,6 @@
 #ifdef DECLARE_REGISTER_INFOS_ARM64_STRUCT
 
 enum {
-  sve_fpsr = fpu_fpsr,
-  sve_fpcr = fpu_fpcr,
-
   sve_vg = exc_far,
 
   sve_z0,



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

[Lldb-commits] [PATCH] D95261: [lldb/test] Reduce API test tools configuration boilerplate

[Stella Stamenova via Phabricator via lldb-commits]

stella.stamenova added inline comments.



Comment at: lldb/utils/lldb-dotest/CMakeLists.txt:87
   set(LLDB_LIBS_DIR_CONFIGURED "${LLDB_LIBS_DIR}")
+  set(LLVM_TOOLS_DIR_CONFIGURED "${LLVM_TOOLS_DIR_CONFIGURED}")
 

labath wrote:
> stella.stamenova wrote:
> > I think here you just want to set it to LLVM_TOOLS_BINARY_DIR, right?
> Yes, oops. Thanks for catching that.
You also need to add a line for LLDB_TEST_DSYMUTIL_CONFIGURED now that it is 
back


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95261

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

Re: [Lldb-commits] [PATCH] D94063: lldb: Add support for DW_AT_ranges on DW_TAG_subprograms

[Jim Ingham via lldb-commits]

lldb creates a single line table out of the debug_line input and the 
inlined_subroutine info from the debug_info.  For instance, if you have a 
nested set of inlines that all have the same start address, they cannot be 
represented in the debug_line which requires monotonically increasing 
addresses.  But when you are "stepping" into the set of nested inlines, lldb 
would like to represent the step as first stopping before the call in the outer 
function, then stepping one by one into the nested inlines.  I don't know why 
exactly DWARF line tables need to be monotonically increasing in address, but 
we couldn't see any good reason why lldb should also have to do this little 
two-step every time we tried to figure out where you are, we decided to merge 
the info up front.

You could still write Unit Tests accessing the lldb line table construction 
rather than the DWARF debug_line ingestion.  But IIRC the layer between the 
LineEntries in lldb_private and the classes in the SB API is pretty thin, so 
there's less motivation to test that way.

Jim


> On Jan 24, 2021, at 8:32 PM, David Blaikie  wrote:
> 
> 
> 
> On Fri, Jan 22, 2021 at 9:42 AM Jim Ingham  wrote:
> If you are just loading an object file and the looking at the line table or 
> something like that, would a UnitTest be more suitable?
> 
> Maybe, though for what it's worth, this isn't an issue with the line table 
> (well, not the .debug_line contents) as such - this is testing a change to 
> .debug_info - specifically, the use of DW_AT_ranges on a DW_TAG_subprogram. 
> But it manifested as breakpoints not having source information. I don't know 
> a great deal about how the line table ended up interacting with the address 
> ranges specified on the DW_TAG_subprogram, but it did in some way.
> 
> Not sure if that is or isn't especially amenable to unit testing given the 
> LLDB architecture of these components.
> 
> - Dave
>  
> 
> Jim
> 
> 
> > On Jan 22, 2021, at 5:37 AM, Pavel Labath  wrote:
> > 
> > On 19/01/2021 23:23, David Blaikie wrote:
> >> On Tue, Jan 19, 2021 at 1:12 AM Pavel Labath  wrote:
> >> Yeah - I have mixed feelings about debugger testing here - it is nice
> >> to have end-to-end tests which makes for handy debugger testing
> >> (though I guess in theory, debuginfo-tests is the place for
> >> intentional end-to-end testing), though also being able to test
> >> different features (DWARF version, split DWARF, dsym V object
> >> debugging, etc) when they're written as end-to-end tests.
> > 
> > Yeah, it would be nice if there was a clearer separation between the two 
> > categories. The current setup has evolved organically, as the end-to-end 
> > API tests used to be the only kinds of tests.
> > 
> > 
> >> Can we write non-end-to-end API tests, then?
> > 
> > Kind of. There is no fundamental reason why one couldn't run llvm-mc or 
> > whatever as a part of an API test. The main issue is that we don't have the 
> > infrastructure for that set up right now. I think the reason for that is 
> > that once you start dealing with "incomplete" executables which cannot be 
> > run on the host platform, the usefulness of interactivity goes down 
> > sharply. It is hard for such a test to do something other than load up some 
> > executable and query its state. This is a perfect use case for a shell test.
> > 
> > There are exceptions though. For example we have a collection of "API" 
> > tests which test the gdb-remote communication layer, by mocking one end of 
> > the connection. Such tests are necessarily interactive, which is why they 
> > ended up in the API category, but they are definitely not end-to-end tests, 
> > and they either don't use any executables, or just use a static yaml2objed 
> > executable. This is why our API tests have the ability to run yaml2obj and 
> > one could add other llvm tools in a similar fashion.
> > 
> > Another aspect of end-to-endness is being able to test a specific component 
> > of lldb, instead of just the debugger as a whole. Here the API tests cannot 
> > help because the "API" is the lldb public API. However, there are also 
> > various tricks you can do by using the low-level (debugging) commands (like 
> > the "image lookup" thing I mentioned) to interact with the lower debugger 
> > layers in some manner.
> > 
> > 
> > pl
> 

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

Re: [Lldb-commits] [PATCH] D94063: lldb: Add support for DW_AT_ranges on DW_TAG_subprograms

[Jim Ingham via lldb-commits]

> On Jan 24, 2021, at 8:30 PM, David Blaikie  wrote:
> 
> I guess lldb doesn't have a machine readable form, like gdb's machine 
> interface that might make for a more robust thing to test against most of the 
> time (& then leaving a limited number of tests that test the user-textual 
> output)? Instead the python API is the machine interface? 

That was the original idea, except that we also tried to make it easy to test 
command line output in the same tests that test the API's.  Really the only 
part of the system the API tests aren't great at is stuff that depends on 
mid-command interactivity (prompts, line-editing interactions, the REPL, stuff 
like that).  The difference between the two to my mind is pretty much that the 
Shell tests don't require you to know Python, or learn the SB API's to write 
tests.

>  
> Another aspect of end-to-endness is being able to test a specific 
> component of lldb, instead of just the debugger as a whole. Here the API 
> tests cannot help because the "API" is the lldb public API.
> 
> Not sure I followed here - you mean the API tests aren't more narrowly 
> targeted than the Shell tests, because the API is the public API, so it's 
> mostly/pretty close to what you can interact with from the Shell anyway - 
> doesn't give you lower-level access akin to unit testing? Fair enough.
>  

Yes, this is particularly true for lldb's plugins.  There isn't any really 
compelling reason for an lldb user to know the details of how DWARF was 
ingested.  At that level, lldb should present the data from the generic Symbol 
interface, not how it came from DWARF.  So if you want to test the DWARF parser 
specifically then UnitTests are the way to go.  And for testing utility classes 
which don't require lots of other subsystems to construct themselves, the 
UnitTests are much easier to write.  These also are easy to migrate as code 
changes because we know how to do "I added a parameter to an API, go fix the 
calling code" pretty well.

My take is that API tests will always be more precise because each time you get 
a bit of data that you want to test against you get only that data, you don't 
get it intermixed with other text that you have to decide how to either capture 
(and maybe end up testing things you didn't intend to test) or run the risk 
that the patterns you were using to grab the data you thought you were testing 
actually grabbed a different part of the command text.  The solution to that if 
you wanted to do more rigorous tests from the command line is to write special 
purpose commands that present output in a form that's not good for users but is 
better structured for testing.  But that seems like wasted effort and support 
burden when the API's to get what you want are right there in front of you...

Jim


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

[Lldb-commits] [PATCH] D93874: [process] fix exec support on Linux

[walter erquinigo via Phabricator via lldb-commits]

wallace added inline comments.



Comment at: lldb/test/API/functionalities/exec/TestExec.py:133-158
+exe = self.getBuildArtifact("a.out")
+secondprog = self.getBuildArtifact("secondprog")
+
+# Create the target
+target = self.dbg.CreateTarget(exe)
+
+# Create any breakpoints we need

jingham wrote:
> I don't think you need to set the second breakpoint till after you've stopped 
> at the first one, If not, you should be able to replace everything from the 
> "exe = self.getBuildArtifact" to the self.assertTrue(len(threads == 1)) with:
> 
> (target, process, thread, breakpoint1) = 
> lldbutil.run_to_source_breakpoint(self, 'Set breakpoint 1 here', 
> lldb.SBFileSpec('main.cpp', False))
> breakpoint2 = target.BreakpointCreateBySourceRegex(...)
> 
> and "threads[0]" below -> "thread", which is a lot easier to read.
nice! run_to_source_breakpoint is super handy


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93874

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

[Lldb-commits] [PATCH] D93874: [process] fix exec support on Linux

[walter erquinigo via Phabricator via lldb-commits]

wallace updated this revision to Diff 319069.
wallace added a comment.

apply suggestion


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93874

Files:
  lldb/include/lldb/Target/Process.h
  lldb/include/lldb/Target/ProcessTrace.h
  lldb/include/lldb/Target/ThreadPlan.h
  lldb/include/lldb/Target/ThreadPlanStack.h
  lldb/source/Plugins/Process/FreeBSD/ProcessFreeBSD.cpp
  lldb/source/Plugins/Process/FreeBSD/ProcessFreeBSD.h
  lldb/source/Plugins/Process/MacOSX-Kernel/ProcessKDP.cpp
  lldb/source/Plugins/Process/MacOSX-Kernel/ProcessKDP.h
  lldb/source/Plugins/Process/Windows/Common/ProcessWindows.cpp
  lldb/source/Plugins/Process/Windows/Common/ProcessWindows.h
  lldb/source/Plugins/Process/elf-core/ProcessElfCore.cpp
  lldb/source/Plugins/Process/elf-core/ProcessElfCore.h
  lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
  lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.h
  lldb/source/Plugins/Process/mach-core/ProcessMachCore.cpp
  lldb/source/Plugins/Process/mach-core/ProcessMachCore.h
  lldb/source/Plugins/Process/minidump/ProcessMinidump.cpp
  lldb/source/Plugins/Process/minidump/ProcessMinidump.h
  lldb/source/Target/Process.cpp
  lldb/source/Target/ProcessTrace.cpp
  lldb/source/Target/ThreadPlan.cpp
  lldb/source/Target/ThreadPlanStack.cpp
  lldb/test/API/functionalities/exec/TestExec.py
  lldb/unittests/Process/ProcessEventDataTest.cpp
  lldb/unittests/Target/ExecutionContextTest.cpp
  lldb/unittests/Thread/ThreadTest.cpp

Index: lldb/unittests/Thread/ThreadTest.cpp
===
--- lldb/unittests/Thread/ThreadTest.cpp
+++ lldb/unittests/Thread/ThreadTest.cpp
@@ -51,8 +51,8 @@
   Status &error) {
 return 0;
   }
-  virtual bool UpdateThreadList(ThreadList &old_thread_list,
-ThreadList &new_thread_list) {
+  bool DoUpdateThreadList(ThreadList &old_thread_list,
+  ThreadList &new_thread_list) override {
 return false;
   }
   virtual ConstString GetPluginName() { return ConstString("Dummy"); }
Index: lldb/unittests/Target/ExecutionContextTest.cpp
===
--- lldb/unittests/Target/ExecutionContextTest.cpp
+++ lldb/unittests/Target/ExecutionContextTest.cpp
@@ -58,8 +58,8 @@
   Status &error) {
 return 0;
   }
-  virtual bool UpdateThreadList(ThreadList &old_thread_list,
-ThreadList &new_thread_list) {
+  bool DoUpdateThreadList(ThreadList &old_thread_list,
+  ThreadList &new_thread_list) override {
 return false;
   }
   virtual ConstString GetPluginName() { return ConstString("Dummy"); }
Index: lldb/unittests/Process/ProcessEventDataTest.cpp
===
--- lldb/unittests/Process/ProcessEventDataTest.cpp
+++ lldb/unittests/Process/ProcessEventDataTest.cpp
@@ -53,8 +53,8 @@
   Status &error) {
 return 0;
   }
-  virtual bool UpdateThreadList(ThreadList &old_thread_list,
-ThreadList &new_thread_list) {
+  bool DoUpdateThreadList(ThreadList &old_thread_list,
+  ThreadList &new_thread_list) override {
 return false;
   }
   virtual ConstString GetPluginName() { return ConstString("Dummy"); }
Index: lldb/test/API/functionalities/exec/TestExec.py
===
--- lldb/test/API/functionalities/exec/TestExec.py
+++ lldb/test/API/functionalities/exec/TestExec.py
@@ -115,3 +115,68 @@
 self.runCmd("bt")
 self.assertTrue(len(threads) == 1,
 "Stopped at breakpoint in exec'ed process.")
+
+@expectedFailureAll(archs=['i386'],
+oslist=no_match(["freebsd"]),
+bugnumber="rdar://28656532")
+@expectedFailureAll(oslist=["ios", "tvos", "watchos", "bridgeos"], bugnumber="rdar://problem/34559552") # this exec test has problems on ios systems
+@expectedFailureNetBSD
+@skipIfAsan # rdar://problem/43756823
+@skipIfWindows
+def test_correct_thread_plan_state_before_exec(self):
+'''
+In this test we make sure that the Thread* cache in the ThreadPlans
+is cleared correctly when performing exec
+'''
+
+self.build()
+exe = self.getBuildArtifact("a.out")
+target = self.dbg.CreateTarget(exe)
+
+(target, process, thread, breakpoint1) = lldbutil.run_to_source_breakpoint(
+self, 'Set breakpoint 1 here', lldb.SBFileSpec('main.cpp', False))
+
+# The stop reason of the thread should be breakpoint.
+self.assertTrue(process.GetState() == lldb.eStateStopped,
+STOPPED_DUE_TO_BREAKPOINT)
+
+threads = lldbut

[Lldb-commits] [lldb] 4bb6244 - [ThreadPlan] fix exec on Linux

[Walter Erquinigo via lldb-commits]

Author: Walter Erquinigo
Date: 2021-01-25T11:30:48-08:00
New Revision: 4bb6244871c6914517a21f56830b3765495792f2

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

LOG: [ThreadPlan] fix exec on Linux

Added: 


Modified: 
lldb/include/lldb/Target/Process.h
lldb/include/lldb/Target/ProcessTrace.h
lldb/include/lldb/Target/ThreadPlan.h
lldb/include/lldb/Target/ThreadPlanStack.h
lldb/source/Plugins/Process/FreeBSD/ProcessFreeBSD.cpp
lldb/source/Plugins/Process/FreeBSD/ProcessFreeBSD.h
lldb/source/Plugins/Process/MacOSX-Kernel/ProcessKDP.cpp
lldb/source/Plugins/Process/MacOSX-Kernel/ProcessKDP.h
lldb/source/Plugins/Process/Windows/Common/ProcessWindows.cpp
lldb/source/Plugins/Process/Windows/Common/ProcessWindows.h
lldb/source/Plugins/Process/elf-core/ProcessElfCore.cpp
lldb/source/Plugins/Process/elf-core/ProcessElfCore.h
lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.h
lldb/source/Plugins/Process/mach-core/ProcessMachCore.cpp
lldb/source/Plugins/Process/mach-core/ProcessMachCore.h
lldb/source/Plugins/Process/minidump/ProcessMinidump.cpp
lldb/source/Plugins/Process/minidump/ProcessMinidump.h
lldb/source/Target/Process.cpp
lldb/source/Target/ProcessTrace.cpp
lldb/source/Target/ThreadPlan.cpp
lldb/source/Target/ThreadPlanStack.cpp
lldb/test/API/functionalities/exec/TestExec.py
lldb/unittests/Process/ProcessEventDataTest.cpp
lldb/unittests/Target/ExecutionContextTest.cpp
lldb/unittests/Thread/ThreadTest.cpp

Removed: 




diff  --git a/lldb/include/lldb/Target/Process.h 
b/lldb/include/lldb/Target/Process.h
index 5ca5dd28fd8f7..fbdb5069b39fc 100644
--- a/lldb/include/lldb/Target/Process.h
+++ b/lldb/include/lldb/Target/Process.h
@@ -2014,8 +2014,17 @@ class Process : public 
std::enable_shared_from_this,
   virtual Status DisableWatchpoint(Watchpoint *wp, bool notify = true);
 
   // Thread Queries
-  virtual bool UpdateThreadList(ThreadList &old_thread_list,
-ThreadList &new_thread_list) = 0;
+
+  /// Update the thread list.
+  ///
+  /// This method performs some general clean up before invoking
+  /// \a DoUpdateThreadList, which should be implemented by each
+  /// process plugin.
+  ///
+  /// \return
+  /// \b true if the new thread list could be generated, \b false 
otherwise.
+  bool UpdateThreadList(ThreadList &old_thread_list,
+ThreadList &new_thread_list);
 
   void UpdateThreadListIfNeeded();
 
@@ -2514,6 +2523,15 @@ void PruneThreadPlans();
 bool trap_exceptions = false);
 
 protected:
+  /// Update the thread list following process plug-in's specific logic.
+  ///
+  /// This method should only be invoked by \a UpdateThreadList.
+  ///
+  /// \return
+  /// \b true if the new thread list could be generated, \b false 
otherwise.
+  virtual bool DoUpdateThreadList(ThreadList &old_thread_list,
+  ThreadList &new_thread_list) = 0;
+
   /// Actually do the reading of memory from a process.
   ///
   /// Subclasses must override this function and can return fewer bytes than

diff  --git a/lldb/include/lldb/Target/ProcessTrace.h 
b/lldb/include/lldb/Target/ProcessTrace.h
index 53b3e704c17b0..55faba1576d00 100644
--- a/lldb/include/lldb/Target/ProcessTrace.h
+++ b/lldb/include/lldb/Target/ProcessTrace.h
@@ -71,8 +71,8 @@ class ProcessTrace : public PostMortemProcess {
 protected:
   void Clear();
 
-  bool UpdateThreadList(ThreadList &old_thread_list,
-ThreadList &new_thread_list) override;
+  bool DoUpdateThreadList(ThreadList &old_thread_list,
+  ThreadList &new_thread_list) override;
 
 private:
   static lldb::ProcessSP CreateInstance(lldb::TargetSP target_sp,

diff  --git a/lldb/include/lldb/Target/ThreadPlan.h 
b/lldb/include/lldb/Target/ThreadPlan.h
index f4cd2b18f01a1..242a4d3c2d6c8 100644
--- a/lldb/include/lldb/Target/ThreadPlan.h
+++ b/lldb/include/lldb/Target/ThreadPlan.h
@@ -325,6 +325,12 @@ class ThreadPlan : public 
std::enable_shared_from_this,
 
   const Target &GetTarget() const;
 
+  /// Clear the Thread* cache.
+  ///
+  /// This is useful in situations like when a new Thread list is being
+  /// generated.
+  void ClearThreadCache();
+
   /// Print a description of this thread to the stream \a s.
   /// \a thread.  Don't expect that the result of GetThread is valid in
   /// the description method.  This might get called when the underlying

diff  --git a/lldb/include/lldb/Target/ThreadPlanStack.h 
b/lldb/include/lldb/Target/ThreadPlanStack.h
index f1874136cad83..2d2ab2cbaefea 100644
--- a/lldb/include/lldb/Target/ThreadP

[Lldb-commits] [PATCH] D93421: Fix how ValueObject deals with getting unsigned values

[Shafik Yaghmour via Phabricator via lldb-commits]

shafik added a comment.

landed this fix: 
https://reviews.llvm.org/rGdc057e87f6c18c24d17c7cae97ebe95f78b6d934


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

https://reviews.llvm.org/D93421

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

Re: [Lldb-commits] [PATCH] D94063: lldb: Add support for DW_AT_ranges on DW_TAG_subprograms

[David Blaikie via lldb-commits]

On Mon, Jan 25, 2021 at 10:39 AM Jim Ingham  wrote:

> lldb creates a single line table out of the debug_line input and the
> inlined_subroutine info from the debug_info.  For instance, if you have a
> nested set of inlines that all have the same start address, they cannot be
> represented in the debug_line which requires monotonically increasing
> addresses.  But when you are "stepping" into the set of nested inlines,
> lldb would like to represent the step as first stopping before the call in
> the outer function, then stepping one by one into the nested inlines.  I
> don't know why exactly DWARF line tables need to be monotonically
> increasing in address, but we couldn't see any good reason why lldb should
> also have to do this little two-step every time we tried to figure out
> where you are, we decided to merge the info up front.
>
> You could still write Unit Tests accessing the lldb line table
> construction rather than the DWARF debug_line ingestion.  But IIRC the
> layer between the LineEntries in lldb_private and the classes in the SB API
> is pretty thin, so there's less motivation to test that way.
>

This patch/test isn't about inlined subroutines - it's about
DW_TAG_subprograms with DW_AT_ranges - specifically the patch
changes DWARFDebugInfoEntry::BuildFunctionAddressRangeTable - so it sounds
like it probably wouldn't be unit testable via the line table alone (or
perhaps the line table at all). Given the novel (to lldb) functionality,
and partial but untested implementation already in lldb prior to these
recent patches (there was at least one place with a comment explaining why
it was doing something a particular way to support discontiguous functions)
I think the end-to-end testing in some form (SB API or Shell, rather than
the narrower testing of a unit test) is probably valuable to give some more
test coverage to this whole situation, not only the one or two places I've
found specific bugs/fixes.

I'm still mystified why I couldn't reproduce the behavior using the SB API,
but I could using a shell test/using lldb interactively myself. But for now
it seems the Shell test is about the best thing I can do.

- Dave


>
> Jim
>
>
> > On Jan 24, 2021, at 8:32 PM, David Blaikie  wrote:
> >
> >
> >
> > On Fri, Jan 22, 2021 at 9:42 AM Jim Ingham  wrote:
> > If you are just loading an object file and the looking at the line table
> or something like that, would a UnitTest be more suitable?
> >
> > Maybe, though for what it's worth, this isn't an issue with the line
> table (well, not the .debug_line contents) as such - this is testing a
> change to .debug_info - specifically, the use of DW_AT_ranges on a
> DW_TAG_subprogram. But it manifested as breakpoints not having source
> information. I don't know a great deal about how the line table ended up
> interacting with the address ranges specified on the DW_TAG_subprogram, but
> it did in some way.
> >
> > Not sure if that is or isn't especially amenable to unit testing given
> the LLDB architecture of these components.
> >
> > - Dave
> >
> >
> > Jim
> >
> >
> > > On Jan 22, 2021, at 5:37 AM, Pavel Labath  wrote:
> > >
> > > On 19/01/2021 23:23, David Blaikie wrote:
> > >> On Tue, Jan 19, 2021 at 1:12 AM Pavel Labath  wrote:
> > >> Yeah - I have mixed feelings about debugger testing here - it is nice
> > >> to have end-to-end tests which makes for handy debugger testing
> > >> (though I guess in theory, debuginfo-tests is the place for
> > >> intentional end-to-end testing), though also being able to test
> > >> different features (DWARF version, split DWARF, dsym V object
> > >> debugging, etc) when they're written as end-to-end tests.
> > >
> > > Yeah, it would be nice if there was a clearer separation between the
> two categories. The current setup has evolved organically, as the
> end-to-end API tests used to be the only kinds of tests.
> > >
> > >
> > >> Can we write non-end-to-end API tests, then?
> > >
> > > Kind of. There is no fundamental reason why one couldn't run llvm-mc
> or whatever as a part of an API test. The main issue is that we don't have
> the infrastructure for that set up right now. I think the reason for that
> is that once you start dealing with "incomplete" executables which cannot
> be run on the host platform, the usefulness of interactivity goes down
> sharply. It is hard for such a test to do something other than load up some
> executable and query its state. This is a perfect use case for a shell test.
> > >
> > > There are exceptions though. For example we have a collection of "API"
> tests which test the gdb-remote communication layer, by mocking one end of
> the connection. Such tests are necessarily interactive, which is why they
> ended up in the API category, but they are definitely not end-to-end tests,
> and they either don't use any executables, or just use a static yaml2objed
> executable. This is why our API tests have the ability to run yaml2obj and
> one could add other llvm tools in a similar fashion.
> 

[Lldb-commits] [PATCH] D93951: [vscode] Improve runInTerminal and support linux

[walter erquinigo 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 rG0f0462cacf34: [vscode] Improve runInTerminal and support 
linux (authored by wallace).

Changed prior to commit:
  https://reviews.llvm.org/D93951?vs=315655&id=319090#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93951

Files:
  lldb/packages/Python/lldbsuite/test/tools/lldb-vscode/lldbvscode_testcase.py
  lldb/packages/Python/lldbsuite/test/tools/lldb-vscode/vscode.py
  lldb/test/API/tools/lldb-vscode/runInTerminal/TestVSCode_runInTerminal.py
  lldb/tools/lldb-vscode/CMakeLists.txt
  lldb/tools/lldb-vscode/FifoFiles.cpp
  lldb/tools/lldb-vscode/FifoFiles.h
  lldb/tools/lldb-vscode/JSONUtils.cpp
  lldb/tools/lldb-vscode/JSONUtils.h
  lldb/tools/lldb-vscode/Options.td
  lldb/tools/lldb-vscode/RunInTerminal.cpp
  lldb/tools/lldb-vscode/RunInTerminal.h
  lldb/tools/lldb-vscode/VSCode.h
  lldb/tools/lldb-vscode/lldb-vscode.cpp

Index: lldb/tools/lldb-vscode/lldb-vscode.cpp
===
--- lldb/tools/lldb-vscode/lldb-vscode.cpp
+++ lldb/tools/lldb-vscode/lldb-vscode.cpp
@@ -384,12 +384,7 @@
 break;
   case lldb::eStateSuspended:
 break;
-  case lldb::eStateStopped: {
-if (g_vsc.waiting_for_run_in_terminal) {
-  g_vsc.waiting_for_run_in_terminal = false;
-  g_vsc.request_in_terminal_cv.notify_one();
-}
-  }
+  case lldb::eStateStopped:
 // Only report a stopped event if the process was not restarted.
 if (!lldb::SBProcess::GetRestartedFromEvent(event)) {
   SendStdOutStdErr(process);
@@ -1457,47 +1452,64 @@
   g_vsc.SendJSON(llvm::json::Value(std::move(response)));
 }
 
-void request_runInTerminal(const llvm::json::Object &launch_request,
-   llvm::json::Object &launch_response) {
-  // We have already created a target that has a valid "program" path to the
-  // executable. We will attach to the next process whose name matches that
-  // of the target's.
+llvm::Error request_runInTerminal(const llvm::json::Object &launch_request) {
   g_vsc.is_attach = true;
   lldb::SBAttachInfo attach_info;
-  lldb::SBError error;
-  attach_info.SetWaitForLaunch(true, /*async*/ true);
-  g_vsc.target.Attach(attach_info, error);
 
-  llvm::json::Object reverse_request =
-  CreateRunInTerminalReverseRequest(launch_request);
+  llvm::Expected> comm_file_or_err =
+  CreateRunInTerminalCommFile();
+  if (!comm_file_or_err)
+return comm_file_or_err.takeError();
+  FifoFile &comm_file = *comm_file_or_err.get();
+
+  RunInTerminalDebugAdapterCommChannel comm_channel(comm_file.m_path);
+
+  llvm::json::Object reverse_request = CreateRunInTerminalReverseRequest(
+  launch_request, g_vsc.debug_adaptor_path, comm_file.m_path);
   llvm::json::Object reverse_response;
   lldb_vscode::PacketStatus status =
   g_vsc.SendReverseRequest(reverse_request, reverse_response);
   if (status != lldb_vscode::PacketStatus::Success)
-error.SetErrorString("Process cannot be launched by IDE.");
+return llvm::createStringError(llvm::inconvertibleErrorCode(),
+   "Process cannot be launched by the IDE. %s",
+   comm_channel.GetLauncherError().c_str());
 
-  if (error.Success()) {
-// Wait for the attach stop event to happen or for a timeout.
-g_vsc.waiting_for_run_in_terminal = true;
-static std::mutex mutex;
-std::unique_lock locker(mutex);
-g_vsc.request_in_terminal_cv.wait_for(locker, std::chrono::seconds(10));
+  if (llvm::Expected pid = comm_channel.GetLauncherPid())
+attach_info.SetProcessID(*pid);
+  else
+return pid.takeError();
 
-auto attached_pid = g_vsc.target.GetProcess().GetProcessID();
-if (attached_pid == LLDB_INVALID_PROCESS_ID)
-  error.SetErrorString("Failed to attach to a process");
-else
-  SendProcessEvent(Attach);
-  }
+  g_vsc.debugger.SetAsync(false);
+  lldb::SBError error;
+  g_vsc.target.Attach(attach_info, error);
 
-  if (error.Fail()) {
-launch_response["success"] = llvm::json::Value(false);
-EmplaceSafeString(launch_response, "message",
-  std::string(error.GetCString()));
-  } else {
-launch_response["success"] = llvm::json::Value(true);
-g_vsc.SendJSON(CreateEventObject("initialized"));
-  }
+  if (error.Fail())
+return llvm::createStringError(llvm::inconvertibleErrorCode(),
+   "Failed to attach to the target process. %s",
+   comm_channel.GetLauncherError().c_str());
+  // This will notify the runInTerminal launcher that we attached.
+  // We have to make this async, as the function won't return until the launcher
+  // resumes and

[Lldb-commits] [PATCH] D95164: Make SBDebugger::CreateTargetWithFileAndArch accept lldb.LLDB_DEFAULT_ARCH

[Jim Ingham via Phabricator via lldb-commits]

This revision was not accepted when it landed; it landed in state "Needs 
Review".
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rGf05dc40c31d1: Fix SBDebugger::CreateTargetWithFileAndArch to 
accept LLDB_ARCH_DEFAULT. (authored by jingham).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95164

Files:
  lldb/source/API/SBDebugger.cpp
  lldb/test/API/python_api/target/TestTargetAPI.py


Index: lldb/test/API/python_api/target/TestTargetAPI.py
===
--- lldb/test/API/python_api/target/TestTargetAPI.py
+++ lldb/test/API/python_api/target/TestTargetAPI.py
@@ -476,3 +476,15 @@
 desc2 = get_description(symbol2)
 self.assertTrue(desc1 and desc2 and desc1 == desc2,
 "The two addresses should resolve to the same symbol")
+def test_default_arch(self):
+""" Test the other two target create methods using LLDB_ARCH_DEFAULT. 
"""
+self.build()
+exe = self.getBuildArtifact("a.out")
+target = self.dbg.CreateTargetWithFileAndArch(exe, 
lldb.LLDB_ARCH_DEFAULT)
+self.assertTrue(target.IsValid(), "Default arch made a valid target.")
+# This should also work with the target's triple:
+target2 = self.dbg.CreateTargetWithFileAndArch(exe, target.GetTriple())
+self.assertTrue(target2.IsValid(), "Round trip with triple works")
+# And this triple should work for the FileAndTriple API:
+target3 = self.dbg.CreateTargetWithFileAndTargetTriple(exe, 
target.GetTriple())
+self.assertTrue(target3.IsValid())
Index: lldb/source/API/SBDebugger.cpp
===
--- lldb/source/API/SBDebugger.cpp
+++ lldb/source/API/SBDebugger.cpp
@@ -805,11 +805,13 @@
   if (m_opaque_sp) {
 Status error;
 const bool add_dependent_modules = true;
-
+PlatformSP platform_sp = 
m_opaque_sp->GetPlatformList().GetSelectedPlatform();
+ArchSpec arch = Platform::GetAugmentedArchSpec(
+platform_sp.get(), arch_cstr);
 error = m_opaque_sp->GetTargetList().CreateTarget(
-*m_opaque_sp, filename, arch_cstr,
-add_dependent_modules ? eLoadDependentsYes : eLoadDependentsNo, 
nullptr,
-target_sp);
+*m_opaque_sp, filename, arch,
+add_dependent_modules ? eLoadDependentsYes : eLoadDependentsNo, 
+platform_sp, target_sp);
 
 if (error.Success())
   sb_target.SetSP(target_sp);


Index: lldb/test/API/python_api/target/TestTargetAPI.py
===
--- lldb/test/API/python_api/target/TestTargetAPI.py
+++ lldb/test/API/python_api/target/TestTargetAPI.py
@@ -476,3 +476,15 @@
 desc2 = get_description(symbol2)
 self.assertTrue(desc1 and desc2 and desc1 == desc2,
 "The two addresses should resolve to the same symbol")
+def test_default_arch(self):
+""" Test the other two target create methods using LLDB_ARCH_DEFAULT. """
+self.build()
+exe = self.getBuildArtifact("a.out")
+target = self.dbg.CreateTargetWithFileAndArch(exe, lldb.LLDB_ARCH_DEFAULT)
+self.assertTrue(target.IsValid(), "Default arch made a valid target.")
+# This should also work with the target's triple:
+target2 = self.dbg.CreateTargetWithFileAndArch(exe, target.GetTriple())
+self.assertTrue(target2.IsValid(), "Round trip with triple works")
+# And this triple should work for the FileAndTriple API:
+target3 = self.dbg.CreateTargetWithFileAndTargetTriple(exe, target.GetTriple())
+self.assertTrue(target3.IsValid())
Index: lldb/source/API/SBDebugger.cpp
===
--- lldb/source/API/SBDebugger.cpp
+++ lldb/source/API/SBDebugger.cpp
@@ -805,11 +805,13 @@
   if (m_opaque_sp) {
 Status error;
 const bool add_dependent_modules = true;
-
+PlatformSP platform_sp = m_opaque_sp->GetPlatformList().GetSelectedPlatform();
+ArchSpec arch = Platform::GetAugmentedArchSpec(
+platform_sp.get(), arch_cstr);
 error = m_opaque_sp->GetTargetList().CreateTarget(
-*m_opaque_sp, filename, arch_cstr,
-add_dependent_modules ? eLoadDependentsYes : eLoadDependentsNo, nullptr,
-target_sp);
+*m_opaque_sp, filename, arch,
+add_dependent_modules ? eLoadDependentsYes : eLoadDependentsNo, 
+platform_sp, target_sp);
 
 if (error.Success())
   sb_target.SetSP(target_sp);
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D93649: [lldb/Lua] add support for Lua function breakpoint

[Jonas Devlieghere via Phabricator via lldb-commits]

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

LGTM




Comment at: 
lldb/test/Shell/ScriptInterpreter/Lua/breakpoint_function_callback.test:15
+r
+# CHECK: 
+breakpoint command add -s lua -o "abc(frame, bp_loc, ...)"

tammela wrote:
> JDevlieghere wrote:
> > Can we unpack the SBStructuredData and check for `foo` or `123` in the 
> > output?
> While I was doing this change, I noted that the `SBStructuredData` API for 
> `GetStringValue` is quite odd.
> For Lua, the auto-generated SWIG wrapper enforces code like this:
> ```
> local result = ""
> sd:GetStringValue(result, 3) -- 'sd' should be a value with at most 3 
> characters
> ```
> This sort of API leaks all sorts of details to the Lua script. I think it 
> could be improved to just return a `std::string` / `llvm::StringRef` object.
> 
> The SWIG wrapper also has some bugs for this class. For instance it's using 
> `lua_pushnumber` where it should be `lua_pushinteger` for the 
> `GetIntegerValue` method.
> 
> I will report this to the SWIG authors.
I still think this is important. Can you add a FIXME so we remember update this 
in the future? 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93649

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

[Lldb-commits] [PATCH] D93951: [vscode] Improve runInTerminal and support linux

[Stella Stamenova via Phabricator via lldb-commits]

stella.stamenova added a comment.

It looks like this broke the windows lldb bot:


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93951

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

[Lldb-commits] [PATCH] D95297: [lldb] [Process/FreeBSDRemote] Introduce arm64 support

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

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

Removed unused `REG_CONTEXT_SIZE`.


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

https://reviews.llvm.org/D95297

Files:
  lldb/source/Plugins/Platform/FreeBSD/PlatformFreeBSD.cpp
  lldb/source/Plugins/Process/FreeBSDRemote/CMakeLists.txt
  
lldb/source/Plugins/Process/FreeBSDRemote/NativeRegisterContextFreeBSD_arm64.cpp
  lldb/source/Plugins/Process/FreeBSDRemote/NativeRegisterContextFreeBSD_arm64.h
  lldb/unittests/Process/Utility/RegisterContextFreeBSDTest.cpp

Index: lldb/unittests/Process/Utility/RegisterContextFreeBSDTest.cpp
===
--- lldb/unittests/Process/Utility/RegisterContextFreeBSDTest.cpp
+++ lldb/unittests/Process/Utility/RegisterContextFreeBSDTest.cpp
@@ -17,6 +17,8 @@
 #include "Plugins/Process/Utility/lldb-x86-register-enums.h"
 #include "Plugins/Process/Utility/RegisterContextFreeBSD_i386.h"
 #include "Plugins/Process/Utility/RegisterContextFreeBSD_x86_64.h"
+#include "Plugins/Process/Utility/RegisterInfoPOSIX_arm64.h"
+#include "Plugins/Process/Utility/lldb-arm64-register-enums.h"
 
 using namespace lldb;
 using namespace lldb_private;
@@ -231,3 +233,92 @@
 }
 
 #endif // defined(__i386__) || defined(__x86_64__)
+
+#if defined(__aarch64__)
+
+#define EXPECT_GPR_ARM64(lldb_reg, fbsd_reg)   \
+  EXPECT_THAT(GetRegParams(reg_ctx, gpr_##lldb_reg##_arm64),   \
+  ::testing::Pair(offsetof(reg, fbsd_reg), sizeof(reg::fbsd_reg)))
+#define EXPECT_FPU_ARM64(lldb_reg, fbsd_reg)   \
+  EXPECT_THAT(GetRegParams(reg_ctx, fpu_##lldb_reg##_arm64),   \
+  ::testing::Pair(offsetof(fpreg, fbsd_reg) + base_offset, \
+  sizeof(fpreg::fbsd_reg)))
+
+TEST(RegisterContextFreeBSDTest, arm64) {
+  ArchSpec arch{"aarch64-unknown-freebsd"};
+  RegisterInfoPOSIX_arm64 reg_ctx{arch};
+
+  EXPECT_GPR_ARM64(x0, x[0]);
+  EXPECT_GPR_ARM64(x1, x[1]);
+  EXPECT_GPR_ARM64(x2, x[2]);
+  EXPECT_GPR_ARM64(x3, x[3]);
+  EXPECT_GPR_ARM64(x4, x[4]);
+  EXPECT_GPR_ARM64(x5, x[5]);
+  EXPECT_GPR_ARM64(x6, x[6]);
+  EXPECT_GPR_ARM64(x7, x[7]);
+  EXPECT_GPR_ARM64(x8, x[8]);
+  EXPECT_GPR_ARM64(x9, x[9]);
+  EXPECT_GPR_ARM64(x10, x[10]);
+  EXPECT_GPR_ARM64(x11, x[11]);
+  EXPECT_GPR_ARM64(x12, x[12]);
+  EXPECT_GPR_ARM64(x13, x[13]);
+  EXPECT_GPR_ARM64(x14, x[14]);
+  EXPECT_GPR_ARM64(x15, x[15]);
+  EXPECT_GPR_ARM64(x16, x[16]);
+  EXPECT_GPR_ARM64(x17, x[17]);
+  EXPECT_GPR_ARM64(x18, x[18]);
+  EXPECT_GPR_ARM64(x19, x[19]);
+  EXPECT_GPR_ARM64(x20, x[20]);
+  EXPECT_GPR_ARM64(x21, x[21]);
+  EXPECT_GPR_ARM64(x22, x[22]);
+  EXPECT_GPR_ARM64(x23, x[23]);
+  EXPECT_GPR_ARM64(x24, x[24]);
+  EXPECT_GPR_ARM64(x25, x[25]);
+  EXPECT_GPR_ARM64(x26, x[26]);
+  EXPECT_GPR_ARM64(x27, x[27]);
+  EXPECT_GPR_ARM64(x28, x[28]);
+  EXPECT_GPR_ARM64(fp, x[29]);
+  EXPECT_GPR_ARM64(lr, lr);
+  EXPECT_GPR_ARM64(sp, sp);
+  EXPECT_GPR_ARM64(pc, elr);
+  EXPECT_GPR_ARM64(cpsr, spsr);
+
+  size_t base_offset = reg_ctx.GetRegisterInfo()[fpu_v0_arm64].byte_offset;
+
+  EXPECT_FPU_ARM64(v0, fp_q[0]);
+  EXPECT_FPU_ARM64(v1, fp_q[1]);
+  EXPECT_FPU_ARM64(v2, fp_q[2]);
+  EXPECT_FPU_ARM64(v3, fp_q[3]);
+  EXPECT_FPU_ARM64(v4, fp_q[4]);
+  EXPECT_FPU_ARM64(v5, fp_q[5]);
+  EXPECT_FPU_ARM64(v6, fp_q[6]);
+  EXPECT_FPU_ARM64(v7, fp_q[7]);
+  EXPECT_FPU_ARM64(v8, fp_q[8]);
+  EXPECT_FPU_ARM64(v9, fp_q[9]);
+  EXPECT_FPU_ARM64(v10, fp_q[10]);
+  EXPECT_FPU_ARM64(v11, fp_q[11]);
+  EXPECT_FPU_ARM64(v12, fp_q[12]);
+  EXPECT_FPU_ARM64(v13, fp_q[13]);
+  EXPECT_FPU_ARM64(v14, fp_q[14]);
+  EXPECT_FPU_ARM64(v15, fp_q[15]);
+  EXPECT_FPU_ARM64(v16, fp_q[16]);
+  EXPECT_FPU_ARM64(v17, fp_q[17]);
+  EXPECT_FPU_ARM64(v18, fp_q[18]);
+  EXPECT_FPU_ARM64(v19, fp_q[19]);
+  EXPECT_FPU_ARM64(v20, fp_q[20]);
+  EXPECT_FPU_ARM64(v21, fp_q[21]);
+  EXPECT_FPU_ARM64(v22, fp_q[22]);
+  EXPECT_FPU_ARM64(v23, fp_q[23]);
+  EXPECT_FPU_ARM64(v24, fp_q[24]);
+  EXPECT_FPU_ARM64(v25, fp_q[25]);
+  EXPECT_FPU_ARM64(v26, fp_q[26]);
+  EXPECT_FPU_ARM64(v27, fp_q[27]);
+  EXPECT_FPU_ARM64(v28, fp_q[28]);
+  EXPECT_FPU_ARM64(v29, fp_q[29]);
+  EXPECT_FPU_ARM64(v30, fp_q[30]);
+  EXPECT_FPU_ARM64(v31, fp_q[31]);
+  EXPECT_FPU_ARM64(fpsr, fp_sr);
+  EXPECT_FPU_ARM64(fpcr, fp_cr);
+}
+
+#endif // defined(__aarch64__)
Index: lldb/source/Plugins/Process/FreeBSDRemote/NativeRegisterContextFreeBSD_arm64.h
===
--- /dev/null
+++ lldb/source/Plugins/Process/FreeBSDRemote/NativeRegisterContextFreeBSD_arm64.h
@@ -0,0 +1,75 @@
+//===-- NativeRegisterContextFreeBSD_arm64.h *- C++ -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===

Re: [Lldb-commits] [PATCH] D93951: [vscode] Improve runInTerminal and support linux

[Walter via lldb-commits]

I've already submitted a fix, let's see if the buildbot gets fixed

Il giorno lun 25 gen 2021 alle ore 14:18 Stella Stamenova via Phabricator <
revi...@reviews.llvm.org> ha scritto:

> stella.stamenova added a comment.
>
> It looks like this broke the windows lldb bot:
>
>
> Repository:
>   rG LLVM Github Monorepo
>
> CHANGES SINCE LAST ACTION
>   https://reviews.llvm.org/D93951/new/
>
> https://reviews.llvm.org/D93951
>
>

-- 
- Walter Erquínigo Pezo
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D93649: [lldb/Lua] add support for Lua function breakpoint

[Pedro Tammela 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 rG532e4203c5be: [lldb/Lua] add support for Lua function 
breakpoint (authored by tammela).

Changed prior to commit:
  https://reviews.llvm.org/D93649?vs=318775&id=319148#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93649

Files:
  lldb/bindings/lua/lua-swigsafecast.swig
  lldb/bindings/lua/lua-typemaps.swig
  lldb/bindings/lua/lua-wrapper.swig
  lldb/source/Plugins/ScriptInterpreter/Lua/Lua.cpp
  lldb/source/Plugins/ScriptInterpreter/Lua/Lua.h
  lldb/source/Plugins/ScriptInterpreter/Lua/ScriptInterpreterLua.cpp
  lldb/source/Plugins/ScriptInterpreter/Lua/ScriptInterpreterLua.h
  lldb/test/Shell/ScriptInterpreter/Lua/breakpoint_function_callback.test
  lldb/unittests/ScriptInterpreter/Lua/LuaTests.cpp

Index: lldb/unittests/ScriptInterpreter/Lua/LuaTests.cpp
===
--- lldb/unittests/ScriptInterpreter/Lua/LuaTests.cpp
+++ lldb/unittests/ScriptInterpreter/Lua/LuaTests.cpp
@@ -24,10 +24,9 @@
 #pragma warning (disable : 4190)
 #endif
 
-extern "C" llvm::Expected
-LLDBSwigLuaBreakpointCallbackFunction(lua_State *L,
-  lldb::StackFrameSP stop_frame_sp,
-  lldb::BreakpointLocationSP bp_loc_sp) {
+extern "C" llvm::Expected LLDBSwigLuaBreakpointCallbackFunction(
+lua_State *L, lldb::StackFrameSP stop_frame_sp,
+lldb::BreakpointLocationSP bp_loc_sp, StructuredDataImpl *extra_args_impl) {
   return false;
 }
 
Index: lldb/test/Shell/ScriptInterpreter/Lua/breakpoint_function_callback.test
===
--- /dev/null
+++ lldb/test/Shell/ScriptInterpreter/Lua/breakpoint_function_callback.test
@@ -0,0 +1,23 @@
+# REQUIRES: lua
+# RUN: echo "int main() { return 0; }" | %clang_host -x c - -o %t
+# RUN: %lldb -s %s --script-language lua %t 2>&1 | FileCheck %s
+b main
+script
+function abc(a, b, c, ...)
+print(c)
+if c then print(c:GetValueForKey("foo"):GetStringValue(32)) end
+end
+quit
+breakpoint command add -s lua -F abc
+r
+# CHECK: nil
+breakpoint command add -s lua -F abc -k foo -v 123pizza!
+r
+# CHECK: 
+# CHECK: 123pizza!
+breakpoint command add -s lua -o "abc(frame, bp_loc, ...)"
+r
+# CHECK: nil
+breakpoint command add -s lua -F typo
+r
+# CHECK: attempt to call a nil value
Index: lldb/source/Plugins/ScriptInterpreter/Lua/ScriptInterpreterLua.h
===
--- lldb/source/Plugins/ScriptInterpreter/Lua/ScriptInterpreterLua.h
+++ lldb/source/Plugins/ScriptInterpreter/Lua/ScriptInterpreterLua.h
@@ -9,6 +9,7 @@
 #ifndef liblldb_ScriptInterpreterLua_h_
 #define liblldb_ScriptInterpreterLua_h_
 
+#include "lldb/Core/StructuredDataImpl.h"
 #include "lldb/Interpreter/ScriptInterpreter.h"
 #include "lldb/Utility/Status.h"
 #include "lldb/lldb-enumerations.h"
@@ -22,6 +23,11 @@
 CommandDataLua() : BreakpointOptions::CommandData() {
   interpreter = lldb::eScriptLanguageLua;
 }
+CommandDataLua(StructuredData::ObjectSP extra_args_sp)
+: BreakpointOptions::CommandData(), m_extra_args_sp(extra_args_sp) {
+  interpreter = lldb::eScriptLanguageLua;
+}
+StructuredData::ObjectSP m_extra_args_sp;
   };
 
   ScriptInterpreterLua(Debugger &debugger);
@@ -72,9 +78,17 @@
   Status SetBreakpointCommandCallback(BreakpointOptions *bp_options,
   const char *command_body_text) override;
 
+  Status SetBreakpointCommandCallbackFunction(
+  BreakpointOptions *bp_options, const char *function_name,
+  StructuredData::ObjectSP extra_args_sp) override;
+
 private:
   std::unique_ptr m_lua;
   bool m_session_is_active = false;
+
+  Status RegisterBreakpointCallback(BreakpointOptions *bp_options,
+const char *command_body_text,
+StructuredData::ObjectSP extra_args_sp);
 };
 
 } // namespace lldb_private
Index: lldb/source/Plugins/ScriptInterpreter/Lua/ScriptInterpreterLua.cpp
===
--- lldb/source/Plugins/ScriptInterpreter/Lua/ScriptInterpreterLua.cpp
+++ lldb/source/Plugins/ScriptInterpreter/Lua/ScriptInterpreterLua.cpp
@@ -264,8 +264,9 @@
   debugger.GetScriptInterpreter(true, eScriptLanguageLua));
   Lua &lua = lua_interpreter->GetLua();
 
-  llvm::Expected BoolOrErr =
-  lua.CallBreakpointCallback(baton, stop_frame_sp, bp_loc_sp);
+  CommandDataLua *bp_option_data = static_cast(baton);
+  llvm::Expected BoolOrErr = lua.CallBreakpointCallback(
+  baton, stop_frame_sp, bp_loc_sp, bp_option_data->m_extra_args_sp);
   if (llvm::Error E = BoolOrErr.takeError()) {
 debugger.GetErrorStream() << toString(std::move(E));
 return true;
@@ -283

[Lldb-commits] [PATCH] D92957: ExpressionParser: Migrate to FileEntryRef in ParseInternal, NFC

[Duncan P. N. Exon Smith 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 rG8b6aedc4c99a: ExpressionParser: Migrate to FileEntryRef in 
ParseInternal, NFC (authored by dexonsmith).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92957

Files:
  lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp


Index: lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
===
--- lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
+++ lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
@@ -1073,8 +1073,8 @@
   if (file.Write(expr_text, bytes_written).Success()) {
 if (bytes_written == expr_text_len) {
   file.Close();
-  if (auto fileEntry =
-  m_compiler->getFileManager().getFile(result_path)) {
+  if (auto fileEntry = m_compiler->getFileManager().getOptionalFileRef(
+  result_path)) {
 source_mgr.setMainFileID(source_mgr.createFileID(
 *fileEntry,
 SourceLocation(), SrcMgr::C_User));


Index: lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
===
--- lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
+++ lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
@@ -1073,8 +1073,8 @@
   if (file.Write(expr_text, bytes_written).Success()) {
 if (bytes_written == expr_text_len) {
   file.Close();
-  if (auto fileEntry =
-  m_compiler->getFileManager().getFile(result_path)) {
+  if (auto fileEntry = m_compiler->getFileManager().getOptionalFileRef(
+  result_path)) {
 source_mgr.setMainFileID(source_mgr.createFileID(
 *fileEntry,
 SourceLocation(), SrcMgr::C_User));
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D95411: [lldb] Remove unused ThreadPlanStack::GetStackOfKind (NFC)

[Dave Lee via Phabricator via lldb-commits]

kastiglione created this revision.
kastiglione added a reviewer: jingham.
kastiglione requested review of this revision.
Herald added a project: LLDB.
Herald added a subscriber: lldb-commits.

This function isn't used.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D95411

Files:
  lldb/include/lldb/Target/ThreadPlanStack.h
  lldb/source/Target/ThreadPlanStack.cpp


Index: lldb/source/Target/ThreadPlanStack.cpp
===
--- lldb/source/Target/ThreadPlanStack.cpp
+++ lldb/source/Target/ThreadPlanStack.cpp
@@ -379,19 +379,6 @@
   m_discarded_plans.clear();
 }
 
-const ThreadPlanStack::PlanStack &
-ThreadPlanStack::GetStackOfKind(ThreadPlanStack::StackKind kind) const {
-  switch (kind) {
-  case ePlans:
-return m_plans;
-  case eCompletedPlans:
-return m_completed_plans;
-  case eDiscardedPlans:
-return m_discarded_plans;
-  }
-  llvm_unreachable("Invalid StackKind value");
-}
-
 void ThreadPlanStackMap::Update(ThreadList ¤t_threads,
 bool delete_missing,
 bool check_for_new) {
Index: lldb/include/lldb/Target/ThreadPlanStack.h
===
--- lldb/include/lldb/Target/ThreadPlanStack.h
+++ lldb/include/lldb/Target/ThreadPlanStack.h
@@ -35,8 +35,6 @@
   ThreadPlanStack(const Thread &thread, bool make_empty = false);
   ~ThreadPlanStack() {}
 
-  enum StackKind { ePlans, eCompletedPlans, eDiscardedPlans };
-
   using PlanStack = std::vector;
 
   void DumpThreadPlans(Stream &s, lldb::DescriptionLevel desc_level,
@@ -102,8 +100,6 @@
   void ClearThreadCache();
 
 private:
-  const PlanStack &GetStackOfKind(ThreadPlanStack::StackKind kind) const;
-
   void PrintOneStack(Stream &s, llvm::StringRef stack_name,
  const PlanStack &stack, lldb::DescriptionLevel desc_level,
  bool include_internal) const;


Index: lldb/source/Target/ThreadPlanStack.cpp
===
--- lldb/source/Target/ThreadPlanStack.cpp
+++ lldb/source/Target/ThreadPlanStack.cpp
@@ -379,19 +379,6 @@
   m_discarded_plans.clear();
 }
 
-const ThreadPlanStack::PlanStack &
-ThreadPlanStack::GetStackOfKind(ThreadPlanStack::StackKind kind) const {
-  switch (kind) {
-  case ePlans:
-return m_plans;
-  case eCompletedPlans:
-return m_completed_plans;
-  case eDiscardedPlans:
-return m_discarded_plans;
-  }
-  llvm_unreachable("Invalid StackKind value");
-}
-
 void ThreadPlanStackMap::Update(ThreadList ¤t_threads,
 bool delete_missing,
 bool check_for_new) {
Index: lldb/include/lldb/Target/ThreadPlanStack.h
===
--- lldb/include/lldb/Target/ThreadPlanStack.h
+++ lldb/include/lldb/Target/ThreadPlanStack.h
@@ -35,8 +35,6 @@
   ThreadPlanStack(const Thread &thread, bool make_empty = false);
   ~ThreadPlanStack() {}
 
-  enum StackKind { ePlans, eCompletedPlans, eDiscardedPlans };
-
   using PlanStack = std::vector;
 
   void DumpThreadPlans(Stream &s, lldb::DescriptionLevel desc_level,
@@ -102,8 +100,6 @@
   void ClearThreadCache();
 
 private:
-  const PlanStack &GetStackOfKind(ThreadPlanStack::StackKind kind) const;
-
   void PrintOneStack(Stream &s, llvm::StringRef stack_name,
  const PlanStack &stack, lldb::DescriptionLevel desc_level,
  bool include_internal) const;
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D95411: [lldb] Remove unused ThreadPlanStack::GetStackOfKind (NFC)

[Jim Ingham via Phabricator via lldb-commits]

jingham accepted this revision.
jingham added a comment.
This revision is now accepted and ready to land.
Herald added a subscriber: JDevlieghere.

The inverse change to this would be to have all the places where we ask 
questions about the PlanStacks in a ThreadPlanStack through this API.  I put it 
in to add that abstraction layer, but I don't remember why I thought it might 
be useful, and I never found any actual motivation for it.  So this can go.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95411

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

[Lldb-commits] [PATCH] D95164: Make SBDebugger::CreateTargetWithFileAndArch accept lldb.LLDB_DEFAULT_ARCH

[Richard Smith - zygoloid via Phabricator via lldb-commits]

rsmith added a comment.

I reverted this and the follow-up fix in 
rG8b1171488575bd0b5ccb23bc1a3d22e2aaccb244 
, because 
it's introduced several test failures. Example: 
http://lab.llvm.org:8011/#/builders/96/builds/3777

It appears that these tests use `CreateTargetWithFileAndArch(None, None)`, 
which worked before these changes and not afterwards.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95164

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