[Lldb-commits] [PATCH] D46726: build: use cmake to find the libedit content

2018-05-22 Thread Pavel Labath via Phabricator via lldb-commits 
labath accepted this revision.
labath added a comment.
This revision is now accepted and ready to land.

Ok, let's give this a try.


https://reviews.llvm.org/D46726



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

Re: [Lldb-commits] [lldb] r332922 - Work around some odd instruction single-step behavior on macOS.

2018-05-22 Thread Pavel Labath via lldb-commits 
This probably isn't what was happening here because you would have seen the
extra stops in the logs, but one way I can think of we can end up at the
same PC is if the process gets a signal while we're about to single-step
it, in which case we need to execute the signal handler first and then get
back to the instruction we were about to step over.

Anyway, the reason I am writing this is the testing situation. I think we
already have something that should be able to mock a process to a
sufficient level to test behavior like this: MockGdbServer in
testcases/functionalities/gdb_remote_client. So, I believe it should be
possible to trigger this via a sequence like:
- connect to mock server (server pretends to be stopped at PC 0x1000)
- breakpoint set --address 0x1010
- continue (server pretends to stop at 0x1010)
- continue (after the first $s packet, server stays at 0x1010, after the
second one it advances to 0x1011, after the final $c, return W00)
- verify the expected packets were sent

Have you tried using MockGdbServer in this way?

regards,
pl

On Tue, 22 May 2018 at 01:10, Jim Ingham via lldb-commits <
lldb-commits@lists.llvm.org> wrote:

> Author: jingham
> Date: Mon May 21 17:06:55 2018
> New Revision: 332922

> URL: http://llvm.org/viewvc/llvm-project?rev=332922&view=rev
> Log:
> Work around some odd instruction single-step behavior on macOS.

> We've seen some cases on macOS where you go to instruction single
> step (over a breakpoint), and single step returns but the instruction
> hasn't been executed (and the pc hasn't moved.)  The
ThreadPlanStepOverBreakpoint
> used to handle this case by accident, but the patches to handle two
adjacent
> breakpoints broke that accident.

> This patch fixes the logic of ExplainsStop to explicitly handle the case
where
> the pc didn't move.  It also adds a WillPop that re-enables the
breakpoint we
> were stepping over.  We never want an unexpected path through the plan to
> fool us into not doing that.

> I have no idea how to make this bug happen.  It is very inconsistent when
it
> occurs IRL.  We really need a full MockProcess Plugin before we can start
to write
> tests for this sort of system hiccup.

> 

> Modified:
>  lldb/trunk/include/lldb/Target/ThreadPlanStepOverBreakpoint.h
>  lldb/trunk/lldb.xcodeproj/xcshareddata/xcschemes/desktop.xcscheme
>  lldb/trunk/source/Target/ThreadPlanStepOverBreakpoint.cpp

> Modified: lldb/trunk/include/lldb/Target/ThreadPlanStepOverBreakpoint.h
> URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Target/ThreadPlanStepOverBreakpoint.h?rev=332922&r1=332921&r2=332922&view=diff

==
> --- lldb/trunk/include/lldb/Target/ThreadPlanStepOverBreakpoint.h
(original)
> +++ lldb/trunk/include/lldb/Target/ThreadPlanStepOverBreakpoint.h Mon May
21 17:06:55 2018
> @@ -31,6 +31,7 @@ public:
> bool StopOthers() override;
> lldb::StateType GetPlanRunState() override;
> bool WillStop() override;
> +  void WillPop() override;
> bool MischiefManaged() override;
> void ThreadDestroyed() override;
> void SetAutoContinue(bool do_it);

> Modified:
lldb/trunk/lldb.xcodeproj/xcshareddata/xcschemes/desktop.xcscheme
> URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/lldb.xcodeproj/xcshareddata/xcschemes/desktop.xcscheme?rev=332922&r1=332921&r2=332922&view=diff

==
> --- lldb/trunk/lldb.xcodeproj/xcshareddata/xcschemes/desktop.xcscheme
(original)
> +++ lldb/trunk/lldb.xcodeproj/xcshareddata/xcschemes/desktop.xcscheme Mon
May 21 17:06:55 2018
> @@ -26,10 +26,18 @@
> buildConfiguration = "Debug"
> selectedDebuggerIdentifier =
"Xcode.DebuggerFoundation.Debugger.LLDB"
> selectedLauncherIdentifier =
"Xcode.DebuggerFoundation.Launcher.LLDB"
> -  language = ""
> shouldUseLaunchSchemeArgsEnv = "YES">
> 
> 
> +  
> +  +BuildableIdentifier = "primary"
> +BlueprintIdentifier = "26F5C26910F3D9A4009D5894"
> +BuildableName = "lldb"
> +BlueprintName = "lldb-tool"
> +ReferencedContainer = "container:lldb.xcodeproj">
> + 
> +  
> 
> 
>  
> @@ -37,22 +45,22 @@
> buildConfiguration = "DebugClang"
> selectedDebuggerIdentifier =
"Xcode.DebuggerFoundation.Debugger.LLDB"
> selectedLauncherIdentifier =
"Xcode.DebuggerFoundation.Launcher.LLDB"
> -  language = ""
> -  launchStyle = "0"
> +  launchStyle = "1"
> useCustomWorkingDirectory = "NO"
> ignoresPersistentStateOnLaunch = "NO"
> debugDocumentVersioning = "YES"
> debugServiceExtension = "internal"
> allowLocationSimulation = "YES">
> -  
> +   + runnableDebuggingMode = "0">
>   BuildableIdentifier = "primary"
> -BlueprintIdentifier = "26CEF3B114F

[Lldb-commits] [PATCH] D47147: DWARFIndex: Reduce duplication in the GetFunctions methods

2018-05-22 Thread Pavel Labath via Phabricator via lldb-commits 
labath added a comment.

Changing the code to filter based on the dwarf information instead of the going 
through CompilerDeclContexts sounds like a good idea. I've been wondering why 
we are doing it this way -- the explanation I gave to myself was that this 
would allow the individual language plugins to decide what represents a "class" 
instead of just searching for DW_TAG_structure_type and similar. However, it's 
very likely that this is extra flexibility we don't need (and indeed, the 
manual index just checks the dwarf tags while building the index).

Unfortunately, something's come up, so I wasn't able to look into this closer 
today. Hopefully, I'll be able to get back to this patch later this week.


https://reviews.llvm.org/D47147



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

[Lldb-commits] [lldb] r332997 - Enable ProcessMachCore plugin on non-apple platforms

2018-05-22 Thread Pavel Labath via lldb-commits 
Author: labath
Date: Tue May 22 09:33:43 2018
New Revision: 332997

URL: http://llvm.org/viewvc/llvm-project?rev=332997&view=rev
Log:
Enable ProcessMachCore plugin on non-apple platforms

Summary:
The plugin already builds fine on other platforms (linux, at least). All
that was necessary was to revitalize the hack in PlatformDarwinKernel
(not a very pretty hack, but it gets us going at least).

I haven't done a thorough investigation of the state of the plugin on
other platforms, but at least the two core file tests we have seem to
pass, so I enable them.

Reviewers: JDevlieghere, jasonmolenda

Subscribers: lldb-commits, mgorny

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

Modified:

lldb/trunk/packages/Python/lldbsuite/test/functionalities/postmortem/mach-core/TestMachCore.py

lldb/trunk/packages/Python/lldbsuite/test/functionalities/source-map/TestTargetSourceMap.py
lldb/trunk/source/API/SystemInitializerFull.cpp
lldb/trunk/source/Plugins/DynamicLoader/CMakeLists.txt
lldb/trunk/source/Plugins/Platform/MacOSX/PlatformDarwinKernel.h
lldb/trunk/source/Plugins/Process/CMakeLists.txt

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/postmortem/mach-core/TestMachCore.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/postmortem/mach-core/TestMachCore.py?rev=332997&r1=332996&r2=332997&view=diff
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/postmortem/mach-core/TestMachCore.py
 (original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/postmortem/mach-core/TestMachCore.py
 Tue May 22 09:33:43 2018
@@ -26,7 +26,6 @@ class MachCoreTestCase(TestBase):
 lldb.DBG.SetSelectedPlatform(self._initial_platform)
 super(MachCoreTestCase, self).tearDown()
 
-@skipUnlessDarwin
 def test_selected_thread(self):
 """Test that the right thread is selected after a core is loaded."""
 # Create core form YAML.

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/source-map/TestTargetSourceMap.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/source-map/TestTargetSourceMap.py?rev=332997&r1=332996&r2=332997&view=diff
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/source-map/TestTargetSourceMap.py
 (original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/source-map/TestTargetSourceMap.py
 Tue May 22 09:33:43 2018
@@ -7,7 +7,6 @@ class TestTargetSourceMap(TestBase):
 
 mydir = TestBase.compute_mydir(__file__)
 
-@skipUnlessDarwin
 @no_debug_info_test
 def test_source_map(self):
 """Test target.source-map' functionality."""

Modified: lldb/trunk/source/API/SystemInitializerFull.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/API/SystemInitializerFull.cpp?rev=332997&r1=332996&r2=332997&view=diff
==
--- lldb/trunk/source/API/SystemInitializerFull.cpp (original)
+++ lldb/trunk/source/API/SystemInitializerFull.cpp Tue May 22 09:33:43 2018
@@ -84,6 +84,7 @@
 #include "Plugins/Platform/gdb-server/PlatformRemoteGDBServer.h"
 #include "Plugins/Process/elf-core/ProcessElfCore.h"
 #include "Plugins/Process/gdb-remote/ProcessGDBRemote.h"
+#include "Plugins/Process/mach-core/ProcessMachCore.h"
 #include "Plugins/Process/minidump/ProcessMinidump.h"
 #include "Plugins/ScriptInterpreter/None/ScriptInterpreterNone.h"
 #include "Plugins/SymbolFile/DWARF/SymbolFileDWARF.h"
@@ -104,7 +105,6 @@
 #include "Plugins/Platform/MacOSX/PlatformRemoteAppleWatch.h"
 #include "Plugins/Platform/MacOSX/PlatformiOSSimulator.h"
 #include "Plugins/Process/MacOSX-Kernel/ProcessKDP.h"
-#include "Plugins/Process/mach-core/ProcessMachCore.h"
 #include "Plugins/SymbolVendor/MacOSX/SymbolVendorMacOSX.h"
 #endif
 #include "Plugins/StructuredData/DarwinLog/StructuredDataDarwinLog.h"
@@ -313,6 +313,7 @@ void SystemInitializerFull::Initialize()
 
   JITLoaderGDB::Initialize();
   ProcessElfCore::Initialize();
+  ProcessMachCore::Initialize();
   minidump::ProcessMinidump::Initialize();
   MemoryHistoryASan::Initialize();
   AddressSanitizerRuntime::Initialize();
@@ -353,7 +354,6 @@ void SystemInitializerFull::Initialize()
 #if defined(__APPLE__)
   SymbolVendorMacOSX::Initialize();
   ProcessKDP::Initialize();
-  ProcessMachCore::Initialize();
   PlatformAppleTVSimulator::Initialize();
   PlatformAppleWatchSimulator::Initialize();
   PlatformRemoteAppleTV::Initialize();
@@ -440,6 +440,7 @@ void SystemInitializerFull::Terminate()
 
   JITLoaderGDB::Terminate();
   ProcessElfCore::Terminate();
+  ProcessMachCore::Terminate();
   minidump::ProcessMinidump::Terminate();
   MemoryHistoryASan::Terminate();
   AddressSanitizerRuntime::Terminat

Re: [Lldb-commits] [lldb] r332922 - Work around some odd instruction single-step behavior on macOS.

2018-05-22 Thread Jim Ingham via lldb-commits 
I haven't played around with this yet.  Can it also provide enough memory to 
pretend a stack trace?  Most of the thread plan stuff will fall over pretty 
early if it doesn't have at least a couple of frames?

Jim


> On May 22, 2018, at 2:41 AM, Pavel Labath  wrote:
> 
> This probably isn't what was happening here because you would have seen the
> extra stops in the logs, but one way I can think of we can end up at the
> same PC is if the process gets a signal while we're about to single-step
> it, in which case we need to execute the signal handler first and then get
> back to the instruction we were about to step over.
> 
> Anyway, the reason I am writing this is the testing situation. I think we
> already have something that should be able to mock a process to a
> sufficient level to test behavior like this: MockGdbServer in
> testcases/functionalities/gdb_remote_client. So, I believe it should be
> possible to trigger this via a sequence like:
> - connect to mock server (server pretends to be stopped at PC 0x1000)
> - breakpoint set --address 0x1010
> - continue (server pretends to stop at 0x1010)
> - continue (after the first $s packet, server stays at 0x1010, after the
> second one it advances to 0x1011, after the final $c, return W00)
> - verify the expected packets were sent
> 
> Have you tried using MockGdbServer in this way?
> 
> regards,
> pl
> 
> On Tue, 22 May 2018 at 01:10, Jim Ingham via lldb-commits <
> lldb-commits@lists.llvm.org> wrote:
> 
>> Author: jingham
>> Date: Mon May 21 17:06:55 2018
>> New Revision: 332922
> 
>> URL: http://llvm.org/viewvc/llvm-project?rev=332922&view=rev
>> Log:
>> Work around some odd instruction single-step behavior on macOS.
> 
>> We've seen some cases on macOS where you go to instruction single
>> step (over a breakpoint), and single step returns but the instruction
>> hasn't been executed (and the pc hasn't moved.)  The
> ThreadPlanStepOverBreakpoint
>> used to handle this case by accident, but the patches to handle two
> adjacent
>> breakpoints broke that accident.
> 
>> This patch fixes the logic of ExplainsStop to explicitly handle the case
> where
>> the pc didn't move.  It also adds a WillPop that re-enables the
> breakpoint we
>> were stepping over.  We never want an unexpected path through the plan to
>> fool us into not doing that.
> 
>> I have no idea how to make this bug happen.  It is very inconsistent when
> it
>> occurs IRL.  We really need a full MockProcess Plugin before we can start
> to write
>> tests for this sort of system hiccup.
> 
>> 
> 
>> Modified:
>> lldb/trunk/include/lldb/Target/ThreadPlanStepOverBreakpoint.h
>> lldb/trunk/lldb.xcodeproj/xcshareddata/xcschemes/desktop.xcscheme
>> lldb/trunk/source/Target/ThreadPlanStepOverBreakpoint.cpp
> 
>> Modified: lldb/trunk/include/lldb/Target/ThreadPlanStepOverBreakpoint.h
>> URL:
> http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Target/ThreadPlanStepOverBreakpoint.h?rev=332922&r1=332921&r2=332922&view=diff
> 
> ==
>> --- lldb/trunk/include/lldb/Target/ThreadPlanStepOverBreakpoint.h
> (original)
>> +++ lldb/trunk/include/lldb/Target/ThreadPlanStepOverBreakpoint.h Mon May
> 21 17:06:55 2018
>> @@ -31,6 +31,7 @@ public:
>>bool StopOthers() override;
>>lldb::StateType GetPlanRunState() override;
>>bool WillStop() override;
>> +  void WillPop() override;
>>bool MischiefManaged() override;
>>void ThreadDestroyed() override;
>>void SetAutoContinue(bool do_it);
> 
>> Modified:
> lldb/trunk/lldb.xcodeproj/xcshareddata/xcschemes/desktop.xcscheme
>> URL:
> http://llvm.org/viewvc/llvm-project/lldb/trunk/lldb.xcodeproj/xcshareddata/xcschemes/desktop.xcscheme?rev=332922&r1=332921&r2=332922&view=diff
> 
> ==
>> --- lldb/trunk/lldb.xcodeproj/xcshareddata/xcschemes/desktop.xcscheme
> (original)
>> +++ lldb/trunk/lldb.xcodeproj/xcshareddata/xcschemes/desktop.xcscheme Mon
> May 21 17:06:55 2018
>> @@ -26,10 +26,18 @@
>>buildConfiguration = "Debug"
>>selectedDebuggerIdentifier =
> "Xcode.DebuggerFoundation.Debugger.LLDB"
>>selectedLauncherIdentifier =
> "Xcode.DebuggerFoundation.Launcher.LLDB"
>> -  language = ""
>>shouldUseLaunchSchemeArgsEnv = "YES">
>>
>>
>> +  
>> + > +BuildableIdentifier = "primary"
>> +BlueprintIdentifier = "26F5C26910F3D9A4009D5894"
>> +BuildableName = "lldb"
>> +BlueprintName = "lldb-tool"
>> +ReferencedContainer = "container:lldb.xcodeproj">
>> + 
>> +  
>>
>>
>> 
>> @@ -37,22 +45,22 @@
>>buildConfiguration = "DebugClang"
>>selectedDebuggerIdentifier =
> "Xcode.DebuggerFoundation.Debugger.LLDB"
>>selectedLauncherIdentifier =
> "Xcode.DebuggerFoundation.Launcher.LLDB"
>> -  language = ""
>> -  launchSty

[Lldb-commits] [PATCH] D47133: Enable ProcessMachCore plugin on non-apple platforms

2018-05-22 Thread Pavel Labath via Phabricator via lldb-commits 
This revision was automatically updated to reflect the committed changes.
Closed by commit rL332997: Enable ProcessMachCore plugin on non-apple platforms 
(authored by labath, committed by ).
Herald added a subscriber: llvm-commits.

Repository:
  rL LLVM

https://reviews.llvm.org/D47133

Files:
  
lldb/trunk/packages/Python/lldbsuite/test/functionalities/postmortem/mach-core/TestMachCore.py
  
lldb/trunk/packages/Python/lldbsuite/test/functionalities/source-map/TestTargetSourceMap.py
  lldb/trunk/source/API/SystemInitializerFull.cpp
  lldb/trunk/source/Plugins/DynamicLoader/CMakeLists.txt
  lldb/trunk/source/Plugins/Platform/MacOSX/PlatformDarwinKernel.h
  lldb/trunk/source/Plugins/Process/CMakeLists.txt

Index: lldb/trunk/packages/Python/lldbsuite/test/functionalities/postmortem/mach-core/TestMachCore.py
===
--- lldb/trunk/packages/Python/lldbsuite/test/functionalities/postmortem/mach-core/TestMachCore.py
+++ lldb/trunk/packages/Python/lldbsuite/test/functionalities/postmortem/mach-core/TestMachCore.py
@@ -26,7 +26,6 @@
 lldb.DBG.SetSelectedPlatform(self._initial_platform)
 super(MachCoreTestCase, self).tearDown()
 
-@skipUnlessDarwin
 def test_selected_thread(self):
 """Test that the right thread is selected after a core is loaded."""
 # Create core form YAML.
Index: lldb/trunk/packages/Python/lldbsuite/test/functionalities/source-map/TestTargetSourceMap.py
===
--- lldb/trunk/packages/Python/lldbsuite/test/functionalities/source-map/TestTargetSourceMap.py
+++ lldb/trunk/packages/Python/lldbsuite/test/functionalities/source-map/TestTargetSourceMap.py
@@ -7,7 +7,6 @@
 
 mydir = TestBase.compute_mydir(__file__)
 
-@skipUnlessDarwin
 @no_debug_info_test
 def test_source_map(self):
 """Test target.source-map' functionality."""
Index: lldb/trunk/source/Plugins/Process/CMakeLists.txt
===
--- lldb/trunk/source/Plugins/Process/CMakeLists.txt
+++ lldb/trunk/source/Plugins/Process/CMakeLists.txt
@@ -11,9 +11,9 @@
   add_subdirectory(Windows/Common)
 elseif (CMAKE_SYSTEM_NAME MATCHES "Darwin")
   add_subdirectory(MacOSX-Kernel)
-  add_subdirectory(mach-core)
 endif()
 add_subdirectory(gdb-remote)
 add_subdirectory(Utility)
 add_subdirectory(elf-core)
+add_subdirectory(mach-core)
 add_subdirectory(minidump)
Index: lldb/trunk/source/Plugins/DynamicLoader/CMakeLists.txt
===
--- lldb/trunk/source/Plugins/DynamicLoader/CMakeLists.txt
+++ lldb/trunk/source/Plugins/DynamicLoader/CMakeLists.txt
@@ -1,9 +1,6 @@
+add_subdirectory(Darwin-Kernel)
 add_subdirectory(MacOSX-DYLD)
 add_subdirectory(POSIX-DYLD)
 add_subdirectory(Static)
 add_subdirectory(Hexagon-DYLD)
 add_subdirectory(Windows-DYLD)
-
-if (CMAKE_SYSTEM_NAME MATCHES "Darwin")
-  add_subdirectory(Darwin-Kernel)
-endif()
Index: lldb/trunk/source/Plugins/Platform/MacOSX/PlatformDarwinKernel.h
===
--- lldb/trunk/source/Plugins/Platform/MacOSX/PlatformDarwinKernel.h
+++ lldb/trunk/source/Plugins/Platform/MacOSX/PlatformDarwinKernel.h
@@ -201,6 +201,7 @@
 // source/Host/macosx/cfcpp utilities.
 
 class PlatformDarwinKernel {
+public:
   static lldb_private::ConstString GetPluginNameStatic();
 };
 
Index: lldb/trunk/source/API/SystemInitializerFull.cpp
===
--- lldb/trunk/source/API/SystemInitializerFull.cpp
+++ lldb/trunk/source/API/SystemInitializerFull.cpp
@@ -84,6 +84,7 @@
 #include "Plugins/Platform/gdb-server/PlatformRemoteGDBServer.h"
 #include "Plugins/Process/elf-core/ProcessElfCore.h"
 #include "Plugins/Process/gdb-remote/ProcessGDBRemote.h"
+#include "Plugins/Process/mach-core/ProcessMachCore.h"
 #include "Plugins/Process/minidump/ProcessMinidump.h"
 #include "Plugins/ScriptInterpreter/None/ScriptInterpreterNone.h"
 #include "Plugins/SymbolFile/DWARF/SymbolFileDWARF.h"
@@ -104,7 +105,6 @@
 #include "Plugins/Platform/MacOSX/PlatformRemoteAppleWatch.h"
 #include "Plugins/Platform/MacOSX/PlatformiOSSimulator.h"
 #include "Plugins/Process/MacOSX-Kernel/ProcessKDP.h"
-#include "Plugins/Process/mach-core/ProcessMachCore.h"
 #include "Plugins/SymbolVendor/MacOSX/SymbolVendorMacOSX.h"
 #endif
 #include "Plugins/StructuredData/DarwinLog/StructuredDataDarwinLog.h"
@@ -313,6 +313,7 @@
 
   JITLoaderGDB::Initialize();
   ProcessElfCore::Initialize();
+  ProcessMachCore::Initialize();
   minidump::ProcessMinidump::Initialize();
   MemoryHistoryASan::Initialize();
   AddressSanitizerRuntime::Initialize();
@@ -353,7 +354,6 @@
 #if defined(__APPLE__)
   SymbolVendorMacOSX::Initialize();
   ProcessKDP::Initialize();
-  ProcessMachCore::Initialize();
   PlatformAppleTVSimulator::Initialize();
   PlatformAppleWatchSimulator::Initialize();

Re: [Lldb-commits] [lldb] r332922 - Work around some odd instruction single-step behavior on macOS.

2018-05-22 Thread Jim Ingham via lldb-commits 
BTW, I think it is likely that we are being interrupted, but the bug happens 
very infrequently and generally goes away when I turn on more than a trivial 
amount of logging, so it's been hard to prove that yet.

Jim


> On May 22, 2018, at 9:37 AM, Jim Ingham  wrote:
> 
> I haven't played around with this yet.  Can it also provide enough memory to 
> pretend a stack trace?  Most of the thread plan stuff will fall over pretty 
> early if it doesn't have at least a couple of frames?
> 
> Jim
> 
> 
>> On May 22, 2018, at 2:41 AM, Pavel Labath  wrote:
>> 
>> This probably isn't what was happening here because you would have seen the
>> extra stops in the logs, but one way I can think of we can end up at the
>> same PC is if the process gets a signal while we're about to single-step
>> it, in which case we need to execute the signal handler first and then get
>> back to the instruction we were about to step over.
>> 
>> Anyway, the reason I am writing this is the testing situation. I think we
>> already have something that should be able to mock a process to a
>> sufficient level to test behavior like this: MockGdbServer in
>> testcases/functionalities/gdb_remote_client. So, I believe it should be
>> possible to trigger this via a sequence like:
>> - connect to mock server (server pretends to be stopped at PC 0x1000)
>> - breakpoint set --address 0x1010
>> - continue (server pretends to stop at 0x1010)
>> - continue (after the first $s packet, server stays at 0x1010, after the
>> second one it advances to 0x1011, after the final $c, return W00)
>> - verify the expected packets were sent
>> 
>> Have you tried using MockGdbServer in this way?
>> 
>> regards,
>> pl
>> 
>> On Tue, 22 May 2018 at 01:10, Jim Ingham via lldb-commits <
>> lldb-commits@lists.llvm.org> wrote:
>> 
>>> Author: jingham
>>> Date: Mon May 21 17:06:55 2018
>>> New Revision: 332922
>> 
>>> URL: http://llvm.org/viewvc/llvm-project?rev=332922&view=rev
>>> Log:
>>> Work around some odd instruction single-step behavior on macOS.
>> 
>>> We've seen some cases on macOS where you go to instruction single
>>> step (over a breakpoint), and single step returns but the instruction
>>> hasn't been executed (and the pc hasn't moved.)  The
>> ThreadPlanStepOverBreakpoint
>>> used to handle this case by accident, but the patches to handle two
>> adjacent
>>> breakpoints broke that accident.
>> 
>>> This patch fixes the logic of ExplainsStop to explicitly handle the case
>> where
>>> the pc didn't move.  It also adds a WillPop that re-enables the
>> breakpoint we
>>> were stepping over.  We never want an unexpected path through the plan to
>>> fool us into not doing that.
>> 
>>> I have no idea how to make this bug happen.  It is very inconsistent when
>> it
>>> occurs IRL.  We really need a full MockProcess Plugin before we can start
>> to write
>>> tests for this sort of system hiccup.
>> 
>>> 
>> 
>>> Modified:
>>>lldb/trunk/include/lldb/Target/ThreadPlanStepOverBreakpoint.h
>>>lldb/trunk/lldb.xcodeproj/xcshareddata/xcschemes/desktop.xcscheme
>>>lldb/trunk/source/Target/ThreadPlanStepOverBreakpoint.cpp
>> 
>>> Modified: lldb/trunk/include/lldb/Target/ThreadPlanStepOverBreakpoint.h
>>> URL:
>> http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Target/ThreadPlanStepOverBreakpoint.h?rev=332922&r1=332921&r2=332922&view=diff
>> 
>> ==
>>> --- lldb/trunk/include/lldb/Target/ThreadPlanStepOverBreakpoint.h
>> (original)
>>> +++ lldb/trunk/include/lldb/Target/ThreadPlanStepOverBreakpoint.h Mon May
>> 21 17:06:55 2018
>>> @@ -31,6 +31,7 @@ public:
>>>   bool StopOthers() override;
>>>   lldb::StateType GetPlanRunState() override;
>>>   bool WillStop() override;
>>> +  void WillPop() override;
>>>   bool MischiefManaged() override;
>>>   void ThreadDestroyed() override;
>>>   void SetAutoContinue(bool do_it);
>> 
>>> Modified:
>> lldb/trunk/lldb.xcodeproj/xcshareddata/xcschemes/desktop.xcscheme
>>> URL:
>> http://llvm.org/viewvc/llvm-project/lldb/trunk/lldb.xcodeproj/xcshareddata/xcschemes/desktop.xcscheme?rev=332922&r1=332921&r2=332922&view=diff
>> 
>> ==
>>> --- lldb/trunk/lldb.xcodeproj/xcshareddata/xcschemes/desktop.xcscheme
>> (original)
>>> +++ lldb/trunk/lldb.xcodeproj/xcshareddata/xcschemes/desktop.xcscheme Mon
>> May 21 17:06:55 2018
>>> @@ -26,10 +26,18 @@
>>>   buildConfiguration = "Debug"
>>>   selectedDebuggerIdentifier =
>> "Xcode.DebuggerFoundation.Debugger.LLDB"
>>>   selectedLauncherIdentifier =
>> "Xcode.DebuggerFoundation.Launcher.LLDB"
>>> -  language = ""
>>>   shouldUseLaunchSchemeArgsEnv = "YES">
>>>   
>>>   
>>> +  
>>> + >> +BuildableIdentifier = "primary"
>>> +BlueprintIdentifier = "26F5C26910F3D9A4009D5894"
>>> +BuildableName = "lldb"
>>> +BlueprintName = "lldb-tool"
>>> +

Re: [Lldb-commits] [lldb] r332922 - Work around some odd instruction single-step behavior on macOS.

2018-05-22 Thread Pavel Labath via lldb-commits 
> > On May 22, 2018, at 9:37 AM, Jim Ingham  wrote:
> >
> > I haven't played around with this yet.  Can it also provide enough
memory to pretend a stack trace?  Most of the thread plan stuff will fall
over pretty early if it doesn't have at least a couple of frames?

You can do anything, but there isn't much infrastructure for it yet, so
simulating complex states is not going to be pretty. The reason I suggested
this is because this
deals with only instruction-level steps and not the fancy step-ins/outs,
which require more stack frames, so /I hope/ a very rudimentary mock will
be enough. I was thinking of something like:
memory:
0x1000-0x2000: code, full of "nop" instructions
0x2000-0x3000: data full of zeroes
registers:
pc- points to 0x1000, then slowly advances
sp - points to 0x2xxx
other registers zero


On Tue, 22 May 2018 at 17:38, Jim Ingham  wrote:

> BTW, I think it is likely that we are being interrupted, but the bug
happens very infrequently and generally goes away when I turn on more than
a trivial amount of logging, so it's been hard to prove that yet.

Ah, interesting.. By "we" I assume you mean the process-under-debug (and
not say debugserver of lldb). I am not sure how ptrace works on macos, but
if it's anything like linux the interrupt signal will only get delivered
after the process is resumed (and not while the debugger has it suspended).
If that's the case then it should be possible to reproduce this fairly
reliably by sending the signal (with kill) while the process is stopped at
the breakpoint, and then attempting to step over it.
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [PATCH] D43984: Make the clang module cache setting available without a target

2018-05-22 Thread Zachary Turner via lldb-commits 
This change has introduced a dependency from Core -> clang Driver (due to
#include "clang/Driver/Driver.h" in ModuleList.cpp).  Can you please try to
find a way to remove this dependency?

On Fri, Mar 2, 2018 at 2:45 PM Phabricator via Phabricator via lldb-commits
 wrote:

> This revision was not accepted when it landed; it landed in state "Needs
> Review".
> This revision was automatically updated to reflect the committed changes.
> Closed by commit rL326628: Make the clang module cache setting available
> without a target (authored by adrian, committed by ).
> Herald added a subscriber: llvm-commits.
>
> Changed prior to commit:
>   https://reviews.llvm.org/D43984?vs=136803&id=136858#toc
>
> Repository:
>   rL LLVM
>
> https://reviews.llvm.org/D43984
>
> Files:
>   lldb/trunk/include/lldb/Core/ModuleList.h
>   lldb/trunk/include/lldb/Target/Target.h
>
> lldb/trunk/packages/Python/lldbsuite/test/lang/objc/modules-cache/Makefile
>
> lldb/trunk/packages/Python/lldbsuite/test/lang/objc/modules-cache/TestClangModulesCache.py
>   lldb/trunk/packages/Python/lldbsuite/test/lang/objc/modules-cache/f.h
>   lldb/trunk/packages/Python/lldbsuite/test/lang/objc/modules-cache/main.m
>
> lldb/trunk/packages/Python/lldbsuite/test/lang/objc/modules-cache/module.modulemap
>   lldb/trunk/packages/Python/lldbsuite/test/lldbtest.py
>   lldb/trunk/source/Core/Debugger.cpp
>   lldb/trunk/source/Core/ModuleList.cpp
>
> lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangModulesDeclVendor.cpp
>   lldb/trunk/source/Target/Target.cpp
>
> ___
> lldb-commits mailing list
> lldb-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D43984: Make the clang module cache setting available without a target

2018-05-22 Thread Zachary Turner via Phabricator via lldb-commits 
zturner added subscribers: aprantl, labath, zturner.
zturner added a comment.

This change has introduced a dependency from Core -> clang Driver (due to
#include "clang/Driver/Driver.h" in ModuleList.cpp).  Can you please try to
find a way to remove this dependency?


Repository:
  rL LLVM

https://reviews.llvm.org/D43984



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

Re: [Lldb-commits] [PATCH] D43984: Make the clang module cache setting available without a target

2018-05-22 Thread Adrian Prantl via lldb-commits 
Can you help me understand why this dependency poses a problem? It's not clear 
to me how to resolve this otherwise. The point of the patch is to ask the clang 
driver for the clang module cache path. If the problem is that we otherwise 
don't use the driver and now pull it in, would moving the Clang API into a 
different clang library work? Which one?

-- adrian

> On May 22, 2018, at 11:28 AM, Zachary Turner  wrote:
> 
> This change has introduced a dependency from Core -> clang Driver (due to 
> #include "clang/Driver/Driver.h" in ModuleList.cpp).  Can you please try to 
> find a way to remove this dependency?
> 
> On Fri, Mar 2, 2018 at 2:45 PM Phabricator via Phabricator via lldb-commits 
> mailto:lldb-commits@lists.llvm.org>> wrote:
> This revision was not accepted when it landed; it landed in state "Needs 
> Review".
> This revision was automatically updated to reflect the committed changes.
> Closed by commit rL326628: Make the clang module cache setting available 
> without a target (authored by adrian, committed by ).
> Herald added a subscriber: llvm-commits.
> 
> Changed prior to commit:
>   https://reviews.llvm.org/D43984?vs=136803&id=136858#toc 
> 
> 
> Repository:
>   rL LLVM
> 
> https://reviews.llvm.org/D43984 
> 
> Files:
>   lldb/trunk/include/lldb/Core/ModuleList.h
>   lldb/trunk/include/lldb/Target/Target.h
>   lldb/trunk/packages/Python/lldbsuite/test/lang/objc/modules-cache/Makefile
>   
> lldb/trunk/packages/Python/lldbsuite/test/lang/objc/modules-cache/TestClangModulesCache.py
>   lldb/trunk/packages/Python/lldbsuite/test/lang/objc/modules-cache/f.h
>   lldb/trunk/packages/Python/lldbsuite/test/lang/objc/modules-cache/main.m
>   
> lldb/trunk/packages/Python/lldbsuite/test/lang/objc/modules-cache/module.modulemap
>   lldb/trunk/packages/Python/lldbsuite/test/lldbtest.py
>   lldb/trunk/source/Core/Debugger.cpp
>   lldb/trunk/source/Core/ModuleList.cpp
>   lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangModulesDeclVendor.cpp
>   lldb/trunk/source/Target/Target.cpp
> 
> ___
> lldb-commits mailing list
> lldb-commits@lists.llvm.org 
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits 
> 

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

Re: [Lldb-commits] [PATCH] D43984: Make the clang module cache setting available without a target

2018-05-22 Thread Zachary Turner via lldb-commits 
We've been going to a lot of effort recently to separate out dependencies
and properly layer libraries.  Even if we deemed this to be an acceptable
location to #include something from clang/Driver, the CMake does not
actually reference clangDriver in its link list.  So the only reason this
is working, AFAICT, is because most of the final executables ultimately
link in all of clang.  But that in and of itself is something we are trying
to move away from.  For theoretical reasons (i.e. it doesn't make sense
from a layering standpoint) as well as more practical reasons  -- we should
be able to use LLDB as a library, and we should be able to link against
pieces of it without requiring all of clang (or without requiring all of X
where X is anything unrelated to the logical component we want to use).

An LLDB module is, conceptually, an abstract concept that is independent of
clang.

One way to resolve it, perhaps, would be to add a function

static void setDefaultModuleCachePath(const Twine &Path);

Then, during startup where we are in the LLDB driver and have linked
against everything including clang, call
setDefaultModuleCachePath(clang::driver::Driver::getDefaultModuleCachePath());

If the ModuleListProperties class were somewhere else, perhaps this would
be less of a problem.  But we can't have a dependency from Core to clang
(and especially not a newly introduced one.  There is already one there to
clang/AST that we are trying to remove).

On Tue, May 22, 2018 at 11:32 AM Adrian Prantl  wrote:

> Can you help me understand why this dependency poses a problem? It's not
> clear to me how to resolve this otherwise. The point of the patch is to ask
> the clang driver for the clang module cache path. If the problem is that we
> otherwise don't use the driver and now pull it in, would moving the Clang
> API into a different clang library work? Which one?
>
> -- adrian
>
> On May 22, 2018, at 11:28 AM, Zachary Turner  wrote:
>
> This change has introduced a dependency from Core -> clang Driver (due to
> #include "clang/Driver/Driver.h" in ModuleList.cpp).  Can you please try to
> find a way to remove this dependency?
>
> On Fri, Mar 2, 2018 at 2:45 PM Phabricator via Phabricator via
> lldb-commits  wrote:
>
>> This revision was not accepted when it landed; it landed in state "Needs
>> Review".
>> This revision was automatically updated to reflect the committed changes.
>> Closed by commit rL326628: Make the clang module cache setting available
>> without a target (authored by adrian, committed by ).
>> Herald added a subscriber: llvm-commits.
>>
>> Changed prior to commit:
>>   https://reviews.llvm.org/D43984?vs=136803&id=136858#toc
>>
>> Repository:
>>   rL LLVM
>>
>> https://reviews.llvm.org/D43984
>>
>> Files:
>>   lldb/trunk/include/lldb/Core/ModuleList.h
>>   lldb/trunk/include/lldb/Target/Target.h
>>
>> lldb/trunk/packages/Python/lldbsuite/test/lang/objc/modules-cache/Makefile
>>
>> lldb/trunk/packages/Python/lldbsuite/test/lang/objc/modules-cache/TestClangModulesCache.py
>>   lldb/trunk/packages/Python/lldbsuite/test/lang/objc/modules-cache/f.h
>>   lldb/trunk/packages/Python/lldbsuite/test/lang/objc/modules-cache/main.m
>>
>> lldb/trunk/packages/Python/lldbsuite/test/lang/objc/modules-cache/module.modulemap
>>   lldb/trunk/packages/Python/lldbsuite/test/lldbtest.py
>>   lldb/trunk/source/Core/Debugger.cpp
>>   lldb/trunk/source/Core/ModuleList.cpp
>>
>> lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangModulesDeclVendor.cpp
>>   lldb/trunk/source/Target/Target.cpp
>>
>> ___
>> lldb-commits mailing list
>> lldb-commits@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
>>
>
>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [PATCH] D43984: Make the clang module cache setting available without a target

2018-05-22 Thread Jim Ingham via lldb-commits 
Where clang stores modules by default on the host system seems like a Host 
function.  It isn't in practice because that gets delegated to clang to do the 
host specific calculation, but in theory that seems where the functionality 
properly belongs.  It's a little odd to have ModuleList depend on Host, but 
much less strained than to have it depend on clang.

Jim

> On May 22, 2018, at 11:57 AM, Zachary Turner  wrote:
> 
> We've been going to a lot of effort recently to separate out dependencies and 
> properly layer libraries.  Even if we deemed this to be an acceptable 
> location to #include something from clang/Driver, the CMake does not actually 
> reference clangDriver in its link list.  So the only reason this is working, 
> AFAICT, is because most of the final executables ultimately link in all of 
> clang.  But that in and of itself is something we are trying to move away 
> from.  For theoretical reasons (i.e. it doesn't make sense from a layering 
> standpoint) as well as more practical reasons  -- we should be able to use 
> LLDB as a library, and we should be able to link against pieces of it without 
> requiring all of clang (or without requiring all of X where X is anything 
> unrelated to the logical component we want to use).
> 
> An LLDB module is, conceptually, an abstract concept that is independent of 
> clang.
> 
> One way to resolve it, perhaps, would be to add a function 
> 
> static void setDefaultModuleCachePath(const Twine &Path);
> 
> Then, during startup where we are in the LLDB driver and have linked against 
> everything including clang, call 
> setDefaultModuleCachePath(clang::driver::Driver::getDefaultModuleCachePath());
> 
> If the ModuleListProperties class were somewhere else, perhaps this would be 
> less of a problem.  But we can't have a dependency from Core to clang (and 
> especially not a newly introduced one.  There is already one there to 
> clang/AST that we are trying to remove).
> 
> On Tue, May 22, 2018 at 11:32 AM Adrian Prantl  wrote:
> Can you help me understand why this dependency poses a problem? It's not 
> clear to me how to resolve this otherwise. The point of the patch is to ask 
> the clang driver for the clang module cache path. If the problem is that we 
> otherwise don't use the driver and now pull it in, would moving the Clang API 
> into a different clang library work? Which one?
> 
> -- adrian
> 
>> On May 22, 2018, at 11:28 AM, Zachary Turner  wrote:
>> 
>> This change has introduced a dependency from Core -> clang Driver (due to 
>> #include "clang/Driver/Driver.h" in ModuleList.cpp).  Can you please try to 
>> find a way to remove this dependency?
>> 
>> On Fri, Mar 2, 2018 at 2:45 PM Phabricator via Phabricator via lldb-commits 
>>  wrote:
>> This revision was not accepted when it landed; it landed in state "Needs 
>> Review".
>> This revision was automatically updated to reflect the committed changes.
>> Closed by commit rL326628: Make the clang module cache setting available 
>> without a target (authored by adrian, committed by ).
>> Herald added a subscriber: llvm-commits.
>> 
>> Changed prior to commit:
>>   https://reviews.llvm.org/D43984?vs=136803&id=136858#toc
>> 
>> Repository:
>>   rL LLVM
>> 
>> https://reviews.llvm.org/D43984
>> 
>> Files:
>>   lldb/trunk/include/lldb/Core/ModuleList.h
>>   lldb/trunk/include/lldb/Target/Target.h
>>   lldb/trunk/packages/Python/lldbsuite/test/lang/objc/modules-cache/Makefile
>>   
>> lldb/trunk/packages/Python/lldbsuite/test/lang/objc/modules-cache/TestClangModulesCache.py
>>   lldb/trunk/packages/Python/lldbsuite/test/lang/objc/modules-cache/f.h
>>   lldb/trunk/packages/Python/lldbsuite/test/lang/objc/modules-cache/main.m
>>   
>> lldb/trunk/packages/Python/lldbsuite/test/lang/objc/modules-cache/module.modulemap
>>   lldb/trunk/packages/Python/lldbsuite/test/lldbtest.py
>>   lldb/trunk/source/Core/Debugger.cpp
>>   lldb/trunk/source/Core/ModuleList.cpp
>>   lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangModulesDeclVendor.cpp
>>   lldb/trunk/source/Target/Target.cpp
>> 
>> ___
>> lldb-commits mailing list
>> lldb-commits@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
> 

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

[Lldb-commits] [PATCH] D47228: Break dependency from Core to ObjectFileJIT

2018-05-22 Thread Zachary Turner via Phabricator via lldb-commits 
zturner created this revision.
zturner added reviewers: labath, jingham.
Herald added a subscriber: mgorny.

This was responsible for the cycle Core > ObjectFile > Core.

The only reason this dependency was here was so that `Module` could have a 
function called `CreateJITModule` which created things in a special order.  
Instead of making this specific to creating a jit module, I turn this into a 
function that can create a module for any type of object file plugin and 
forwards the arguments through.  Since it is not instantiated in `Core`, the 
linker (and header file) dependency moves to the point where it is 
instantiated, which only happens in `Expression`.  Conceptually, this location 
also happens to make more sense for a dependency on `ObjectFileJIT`.  After 
all, we JIT expressions so it's no surprise that Expression needs to make use 
of `ObjectFileJIT`.

This change reduces the distinct cycle count from 38 to 37


https://reviews.llvm.org/D47228

Files:
  lldb/include/lldb/Core/Module.h
  lldb/source/Core/CMakeLists.txt
  lldb/source/Core/Module.cpp
  lldb/source/Expression/CMakeLists.txt
  lldb/source/Expression/IRExecutionUnit.cpp

Index: lldb/source/Expression/IRExecutionUnit.cpp
===
--- lldb/source/Expression/IRExecutionUnit.cpp
+++ lldb/source/Expression/IRExecutionUnit.cpp
@@ -33,6 +33,7 @@
 #include "lldb/Utility/Log.h"
 
 #include "lldb/../../source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.h"
+#include "lldb/../../source/Plugins/ObjectFile/JIT/ObjectFileJIT.h"
 
 using namespace lldb_private;
 
@@ -1225,15 +1226,18 @@
 lldb::ModuleSP IRExecutionUnit::GetJITModule() {
   ExecutionContext exe_ctx(GetBestExecutionContextScope());
   Target *target = exe_ctx.GetTargetPtr();
-  if (target) {
-lldb::ModuleSP jit_module_sp = lldb_private::Module::CreateJITModule(
-std::static_pointer_cast(
-shared_from_this()));
-if (jit_module_sp) {
-  bool changed = false;
-  jit_module_sp->SetLoadAddress(*target, 0, true, changed);
-}
-return jit_module_sp;
-  }
-  return lldb::ModuleSP();
+  if (!target)
+return nullptr;
+
+  auto Delegate = std::static_pointer_cast(
+  shared_from_this());
+
+  lldb::ModuleSP jit_module_sp =
+  lldb_private::Module::CreateModuleFromObjectFile(Delegate);
+  if (!jit_module_sp)
+return nullptr;
+
+  bool changed = false;
+  jit_module_sp->SetLoadAddress(*target, 0, true, changed);
+  return jit_module_sp;
 }
Index: lldb/source/Expression/CMakeLists.txt
===
--- lldb/source/Expression/CMakeLists.txt
+++ lldb/source/Expression/CMakeLists.txt
@@ -30,6 +30,7 @@
 lldbTarget
 lldbUtility
 lldbPluginExpressionParserClang
+lldbPluginObjectFileJIT
 
   LINK_COMPONENTS
 Core
Index: lldb/source/Core/Module.cpp
===
--- lldb/source/Core/Module.cpp
+++ lldb/source/Core/Module.cpp
@@ -53,7 +53,6 @@
 
 #include "Plugins/Language/CPlusPlus/CPlusPlusLanguage.h"
 #include "Plugins/Language/ObjC/ObjCLanguage.h"
-#include "Plugins/ObjectFile/JIT/ObjectFileJIT.h"
 
 #include "llvm/ADT/STLExtras.h"// for make_unique
 #include "llvm/Support/Compiler.h" // for LLVM_PRETT...
@@ -1652,26 +1651,6 @@
   return 0;
 }
 
-ModuleSP
-Module::CreateJITModule(const lldb::ObjectFileJITDelegateSP &delegate_sp) {
-  if (delegate_sp) {
-// Must create a module and place it into a shared pointer before we can
-// create an object file since it has a std::weak_ptr back to the module,
-// so we need to control the creation carefully in this static function
-ModuleSP module_sp(new Module());
-module_sp->m_objfile_sp =
-std::make_shared(module_sp, delegate_sp);
-if (module_sp->m_objfile_sp) {
-  // Once we get the object file, update our module with the object file's
-  // architecture since it might differ in vendor/os if some parts were
-  // unknown.
-  module_sp->m_objfile_sp->GetArchitecture(module_sp->m_arch);
-}
-return module_sp;
-  }
-  return ModuleSP();
-}
-
 bool Module::GetIsDynamicLinkEditor() {
   ObjectFile *obj_file = GetObjectFile();
 
Index: lldb/source/Core/CMakeLists.txt
===
--- lldb/source/Core/CMakeLists.txt
+++ lldb/source/Core/CMakeLists.txt
@@ -69,7 +69,6 @@
 lldbPluginProcessUtility
 lldbPluginCPlusPlusLanguage
 lldbPluginObjCLanguage
-lldbPluginObjectFileJIT
 ${LLDB_CURSES_LIBS}
 
   LINK_COMPONENTS
Index: lldb/include/lldb/Core/Module.h
===
--- lldb/include/lldb/Core/Module.h
+++ lldb/include/lldb/Core/Module.h
@@ -155,8 +155,23 @@
 
   Module(const ModuleSpec &module_spec);
 
-  static lldb::ModuleSP
-  CreateJITModule(const lldb::ObjectFileJITDelegateSP &delegate_sp);
+  template 
+  static lldb::ModuleSP CreateMo

[Lldb-commits] [lldb] r333032 - Avoid using header from Host/macosx when not testing an apple build.

2018-05-22 Thread James Y Knight via lldb-commits 
Author: jyknight
Date: Tue May 22 14:49:41 2018
New Revision: 333032

URL: http://llvm.org/viewvc/llvm-project?rev=333032&view=rev
Log:
Avoid using header from Host/macosx when not testing an apple build.

Modified:
lldb/trunk/unittests/Host/HostInfoTest.cpp

Modified: lldb/trunk/unittests/Host/HostInfoTest.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/unittests/Host/HostInfoTest.cpp?rev=333032&r1=333031&r2=333032&view=diff
==
--- lldb/trunk/unittests/Host/HostInfoTest.cpp (original)
+++ lldb/trunk/unittests/Host/HostInfoTest.cpp Tue May 22 14:49:41 2018
@@ -8,11 +8,14 @@
 
//===--===//
 
 #include "lldb/Host/HostInfo.h"
-#include "lldb/Host/macosx/HostInfoMacOSX.h"
 #include "lldb/lldb-defines.h"
 #include "TestingSupport/TestUtilities.h"
 #include "gtest/gtest.h"
 
+#ifdef __APPLE__
+#include "lldb/Host/macosx/HostInfoMacOSX.h"
+#endif
+
 using namespace lldb_private;
 using namespace llvm;
 
@@ -47,6 +50,8 @@ TEST_F(HostInfoTest, GetAugmentedArchSpe
 }
 
 
+#ifdef __APPLE__
+
 struct HostInfoMacOSXTest : public HostInfoMacOSX {
   static std::string ComputeClangDir(std::string lldb_shlib_path,
  bool verify = false) {
@@ -58,7 +63,6 @@ struct HostInfoMacOSXTest : public HostI
 };
 
 
-#ifdef __APPLE__
 TEST_F(HostInfoTest, MacOSX) {
   // This returns whatever the POSIX fallback returns.
   std::string posix = "/usr/lib/liblldb.dylib";


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

[Lldb-commits] [PATCH] D47232: Break dependency from Expression -> Commands

2018-05-22 Thread Zachary Turner via Phabricator via lldb-commits 
zturner created this revision.
zturner added reviewers: labath, davide.

The REPL (which lives in Expression) was making use of the command options for 
the expression command.  It's arguable whether `REPL` should even live in 
`Expression` to begin with, but it makes more sense for Command to depend on 
REPL than the other way around.  The command library should be thought of as a 
UI library, low level engine stuff shouldn't depend on it, but the other way 
around makes perfect sense.

Anyway, only about 3-4 of the fields of this structure were even used and the 
rest were ignored, so we just give `REPL` its own custom structure and have the 
command object fill this out and pass it in.  This way `REPL` doesn't need to 
reference one from a higher level library.

This breaks the cycle from Expression -> Commands -> Expression, reducing the 
distinct cycle count to 36.

Note that no `CMakeLists.txt` file needs to be updated here, because 
`Expression` was (incorrectly) not including `Commands` in its link list to 
begin with.


https://reviews.llvm.org/D47232

Files:
  lldb/include/lldb/Expression/REPL.h
  lldb/source/Commands/CommandObjectExpression.cpp
  lldb/source/Expression/REPL.cpp

Index: lldb/source/Expression/REPL.cpp
===
--- lldb/source/Expression/REPL.cpp
+++ lldb/source/Expression/REPL.cpp
@@ -32,12 +32,6 @@
   auto exe_ctx = debugger.GetCommandInterpreter().GetExecutionContext();
   m_format_options.OptionParsingStarting(&exe_ctx);
   m_varobj_options.OptionParsingStarting(&exe_ctx);
-  m_command_options.OptionParsingStarting(&exe_ctx);
-
-  // Default certain settings for REPL regardless of the global settings.
-  m_command_options.unwind_on_error = false;
-  m_command_options.ignore_breakpoints = false;
-  m_command_options.debug = false;
 }
 
 REPL::~REPL() = default;
@@ -283,18 +277,19 @@
 
   EvaluateExpressionOptions expr_options;
   expr_options.SetCoerceToId(m_varobj_options.use_objc);
-  expr_options.SetUnwindOnError(m_command_options.unwind_on_error);
-  expr_options.SetIgnoreBreakpoints(m_command_options.ignore_breakpoints);
+  expr_options.SetUnwindOnError(m_command_options.UnwindOnError);
+  expr_options.SetIgnoreBreakpoints(m_command_options.IgnoreBreakpoints);
   expr_options.SetKeepInMemory(true);
   expr_options.SetUseDynamic(m_varobj_options.use_dynamic);
-  expr_options.SetTryAllThreads(m_command_options.try_all_threads);
+  expr_options.SetTryAllThreads(m_command_options.TryAllThreads);
   expr_options.SetGenerateDebugInfo(true);
   expr_options.SetREPLEnabled(true);
   expr_options.SetColorizeErrors(colorize_err);
   expr_options.SetPoundLine(m_repl_source_path.c_str(),
 m_code.GetSize() + 1);
-  if (m_command_options.timeout > 0)
-expr_options.SetTimeout(std::chrono::microseconds(m_command_options.timeout));
+  if (m_command_options.Timeout > 0)
+expr_options.SetTimeout(
+std::chrono::microseconds(m_command_options.Timeout));
   else
 expr_options.SetTimeout(llvm::None);
 
Index: lldb/source/Commands/CommandObjectExpression.cpp
===
--- lldb/source/Commands/CommandObjectExpression.cpp
+++ lldb/source/Commands/CommandObjectExpression.cpp
@@ -588,7 +588,13 @@
 
 if (repl_sp) {
   if (initialize) {
-repl_sp->SetCommandOptions(m_command_options);
+REPL::CommandOptions Options;
+Options.IgnoreBreakpoints =
+m_command_options.ignore_breakpoints;
+Options.Timeout = m_command_options.timeout;
+Options.TryAllThreads = m_command_options.try_all_threads;
+Options.UnwindOnError = m_command_options.unwind_on_error;
+repl_sp->SetCommandOptions(Options);
 repl_sp->SetFormatOptions(m_format_options);
 repl_sp->SetValueObjectDisplayOptions(m_varobj_options);
   }
Index: lldb/include/lldb/Expression/REPL.h
===
--- lldb/include/lldb/Expression/REPL.h
+++ lldb/include/lldb/Expression/REPL.h
@@ -16,14 +16,20 @@
 
 // Other libraries and framework includes
 // Project includes
-#include "lldb/../../source/Commands/CommandObjectExpression.h"
+#include "lldb/Core/IOHandler.h"
 #include "lldb/Interpreter/OptionGroupFormat.h"
 #include "lldb/Interpreter/OptionGroupValueObjectDisplay.h"
 
 namespace lldb_private {
 
 class REPL : public IOHandlerDelegate {
 public:
+  struct CommandOptions {
+bool UnwindOnError = false;
+bool IgnoreBreakpoints = false;
+bool TryAllThreads = true;
+uint32_t Timeout = 0;
+  };
   //--
   // See TypeSystem.h for how to add subclasses to this.
   //

[Lldb-commits] [lldb] r333035 - Normalize some lldb #include statements.

2018-05-22 Thread James Y Knight via lldb-commits 
Author: jyknight
Date: Tue May 22 15:53:50 2018
New Revision: 333035

URL: http://llvm.org/viewvc/llvm-project?rev=333035&view=rev
Log:
Normalize some lldb #include statements.

Most non-local includes of header files living under lldb/sources/
were specified with the full path starting after sources/. However, in
a few instances, other sub-directories were added to include paths, or

Normalize those few instances to follow the style used by the rest of
the codebase, to make it easier to understand.

Modified:
lldb/trunk/source/API/SBTarget.cpp
lldb/trunk/source/Interpreter/CommandInterpreter.cpp
lldb/trunk/source/Plugins/JITLoader/GDB/CMakeLists.txt
lldb/trunk/source/Plugins/Platform/gdb-server/PlatformRemoteGDBServer.h
lldb/trunk/source/Plugins/Process/FreeBSD/CMakeLists.txt
lldb/trunk/source/Plugins/Process/FreeBSD/RegisterContextPOSIX.h

lldb/trunk/source/Plugins/Process/FreeBSD/RegisterContextPOSIXProcessMonitor_arm.cpp

lldb/trunk/source/Plugins/Process/FreeBSD/RegisterContextPOSIXProcessMonitor_powerpc.cpp
lldb/trunk/source/Plugins/Process/Linux/CMakeLists.txt
lldb/trunk/source/Plugins/Process/Linux/NativeRegisterContextLinux_ppc64le.h
lldb/trunk/source/Plugins/Process/NetBSD/CMakeLists.txt
lldb/trunk/source/Plugins/Process/POSIX/CMakeLists.txt
lldb/trunk/source/Plugins/Process/Utility/CMakeLists.txt
lldb/trunk/source/Plugins/Process/Windows/Common/CMakeLists.txt
lldb/trunk/source/Plugins/Process/Windows/Common/TargetThreadWindows.cpp

lldb/trunk/source/Plugins/Process/Windows/Common/x64/RegisterContextWindows_x64.cpp

lldb/trunk/source/Plugins/Process/Windows/Common/x86/RegisterContextWindows_x86.cpp
lldb/trunk/source/Plugins/Process/elf-core/CMakeLists.txt
lldb/trunk/source/Plugins/Process/mach-core/CMakeLists.txt
lldb/trunk/source/Plugins/Process/mach-core/ProcessMachCore.cpp
lldb/trunk/source/Plugins/Process/minidump/CMakeLists.txt
lldb/trunk/source/Target/CMakeLists.txt

Modified: lldb/trunk/source/API/SBTarget.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/API/SBTarget.cpp?rev=333035&r1=333034&r2=333035&view=diff
==
--- lldb/trunk/source/API/SBTarget.cpp (original)
+++ lldb/trunk/source/API/SBTarget.cpp Tue May 22 15:53:50 2018
@@ -64,7 +64,7 @@
 #include "lldb/Utility/Log.h"
 #include "lldb/Utility/RegularExpression.h"
 
-#include "../source/Commands/CommandObjectBreakpoint.h"
+#include "Commands/CommandObjectBreakpoint.h"
 #include "lldb/Interpreter/CommandReturnObject.h"
 #include "llvm/Support/PrettyStackTrace.h"
 #include "llvm/Support/Regex.h"

Modified: lldb/trunk/source/Interpreter/CommandInterpreter.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Interpreter/CommandInterpreter.cpp?rev=333035&r1=333034&r2=333035&view=diff
==
--- lldb/trunk/source/Interpreter/CommandInterpreter.cpp (original)
+++ lldb/trunk/source/Interpreter/CommandInterpreter.cpp Tue May 22 15:53:50 
2018
@@ -14,31 +14,31 @@
 #include "CommandObjectScript.h"
 #include "lldb/Interpreter/CommandObjectRegexCommand.h"
 
-#include "../Commands/CommandObjectApropos.h"
-#include "../Commands/CommandObjectBreakpoint.h"
-#include "../Commands/CommandObjectBugreport.h"
-#include "../Commands/CommandObjectCommands.h"
-#include "../Commands/CommandObjectDisassemble.h"
-#include "../Commands/CommandObjectExpression.h"
-#include "../Commands/CommandObjectFrame.h"
-#include "../Commands/CommandObjectGUI.h"
-#include "../Commands/CommandObjectHelp.h"
-#include "../Commands/CommandObjectLanguage.h"
-#include "../Commands/CommandObjectLog.h"
-#include "../Commands/CommandObjectMemory.h"
-#include "../Commands/CommandObjectPlatform.h"
-#include "../Commands/CommandObjectPlugin.h"
-#include "../Commands/CommandObjectProcess.h"
-#include "../Commands/CommandObjectQuit.h"
-#include "../Commands/CommandObjectRegister.h"
-#include "../Commands/CommandObjectSettings.h"
-#include "../Commands/CommandObjectSource.h"
-#include "../Commands/CommandObjectStats.h"
-#include "../Commands/CommandObjectTarget.h"
-#include "../Commands/CommandObjectThread.h"
-#include "../Commands/CommandObjectType.h"
-#include "../Commands/CommandObjectVersion.h"
-#include "../Commands/CommandObjectWatchpoint.h"
+#include "Commands/CommandObjectApropos.h"
+#include "Commands/CommandObjectBreakpoint.h"
+#include "Commands/CommandObjectBugreport.h"
+#include "Commands/CommandObjectCommands.h"
+#include "Commands/CommandObjectDisassemble.h"
+#include "Commands/CommandObjectExpression.h"
+#include "Commands/CommandObjectFrame.h"
+#include "Commands/CommandObjectGUI.h"
+#include "Commands/CommandObjectHelp.h"
+#include "Commands/CommandObjectLanguage.h"
+#include "Commands/CommandObjectLog.h"
+#include "Commands/CommandObjectMemory.h"
+#include "Commands/CommandObjectPlatform.h"
+#include "Commands/Comman

[Lldb-commits] [PATCH] D47232: Break dependency from Expression -> Commands

2018-05-22 Thread Davide Italiano via Phabricator via lldb-commits 
davide accepted this revision.
davide added a comment.
This revision is now accepted and ready to land.

Looks fine to me, but let's wait for Pavel. Are you back working on lldb ? :)


https://reviews.llvm.org/D47232



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

[Lldb-commits] [lldb] r333041 - build: use cmake to find the libedit content

2018-05-22 Thread Saleem Abdulrasool via lldb-commits 
Author: compnerd
Date: Tue May 22 16:24:46 2018
New Revision: 333041

URL: http://llvm.org/viewvc/llvm-project?rev=333041&view=rev
Log:
build: use cmake to find the libedit content

Use proper cmake techniques to detect where the libedit package resides.
This allows for the use of libedit from an alternative location which is
needed for supporting cross-compilation.

Added:
lldb/trunk/cmake/modules/FindLibEdit.cmake
Modified:
lldb/trunk/CMakeLists.txt
lldb/trunk/scripts/Python/modules/readline/CMakeLists.txt

Modified: lldb/trunk/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/CMakeLists.txt?rev=333041&r1=333040&r2=333041&view=diff
==
--- lldb/trunk/CMakeLists.txt (original)
+++ lldb/trunk/CMakeLists.txt Tue May 22 16:24:46 2018
@@ -29,6 +29,8 @@ endif ()
 set(LLDB_DISABLE_LIBEDIT ${LLDB_DEFAULT_DISABLE_LIBEDIT} CACHE BOOL "Disables 
the use of editline.")
 if (LLDB_DISABLE_LIBEDIT)
   add_definitions( -DLLDB_DISABLE_LIBEDIT )
+else()
+  find_package(LibEdit REQUIRED)
 endif()
 
 if(APPLE)

Added: lldb/trunk/cmake/modules/FindLibEdit.cmake
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/cmake/modules/FindLibEdit.cmake?rev=333041&view=auto
==
--- lldb/trunk/cmake/modules/FindLibEdit.cmake (added)
+++ lldb/trunk/cmake/modules/FindLibEdit.cmake Tue May 22 16:24:46 2018
@@ -0,0 +1,62 @@
+#.rst:
+# FindLibEdit
+# ---
+#
+# Find libedit library and headers
+#
+# The module defines the following variables:
+#
+# ::
+#
+#   libedit_FOUND - true if libedit was found
+#   libedit_INCLUDE_DIRS  - include search path
+#   libedit_LIBRARIES - libraries to link
+#   libedit_VERSION   - version number
+
+if(libedit_INCLUDE_DIRS AND libedit_LIBRARIES)
+  set(libedit_FOUND TRUE)
+else()
+  find_package(PkgConfig QUIET)
+  pkg_check_modules(PC_LIBEDIT QUIET libedit)
+
+  find_path(libedit_INCLUDE_DIRS
+NAMES
+  histedit.h
+HINTS
+  ${PC_LIBEDIT_INCLUDEDIR}
+  ${PC_LIBEDIT_INCLUDE_DIRS}
+  ${CMAKE_INSTALL_FULL_INCLUDEDIR})
+  find_library(libedit_LIBRARIES
+   NAMES
+ edit libedit
+   HINTS
+ ${PC_LIBEDIT_LIBDIR}
+ ${PC_LIBEDIT_LIBRARY_DIRS}
+ ${CMAKE_INSTALL_FULL_LIBDIR})
+
+  if(libedit_INCLUDE_DIRS AND EXISTS "${libedit_INCLUDE_DIRS}/histedit.h")
+file(STRINGS "${libedit_INCLUDE_DIRS}/histedit.h"
+ libedit_major_version_str
+ REGEX "^#define[ \t]+LIBEDIT_MAJOR[ \t]+[0-9]+")
+string(REGEX REPLACE "^#define[ \t]+LIBEDIT_MAJOR[ \t]+([0-9]+)" "\\1"
+   LIBEDIT_MAJOR_VERSION "${libedit_major_version_str}")
+
+file(STRINGS "${libedit_INCLUDE_DIRS}/histedit.h"
+ libedit_minor_version_str
+ REGEX "^#define[ \t]+LIBEDIT_MINOR[ \t]+[0-9]+")
+string(REGEX REPLACE "^#define[ \t]+LIBEDIT_MINOR[ \t]+([0-9]+)" "\\1"
+   LIBEDIT_MINOR_VERSION "${libedit_minor_version_str}")
+
+set(libedit_VERSION_STRING 
"${libedit_major_version}.${libedit_minor_version}")
+  endif()
+
+  include(FindPackageHandleStandardArgs)
+  find_package_handle_standard_args(libedit
+REQUIRED_VARS
+  libedit_INCLUDE_DIRS
+  libedit_LIBRARIES
+VERSION_VAR
+  libedit_VERSION_STRING)
+  mark_as_advanced(libedit_INCLUDE_DIRS libedit_LIBRARIES)
+endif()
+

Modified: lldb/trunk/scripts/Python/modules/readline/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/scripts/Python/modules/readline/CMakeLists.txt?rev=333041&r1=333040&r2=333041&view=diff
==
--- lldb/trunk/scripts/Python/modules/readline/CMakeLists.txt (original)
+++ lldb/trunk/scripts/Python/modules/readline/CMakeLists.txt Tue May 22 
16:24:46 2018
@@ -6,9 +6,12 @@ SET(PYTHON_DIRECTORY python${PYTHON_VERS
 # Build the readline python module
 include_directories(${PYTHON_INCLUDE_DIR})
 add_library(readline SHARED readline.cpp)
+target_include_directories(readline
+   PRIVATE
+ ${libedit_INCLUDE_DIRS})
 
 if (NOT LLDB_DISABLE_LIBEDIT)
-  target_link_libraries(readline ${PYTHON_LIBRARY} edit)
+  target_link_libraries(readline ${PYTHON_LIBRARY} ${libedit_LIBRARIES})
 else()
   target_link_libraries(readline ${PYTHON_LIBRARY})
 endif()


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

[Lldb-commits] [PATCH] D46726: build: use cmake to find the libedit content

2018-05-22 Thread Saleem Abdulrasool via Phabricator via lldb-commits 
compnerd closed this revision.
compnerd added a comment.

SVN r333041


https://reviews.llvm.org/D46726



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

[Lldb-commits] [PATCH] D47235: Move ModuleList's dependency on clangDriver into Host

2018-05-22 Thread Adrian Prantl via Phabricator via lldb-commits 
aprantl created this revision.
aprantl added reviewers: zturner, jingham.
Herald added subscribers: jkorous, MaskRay, ioeric, ilya-biryukov, mgorny.

@zturner wrote:

> This change has introduced a dependency from Core -> clang Driver (due to 
> #include "clang/Driver/Driver.h" in ModuleList.cpp).  Can you please try to 
> find a way to remove this dependency?

This is implementing Jim's suggestions in 
http://lists.llvm.org/pipermail/lldb-commits/Week-of-Mon-20180521/041010.html .
This certainly makes sense from a logical perspective, but I'm not sure whether 
this addresses Zachary's concerns. Let me know what you think.


https://reviews.llvm.org/D47235

Files:
  include/lldb/Host/HostInfoBase.h
  source/Core/ModuleList.cpp
  source/Host/CMakeLists.txt
  source/Host/common/HostInfoBase.cpp


Index: source/Host/common/HostInfoBase.cpp
===
--- source/Host/common/HostInfoBase.cpp
+++ source/Host/common/HostInfoBase.cpp
@@ -25,6 +25,8 @@
 #include "llvm/Support/Threading.h"
 #include "llvm/Support/raw_ostream.h"
 
+#include "clang/Driver/Driver.h"
+
 #include 
 #include 
 
@@ -387,3 +389,9 @@
 break;
   }
 }
+
+std::string HostInfoBase::GetDefaultClangModuleCachePath() {
+  llvm::SmallString<128> path;
+  clang::driver::Driver::getDefaultModuleCachePath(path);
+  return path.str();
+}
Index: source/Host/CMakeLists.txt
===
--- source/Host/CMakeLists.txt
+++ source/Host/CMakeLists.txt
@@ -185,7 +185,8 @@
 lldbUtility
 ${LLDB_PLUGINS}
 ${EXTRA_LIBS}
-  
+clangDriver
+
   LINK_COMPONENTS
 Object
 Support
Index: source/Core/ModuleList.cpp
===
--- source/Core/ModuleList.cpp
+++ source/Core/ModuleList.cpp
@@ -13,6 +13,7 @@
 #include "lldb/Core/ModuleSpec.h"
 #include "lldb/Host/FileSystem.h"
 #include "lldb/Host/Symbols.h"
+#include "lldb/Host/HostInfoBase.h"
 #include "lldb/Interpreter/OptionValueProperties.h"
 #include "lldb/Interpreter/OptionValueFileSpec.h"
 #include "lldb/Interpreter/Property.h"
@@ -34,7 +35,6 @@
 #include "llvm/Support/FileSystem.h"
 #include "llvm/Support/Threading.h"
 #include "llvm/Support/raw_ostream.h" // for fs
-#include "clang/Driver/Driver.h"
 
 #include  // for operator!=, time_point
 #include  // for shared_ptr
@@ -85,9 +85,7 @@
   m_collection_sp.reset(new OptionValueProperties(ConstString("symbols")));
   m_collection_sp->Initialize(g_properties);
 
-  llvm::SmallString<128> path;
-  clang::driver::Driver::getDefaultModuleCachePath(path);
-  SetClangModulesCachePath(path);
+  SetClangModulesCachePath(HostInfoBase::GetDefaultClangModuleCachePath());
 }
 
 bool ModuleListProperties::GetEnableExternalLookup() const {
Index: include/lldb/Host/HostInfoBase.h
===
--- include/lldb/Host/HostInfoBase.h
+++ include/lldb/Host/HostInfoBase.h
@@ -90,6 +90,9 @@
   //---
   static ArchSpec GetAugmentedArchSpec(llvm::StringRef triple);
 
+  /// Return the default path for the Clang module cache.
+  static std::string GetDefaultClangModuleCachePath();
+  
 protected:
   static bool ComputeSharedLibraryDirectory(FileSpec &file_spec);
   static bool ComputeSupportExeDirectory(FileSpec &file_spec);


Index: source/Host/common/HostInfoBase.cpp
===
--- source/Host/common/HostInfoBase.cpp
+++ source/Host/common/HostInfoBase.cpp
@@ -25,6 +25,8 @@
 #include "llvm/Support/Threading.h"
 #include "llvm/Support/raw_ostream.h"
 
+#include "clang/Driver/Driver.h"
+
 #include 
 #include 
 
@@ -387,3 +389,9 @@
 break;
   }
 }
+
+std::string HostInfoBase::GetDefaultClangModuleCachePath() {
+  llvm::SmallString<128> path;
+  clang::driver::Driver::getDefaultModuleCachePath(path);
+  return path.str();
+}
Index: source/Host/CMakeLists.txt
===
--- source/Host/CMakeLists.txt
+++ source/Host/CMakeLists.txt
@@ -185,7 +185,8 @@
 lldbUtility
 ${LLDB_PLUGINS}
 ${EXTRA_LIBS}
-  
+clangDriver
+
   LINK_COMPONENTS
 Object
 Support
Index: source/Core/ModuleList.cpp
===
--- source/Core/ModuleList.cpp
+++ source/Core/ModuleList.cpp
@@ -13,6 +13,7 @@
 #include "lldb/Core/ModuleSpec.h"
 #include "lldb/Host/FileSystem.h"
 #include "lldb/Host/Symbols.h"
+#include "lldb/Host/HostInfoBase.h"
 #include "lldb/Interpreter/OptionValueProperties.h"
 #include "lldb/Interpreter/OptionValueFileSpec.h"
 #include "lldb/Interpreter/Property.h"
@@ -34,7 +35,6 @@
 #include "llvm/Support/FileSystem.h"
 #include "llvm/Support/Threading.h"
 #include "llvm/Support/raw_ostream.h" // for fs
-#include "clang/Driver/Driver.h"
 
 #include  // for operator!=, time_point
 #include  //

[Lldb-commits] [PATCH] D47232: Break dependency from Expression -> Commands

2018-05-22 Thread Jim Ingham via Phabricator via lldb-commits 
jingham requested changes to this revision.
jingham added a comment.
This revision now requires changes to proceed.

The REPL is just a mode of the expression command.  You invoke it by saying:

(lldb) expr --repl --

or you can add any other options to it that you want, including flags like -i 
or -u.

So it seems odd to handle the passing of one subset of those options from the 
expression command to this expression mode differently from all the other 
options you pass to it (e.g. the variable object - i.e. result printing - 
options.)


https://reviews.llvm.org/D47232



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

[Lldb-commits] [PATCH] D47232: Break dependency from Expression -> Commands

2018-05-22 Thread Jim Ingham via Phabricator via lldb-commits 
jingham added a comment.

Perhaps a better way to handle this is to think of REPL.cpp/h as adjuncts of 
CommandObjectExpression.cpp/h - they mostly define the fancy IOHandler that 
gets pushed when you run the command in this mode.  I think it would be fine to 
move them to Command, at which point using all the OptionGroups would be 
expected.


https://reviews.llvm.org/D47232



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

[Lldb-commits] [PATCH] D45224: [SymbolFilePDB] Add support for resolving variable symbols

2018-05-22 Thread Aaron Smith via Phabricator via lldb-commits 
This revision was not accepted when it landed; it landed in state "Needs 
Review".
This revision was automatically updated to reflect the committed changes.
Closed by commit rL333049: [SymbolFilePDB] Add support for resolving variable 
symbols (authored by asmith, committed by ).

Changed prior to commit:
  https://reviews.llvm.org/D45224?vs=140842&id=148144#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D45224

Files:
  lldb/trunk/lit/SymbolFile/PDB/Inputs/VariablesTest.cpp
  lldb/trunk/lit/SymbolFile/PDB/variables.test
  lldb/trunk/source/Plugins/SymbolFile/PDB/SymbolFilePDB.cpp
  lldb/trunk/source/Plugins/SymbolFile/PDB/SymbolFilePDB.h

Index: lldb/trunk/lit/SymbolFile/PDB/variables.test
===
--- lldb/trunk/lit/SymbolFile/PDB/variables.test
+++ lldb/trunk/lit/SymbolFile/PDB/variables.test
@@ -0,0 +1,58 @@
+REQUIRES: windows
+RUN: clang-cl /Z7 /c %S/Inputs/VariablesTest.cpp /o %T/VariablesTest.cpp.obj
+RUN: link %T/VariablesTest.cpp.obj /DEBUG /nodefaultlib /ENTRY:main /OUT:%T/VariablesTest.cpp.exe
+RUN: lldb-test symbols %T/VariablesTest.cpp.exe | FileCheck %s
+
+CHECK: Module [[MOD:.*]]
+CHECK: SymbolVendor ([[MOD]])
+CHECK: CompileUnit{{.*}}, language = "c++", file = '{{.*}}\VariablesTest.cpp'
+CHECK-DAG:   Variable{{.*}}, name = "g_IntVar"
+CHECK-SAME:  scope = global, external
+CHECK-DAG:   Variable{{.*}}, name = "m_StaticClassMember"
+CHECK-SAME:  scope = global, external
+CHECK-DAG:   Variable{{.*}}, name = "g_pConst"
+CHECK-SAME:  scope = global, external
+CHECK-DAG:   Variable{{.*}}, name = "same_name_var"
+CHECK-SAME:  scope = global, external
+CHECK-DAG:   Variable{{.*}}, name = "g_EnumVar"
+CHECK-SAME:  scope = global, external
+CHECK-DAG:   Variable{{.*}}, name = "g_tls"
+CHECK-SAME:  scope = thread local, external
+CHECK-DAG:   Variable{{.*}}, name = "ClassVar"
+CHECK-SAME:  scope = global, external
+CHECK-DAG:   Variable{{.*}}, name = "g_Const"
+CHECK-SAME:  scope = ??? (2)
+
+CHECK-DAG:   Function{[[FID1:.*]]}, mangled = ?f@@YAHHH@Z
+CHECK-NEXT:  Block{[[FID1]]}
+CHECK-DAG: Variable{{.*}}, name = "var_arg1"
+CHECK-SAME:scope = parameter
+CHECK-DAG: Variable{{.*}}, name = "var_arg2"
+CHECK-SAME:scope = parameter
+CHECK-DAG: Variable{{.*}}, name = "same_name_var"
+CHECK-SAME:scope = local
+
+CHECK-DAG:   Function{[[FID2:.*]]}, mangled = main
+CHECK-NEXT:  Block{[[FID2]]}
+CHECK-DAG: Variable{{.*}}, name = "same_name_var"
+CHECK-SAME:scope = local
+CHECK-DAG: Variable{{.*}}, name = "local_const"
+CHECK-SAME:scope = local
+CHECK-DAG: Variable{{.*}}, name = "local_pCString"
+CHECK-SAME:scope = local
+CHECK-DAG: Variable{{.*}}, name = "a"
+CHECK-SAME:scope = local
+
+CHECK-DAG:   Function{[[FID3:.*]]}, mangled = ??0Class@@QEAA@H@Z
+CHECK-NEXT:  Block{[[FID3]]}
+CHECK-DAG: Variable{{.*}}, name = "this"
+CHECK-SAME:scope = parameter
+CHECK-SAME:artificial
+CHECK-DAG: Variable{{.*}}, name = "a"
+CHECK-SAME:scope = parameter
+
+CHECK-DAG:   Function{[[FID4:.*]]}, mangled = ?Func@Class@@QEAAXXZ
+CHECK-NEXT:  Block{[[FID4]]}
+CHECK-DAG: Variable{{.*}}, name = "this"
+CHECK-SAME:scope = parameter
+CHECK-SAME:artificial
\ No newline at end of file
Index: lldb/trunk/lit/SymbolFile/PDB/Inputs/VariablesTest.cpp
===
--- lldb/trunk/lit/SymbolFile/PDB/Inputs/VariablesTest.cpp
+++ lldb/trunk/lit/SymbolFile/PDB/Inputs/VariablesTest.cpp
@@ -0,0 +1,50 @@
+typedef int IntTypedef;
+IntTypedef g_IntVar;  // Testing globals.
+
+typedef enum Enum { // Testing constants.
+  RED,
+  GREEN,
+  BLUE
+} EnumTypedef;
+EnumTypedef g_EnumVar;  // Testing members.
+
+// FIXME: `sg_IntVar` appears both in global scope's children and compiland's
+// children but with different symbol's id.
+static int sg_IntVar = -1;  // Testing file statics.
+
+// FIXME: `g_Const` appears both in global scope's children and compiland's
+// children but with different symbol's id.
+const int g_Const = 0x88;  // Testing constant data.
+const int *g_pConst = &g_Const; // Avoid optimizing the const away
+
+thread_local int g_tls = 0;  // Testing thread-local storage.
+
+class Class {
+  static int m_StaticClassMember;
+public:
+  explicit Class(int a) {}
+  void Func() {}
+};
+int Class::m_StaticClassMember = 10; // Testing static class members.
+Class ClassVar(1);
+
+int f(int var_arg1, int var_arg2) {  // Testing parameters.
+  long same_name_var = -1;
+  return 1;
+}
+
+int same_name_var = 100;
+int main() {
+  int same_name_var = 0;  // Testing locals.
+  const char local_const = 0x1;
+
+  // FIXME: 'local_CString` is not found through compiland's children.
+  const char local_CString[] = "abc";  // Testing constant string.
+  const char *local_pCString = local_CString; // Avoid optimizing the const away
+
+  int a = 10;
+  a++;
+
+  ClassVar.Func();
+  return 0;
+}
Index: lldb/trunk/source/Plugins/SymbolFile/PDB/SymbolFil

[Lldb-commits] [PATCH] D47235: Move ModuleList's dependency on clangDriver into Host

2018-05-22 Thread Zachary Turner via Phabricator via lldb-commits 
zturner added a subscriber: aprantl.
zturner added a comment.

Yea I don’t think this addresses the problem. We should be able to link
against parts of lldb without a dependency on clang. Since this is about
configuring something related to clang, it seems like it should be isolated
to some part of lldb that interfaces with clang


https://reviews.llvm.org/D47235



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

Re: [Lldb-commits] [PATCH] D47235: Move ModuleList's dependency on clangDriver into Host

2018-05-22 Thread Zachary Turner via lldb-commits 
Yea I don’t think this addresses the problem. We should be able to link
against parts of lldb without a dependency on clang. Since this is about
configuring something related to clang, it seems like it should be isolated
to some part of lldb that interfaces with clang
On Tue, May 22, 2018 at 4:32 PM Adrian Prantl via Phabricator <
revi...@reviews.llvm.org> wrote:

> aprantl created this revision.
> aprantl added reviewers: zturner, jingham.
> Herald added subscribers: jkorous, MaskRay, ioeric, ilya-biryukov, mgorny.
>
> @zturner wrote:
>
> > This change has introduced a dependency from Core -> clang Driver (due
> to #include "clang/Driver/Driver.h" in ModuleList.cpp).  Can you please try
> to find a way to remove this dependency?
>
> This is implementing Jim's suggestions in
> http://lists.llvm.org/pipermail/lldb-commits/Week-of-Mon-20180521/041010.html
> .
> This certainly makes sense from a logical perspective, but I'm not sure
> whether this addresses Zachary's concerns. Let me know what you think.
>
>
> https://reviews.llvm.org/D47235
>
> Files:
>   include/lldb/Host/HostInfoBase.h
>   source/Core/ModuleList.cpp
>   source/Host/CMakeLists.txt
>   source/Host/common/HostInfoBase.cpp
>
>
> Index: source/Host/common/HostInfoBase.cpp
> ===
> --- source/Host/common/HostInfoBase.cpp
> +++ source/Host/common/HostInfoBase.cpp
> @@ -25,6 +25,8 @@
>  #include "llvm/Support/Threading.h"
>  #include "llvm/Support/raw_ostream.h"
>
> +#include "clang/Driver/Driver.h"
> +
>  #include 
>  #include 
>
> @@ -387,3 +389,9 @@
>  break;
>}
>  }
> +
> +std::string HostInfoBase::GetDefaultClangModuleCachePath() {
> +  llvm::SmallString<128> path;
> +  clang::driver::Driver::getDefaultModuleCachePath(path);
> +  return path.str();
> +}
> Index: source/Host/CMakeLists.txt
> ===
> --- source/Host/CMakeLists.txt
> +++ source/Host/CMakeLists.txt
> @@ -185,7 +185,8 @@
>  lldbUtility
>  ${LLDB_PLUGINS}
>  ${EXTRA_LIBS}
> -
> +clangDriver
> +
>LINK_COMPONENTS
>  Object
>  Support
> Index: source/Core/ModuleList.cpp
> ===
> --- source/Core/ModuleList.cpp
> +++ source/Core/ModuleList.cpp
> @@ -13,6 +13,7 @@
>  #include "lldb/Core/ModuleSpec.h"
>  #include "lldb/Host/FileSystem.h"
>  #include "lldb/Host/Symbols.h"
> +#include "lldb/Host/HostInfoBase.h"
>  #include "lldb/Interpreter/OptionValueProperties.h"
>  #include "lldb/Interpreter/OptionValueFileSpec.h"
>  #include "lldb/Interpreter/Property.h"
> @@ -34,7 +35,6 @@
>  #include "llvm/Support/FileSystem.h"
>  #include "llvm/Support/Threading.h"
>  #include "llvm/Support/raw_ostream.h" // for fs
> -#include "clang/Driver/Driver.h"
>
>  #include  // for operator!=, time_point
>  #include  // for shared_ptr
> @@ -85,9 +85,7 @@
>m_collection_sp.reset(new
> OptionValueProperties(ConstString("symbols")));
>m_collection_sp->Initialize(g_properties);
>
> -  llvm::SmallString<128> path;
> -  clang::driver::Driver::getDefaultModuleCachePath(path);
> -  SetClangModulesCachePath(path);
> +
> SetClangModulesCachePath(HostInfoBase::GetDefaultClangModuleCachePath());
>  }
>
>  bool ModuleListProperties::GetEnableExternalLookup() const {
> Index: include/lldb/Host/HostInfoBase.h
> ===
> --- include/lldb/Host/HostInfoBase.h
> +++ include/lldb/Host/HostInfoBase.h
> @@ -90,6 +90,9 @@
>
>  //---
>static ArchSpec GetAugmentedArchSpec(llvm::StringRef triple);
>
> +  /// Return the default path for the Clang module cache.
> +  static std::string GetDefaultClangModuleCachePath();
> +
>  protected:
>static bool ComputeSharedLibraryDirectory(FileSpec &file_spec);
>static bool ComputeSupportExeDirectory(FileSpec &file_spec);
>
>
>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits