Re: [Lldb-commits] [PATCH] D18519: Allow building LLDB on Windows with MinGW 64/4.9.2 and later

2016-03-29 Thread Pavel Labath via lldb-commits 
labath added a subscriber: labath.
labath added a comment.

Some more "why do this?" questions from me...

I was looking into using mingw a couple weeks ago, but gave up, so I'm 
interested to see your progress here. However, I'd like to avoid adding hacks 
into the cmake files if it is not completely necessary, as it increases the 
future maintenance burden.



Comment at: CMakeLists.txt:3
@@ -2,1 +2,3 @@
 
+if(MINGW_DEBUG)
+# force debugging info into lldb sources

Why do we need this? Why is `-DCMAKE_BUILD_TYPE=Debug` not sufficient?


Comment at: cmake/modules/LLDBConfig.cmake:224
@@ -223,2 +223,3 @@
 # Disable Clang warnings
+if (CMAKE_CXX_COMPILER_ID MATCHES "Clang")
 check_cxx_compiler_flag("-Wno-deprecated-register"

Why is this necessary? The whole purpose `check_cxx_compiler_flag` is to check 
whether a compiler supports some flag. Hardcoding the check ourselves makes 
that kinda pointless. What error were you getting here?


Comment at: tools/argdumper/CMakeLists.txt:5
@@ -4,1 +4,3 @@
 
+if(MINGW)
+# link directly against the dll file

Why is this necessary? This seems like it's trying to work around some bug 
present elsewhere..


Comment at: tools/driver/CMakeLists.txt:20
@@ -19,1 +19,3 @@
 
+if(MINGW)
+# link directly against the dll file

Same question.


http://reviews.llvm.org/D18519



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

Re: [Lldb-commits] [PATCH] D18519: Allow building LLDB on Windows with MinGW 64/4.9.2 and later

2016-03-29 Thread Eran Ifrah via lldb-commits 
eran.ifrah added a comment.





Comment at: CMakeLists.txt:3
@@ -2,1 +2,3 @@
 
+if(MINGW_DEBUG)
+# force debugging info into lldb sources

labath wrote:
> Why do we need this? Why is `-DCMAKE_BUILD_TYPE=Debug` not sufficient?
No. As I mentioned in my previous comment the object file generated are too big 
for as.exe to handle
and it aborts. This results from Clang files (not LLDB). As a workaround and I 
added this command line directive to be able to produce debug builds of LLDB so 
I can actually debug them and provide some more insights if needed


Comment at: cmake/modules/LLDBConfig.cmake:224
@@ -223,2 +223,3 @@
 # Disable Clang warnings
+if (CMAKE_CXX_COMPILER_ID MATCHES "Clang")
 check_cxx_compiler_flag("-Wno-deprecated-register"

labath wrote:
> Why is this necessary? The whole purpose `check_cxx_compiler_flag` is to 
> check whether a compiler supports some flag. Hardcoding the check ourselves 
> makes that kinda pointless. What error were you getting here?
Tons of warnings about unrecognized command line directive (or something 
similar) - can't remember the exact warning message - but its something like 
this. If really need to know the warning message, I can re-compile without this 
change


Comment at: source/Host/common/OptionParser.cpp:9-11
@@ -8,2 +8,5 @@
 
//===--===//
+#ifdef __MINGW32__
+#define _BSD_SOURCE
+#endif
 

zturner wrote:
> Not sure what `_BSD_SOURCE` is, can you explain what this does?  In any case, 
> it should go in `Host/windows/win32.h` along with other similar preprocessor 
> defines.
This is needed to workaround bug with MinGW + getopt, without this macro 
defined (before any file in the source) optreset is undeclared.
I moved it to Win32.h and added a big comment that explains why this is needed


Comment at: source/Host/windows/EditLineWin.cpp:45
@@ -44,3 +44,3 @@
 
-#if !defined( _WIP_INPUT_METHOD )
+#if !defined( _WIP_INPUT_METHOD ) && !defined(__MINGW32__)
 

zturner wrote:
> This is weird but I honestly don't even know what `_WIP_INPUT_METHOD` is.  My 
> guess is it's not even relevant anymore.
> 
> Anyway, does MinGW already have an implementation of Editline?
I am not really sure what Editline is (need to google that...) - this macro 
simply makes the code compile ;)


Comment at: source/Host/windows/FileSystem.cpp:268
@@ +267,3 @@
+#else
+file = fopen(path, mode);
+#endif

amccarth wrote:
> This code just went through the trouble of converting the path from UTF-8 to 
> a wide string.  If you can't use `_wfopen_s`, it seems you should skip more 
> of this function.  (I'm also surprised you didn't have to make a similar 
> change in more places.)
I moved the `__MINGW32__` a bit higher to exclude more parts of the code 
(indeed, the conversion to UTF8 can be avoided)


Comment at: source/Host/windows/ProcessRunLock.cpp:3-5
@@ -2,13 +2,5 @@
 #include "lldb/Host/windows/windows.h"
-
-namespace
-{
-#if defined(__MINGW32__)
-// Taken from WinNT.h
-typedef struct _RTL_SRWLOCK {
-PVOID Ptr;
-} RTL_SRWLOCK, *PRTL_SRWLOCK;
-
-// Taken from WinBase.h
-typedef RTL_SRWLOCK SRWLOCK, *PSRWLOCK;
+#ifdef __MINGW32__
+#define _WIN32_WINNT 0x0600
+#include 
 #endif

zturner wrote:
> This should be in `Host/windows/win32.h` at the very least, but perhaps even 
> in CMake files.
`_WIN32_WINNT` is now defined in `LLDBConfig.cmake` 


Comment at: source/Plugins/ObjectFile/PECOFF/WindowsMiniDump.cpp:30
@@ -29,3 +29,3 @@
 if (!process_sp) return false;
-#ifdef _WIN32
+#if defined(WIN32) && !defined(__MINGW32__)
 HANDLE process_handle = ::OpenProcess(PROCESS_QUERY_INFORMATION | 
PROCESS_VM_READ, FALSE, process_sp->GetID());

amccarth wrote:
> zturner wrote:
> > Three things here.
> > 
> >   # `_WIN32` got changed to `WIN32`.  Was this intentional or accidental?
> >   # The given conditional appears to be equivalent to `#if 
> > defined(_MSC_VER)` which is simpler to understand.
> >   # Why disable this for MinGW builds?  Other native Win32 APIs are 
> > available, is this one not?
> What the goal of skipping this here?  As far as I can see, this is just 
> calling Win32 APIs, so I'd expect those to be available regardless of which 
> compiler you're using.
The function `MiniDumpWriteDump` simply does not exist in my MinGW build (using 
TDM-GCC-64/4.9.2)
I fixed the condition to `#if defined(_MSC_VER)` which is indeed simpler to 
understand


Comment at: source/Plugins/Process/Windows/Common/ProcessWindowsLog.h:107
@@ -95,1 +106,3 @@
+#define WINWARN_IFALL(Flags, ...) 
+#endif
 

amccarth wrote:
> This will silently break logging on Windows.  Why is this necessary?
I don't like this either, but it causes alot of build errors with `std::atomic` 
it wa

[Lldb-commits] [lldb] r264713 - Add missing swig wrappers for r264662

2016-03-29 Thread Pavel Labath via lldb-commits 
Author: labath
Date: Tue Mar 29 05:41:40 2016
New Revision: 264713

URL: http://llvm.org/viewvc/llvm-project?rev=264713&view=rev
Log:
Add missing swig wrappers for r264662

Modified:
lldb/trunk/scripts/interface/SBExpressionOptions.i

Modified: lldb/trunk/scripts/interface/SBExpressionOptions.i
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/scripts/interface/SBExpressionOptions.i?rev=264713&r1=264712&r2=264713&view=diff
==
--- lldb/trunk/scripts/interface/SBExpressionOptions.i (original)
+++ lldb/trunk/scripts/interface/SBExpressionOptions.i Tue Mar 29 05:41:40 2016
@@ -127,6 +127,11 @@ public:
 bool
 GetAutoApplyFixIts();
 
+bool
+GetTopLevel();
+
+void
+SetTopLevel(bool b = true);
 
 protected:
 


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

Re: [Lldb-commits] [PATCH] D18481: Add argument to expectedFailureAll decorator to xfail for environment variables, and xfail tests for hard float abi and -mthumb on android arm

2016-03-29 Thread Tamas Berghammer via lldb-commits 
tberghammer added a comment.

You can pass extra compiler flags to the test suit with the -E option (haven't 
tested it). I would suggest to use that option and then xfail based on it 
(xfail if extra flags contain -foo).

In long term I would prefer to not add a new option to expectedFailureAll but 
to implement a generic functional style solution where we can just pass in 
arbitrary number of lambda functions to it so the number of arguments aren't 
increasing constantly but it is something what is completely unrelated to this 
patch.


http://reviews.llvm.org/D18481



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

[Lldb-commits] [lldb] r264721 - Add ClangUtil.cpp to the xcode project

2016-03-29 Thread Pavel Labath via lldb-commits 
Author: labath
Date: Tue Mar 29 07:06:37 2016
New Revision: 264721

URL: http://llvm.org/viewvc/llvm-project?rev=264721&view=rev
Log:
Add ClangUtil.cpp to the xcode project

Modified:
lldb/trunk/lldb.xcodeproj/project.pbxproj

Modified: lldb/trunk/lldb.xcodeproj/project.pbxproj
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/lldb.xcodeproj/project.pbxproj?rev=264721&r1=264720&r2=264721&view=diff
==
--- lldb/trunk/lldb.xcodeproj/project.pbxproj (original)
+++ lldb/trunk/lldb.xcodeproj/project.pbxproj Tue Mar 29 07:06:37 2016
@@ -634,6 +634,8 @@
26FFC19914FC072100087D58 /* AuxVector.cpp in Sources */ = {isa 
= PBXBuildFile; fileRef = 26FFC19314FC072100087D58 /* AuxVector.cpp */; };
26FFC19B14FC072100087D58 /* DYLDRendezvous.cpp in Sources */ = 
{isa = PBXBuildFile; fileRef = 26FFC19514FC072100087D58 /* DYLDRendezvous.cpp 
*/; };
26FFC19D14FC072100087D58 /* DynamicLoaderPOSIXDYLD.cpp in 
Sources */ = {isa = PBXBuildFile; fileRef = 26FFC19714FC072100087D58 /* 
DynamicLoaderPOSIXDYLD.cpp */; };
+   304B2E461CAAA57B007829FE /* ClangUtil.cpp in Sources */ = {isa 
= PBXBuildFile; fileRef = 3032B1B61CAAA3D1004BE1AB /* ClangUtil.cpp */; };
+   30B38A001CAAA6D7009524E3 /* ClangUtil.h in Headers */ = {isa = 
PBXBuildFile; fileRef = 3032B1B91CAAA44BE1AB /* ClangUtil.h */; };
30DED5DE1B4ECB49004CC508 /* MainLoopPosix.cpp in Sources */ = 
{isa = PBXBuildFile; fileRef = 30DED5DC1B4ECB17004CC508 /* MainLoopPosix.cpp 
*/; };
332CCB181AFF41620034D4C4 /* SBLanguageRuntime.h in Headers */ = 
{isa = PBXBuildFile; fileRef = 3392EBB71AFF402200858B9F /* SBLanguageRuntime.h 
*/; settings = {ATTRIBUTES = (Public, ); }; };
33E5E8471A674FB60024ED68 /* StringConvert.cpp in Sources */ = 
{isa = PBXBuildFile; fileRef = 33E5E8411A672A240024ED68 /* StringConvert.cpp 
*/; };
@@ -2173,6 +2175,8 @@
26FFC19614FC072100087D58 /* DYLDRendezvous.h */ = {isa = 
PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.c.h; path = 
DYLDRendezvous.h; sourceTree = ""; };
26FFC19714FC072100087D58 /* DynamicLoaderPOSIXDYLD.cpp */ = 
{isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = 
sourcecode.cpp.cpp; path = DynamicLoaderPOSIXDYLD.cpp; sourceTree = ""; 
};
26FFC19814FC072100087D58 /* DynamicLoaderPOSIXDYLD.h */ = {isa 
= PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.c.h; path 
= DynamicLoaderPOSIXDYLD.h; sourceTree = ""; };
+   3032B1B61CAAA3D1004BE1AB /* ClangUtil.cpp */ = {isa = 
PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.cpp.cpp; 
name = ClangUtil.cpp; path = source/Symbol/ClangUtil.cpp; sourceTree = 
""; };
+   3032B1B91CAAA44BE1AB /* ClangUtil.h */ = {isa = 
PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.c.h; name = 
ClangUtil.h; path = include/lldb/Symbol/ClangUtil.h; sourceTree = ""; };
30DED5DC1B4ECB17004CC508 /* MainLoopPosix.cpp */ = {isa = 
PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.cpp.cpp; 
path = MainLoopPosix.cpp; sourceTree = ""; };
33064C991A5C7A330033D415 /* UriParser.cpp */ = {isa = 
PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.cpp.cpp; 
name = UriParser.cpp; path = source/Utility/UriParser.cpp; sourceTree = 
""; };
33064C9B1A5C7A490033D415 /* UriParser.h */ = {isa = 
PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.c.h; name = 
UriParser.h; path = source/Utility/UriParser.h; sourceTree = ""; };
@@ -4368,6 +4372,8 @@
26BC7C4B10F1B6C100F91463 /* Symbol */ = {
isa = PBXGroup;
children = (
+   3032B1B91CAAA44BE1AB /* ClangUtil.h */,
+   3032B1B61CAAA3D1004BE1AB /* ClangUtil.cpp */,
6D0F61411C8000A4ECEE /* JavaASTContext.cpp 
*/,
6D0F613C1C80AA8900A4ECEE /* DebugMacros.h */,
6D0F613D1C80AA8900A4ECEE /* JavaASTContext.h */,
@@ -5949,6 +5955,7 @@
AF6335E31C87B21E00F7D554 /* SymbolFilePDB.h in 
Headers */,
4984BA181B979C08008658D4 /* 
ExpressionVariable.h in Headers */,
26C7C4841BFFEA7E009BD01F /* WindowsMiniDump.h 
in Headers */,
+   30B38A001CAAA6D7009524E3 /* ClangUtil.h in 
Headers */,
AF8AD62F1BEC28A400150209 /* 
PlatformAppleTVSimulator.h in Headers */,
AF8AD63A1BEC28C400150209 /* 
PlatformRemoteAppleWatch.h in Headers */,
257906651BD5AFD000178368 /* Acceptor.h in 
Headers */,
@@ -6646,6 +6653,7 @@

[Lldb-commits] [PATCH] D18547: Fix infinite recursion in DWO file parsing

2016-03-29 Thread Pavel Labath via lldb-commits 
labath created this revision.
labath added reviewers: tberghammer, clayborg.
labath added a subscriber: lldb-commits.

Since r264316, clang started adding DW_AT_GNU_dwo_name attribute to dwo files 
(previously, this
attribute was only present in main object files), breaking pretty much every 
dwo test. The
problem was that we were treating the presence of said attribute as a signal 
that we should look
for information in an external object file, and caused us to enter an infinite 
loop. I fix this
by making sure we do not go looking for an external dwo file if we already 
*are* parsing a dwo
file.

http://reviews.llvm.org/D18547

Files:
  source/Plugins/SymbolFile/DWARF/DWARFCompileUnit.cpp
  source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
  source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h
  source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDwo.h

Index: source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDwo.h
===
--- source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDwo.h
+++ source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDwo.h
@@ -38,6 +38,12 @@
 lldb_private::TypeSystem*
 GetTypeSystemForLanguage(lldb::LanguageType language) override;
 
+std::unique_ptr
+GetDWOForCompileUnit(DWARFCompileUnit &dwarf_cu, const DWARFDebugInfoEntry &cu_die) override
+{
+return nullptr;
+}
+
 protected:
 void
 LoadSectionData (lldb::SectionType sect_type, lldb_private::DWARFDataExtractor& data) override;
Index: source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h
===
--- source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h
+++ source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h
@@ -58,6 +58,7 @@
 class DWARFDIECollection;
 class DWARFFormValue;
 class SymbolFileDWARFDebugMap;
+class SymbolFileDWARFDwo;
 
 #define DIE_IS_BEING_PARSED ((lldb_private::Type*)1)
 
@@ -329,6 +330,9 @@
 lldb::ModuleSP
 GetDWOModule (lldb_private::ConstString name);
 
+virtual std::unique_ptr
+GetDWOForCompileUnit(DWARFCompileUnit &dwarf_cu, const DWARFDebugInfoEntry &cu_die);
+
 protected:
 typedef llvm::DenseMap DIEToTypePtr;
 typedef llvm::DenseMap DIEToVariableSP;
Index: source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
===
--- source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
+++ source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
@@ -1763,6 +1763,38 @@
 return lldb::ModuleSP();
 }
 
+std::unique_ptr
+SymbolFileDWARF::GetDWOForCompileUnit(DWARFCompileUnit &dwarf_cu, const DWARFDebugInfoEntry &cu_die)
+{
+const char *dwo_name = cu_die.GetAttributeValueAsString(this, &dwarf_cu, DW_AT_GNU_dwo_name, nullptr);
+if (!dwo_name)
+return nullptr;
+
+FileSpec dwo_file(dwo_name, true);
+if (dwo_file.IsRelative())
+{
+const char *comp_dir = cu_die.GetAttributeValueAsString(this, &dwarf_cu, DW_AT_comp_dir, nullptr);
+if (!comp_dir)
+return nullptr;
+
+dwo_file.SetFile(comp_dir, true);
+dwo_file.AppendPathComponent(dwo_name);
+}
+
+if (!dwo_file.Exists())
+return nullptr;
+
+const lldb::offset_t file_offset = 0;
+DataBufferSP dwo_file_data_sp;
+lldb::offset_t dwo_file_data_offset = 0;
+ObjectFileSP dwo_obj_file = ObjectFile::FindPlugin(GetObjectFile()->GetModule(), &dwo_file, file_offset,
+   dwo_file.GetByteSize(), dwo_file_data_sp, dwo_file_data_offset);
+if (dwo_obj_file == nullptr)
+return nullptr;
+
+return llvm::make_unique(dwo_obj_file, &dwarf_cu);
+}
+
 void
 SymbolFileDWARF::UpdateExternalModuleListIfNeeded()
 {
Index: source/Plugins/SymbolFile/DWARF/DWARFCompileUnit.cpp
===
--- source/Plugins/SymbolFile/DWARF/DWARFCompileUnit.cpp
+++ source/Plugins/SymbolFile/DWARF/DWARFCompileUnit.cpp
@@ -311,46 +311,12 @@
 {
 assert (m_die_array.empty() && "Compile unit DIE already added");
 AddDIE(die);
-
-DWARFDebugInfoEntry& cu_die = m_die_array.front();
 
-const char* dwo_name = cu_die.GetAttributeValueAsString(m_dwarf2Data,
-this,
-DW_AT_GNU_dwo_name,
-nullptr);
-if (!dwo_name)
+const DWARFDebugInfoEntry &cu_die = m_die_array.front();
+std::unique_ptr dwo_symbol_file = m_dwarf2Data->GetDWOForCompileUnit(*this, cu_die);
+if (!dwo_symbol_file)
 return;
 
-FileSpec dwo_file(dwo_name, true);
-if (dwo_file.IsRelative())
-{
-const char* comp_dir = cu_die.GetAttributeValueAsString(m_dwarf2Data,
-this,
-DW_AT_comp_dir,

Re: [Lldb-commits] [PATCH] D18547: Fix infinite recursion in DWO file parsing

2016-03-29 Thread Tamas Berghammer via lldb-commits 
tberghammer accepted this revision.
tberghammer added a comment.
This revision is now accepted and ready to land.

Looks good



Comment at: source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h:334
@@ +333,3 @@
+virtual std::unique_ptr
+GetDWOForCompileUnit(DWARFCompileUnit &dwarf_cu, const DWARFDebugInfoEntry 
&cu_die);
+

I would rename it to GetDwoSymbolFileForCompileUnit() as DWO in its own 
doesn't mean too much.


http://reviews.llvm.org/D18547



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

Re: [Lldb-commits] [PATCH] D18531: Allow gdbremote process to read modules from memory

2016-03-29 Thread Tamas Berghammer via lldb-commits 
tberghammer added a comment.

What is your opinion about replacing the ProcessGDBRemote::LoadModuleAtAddress 
with the following code:

  lldb::ModuleSP
  ProcessGDBRemote::LoadModuleAtAddress (const FileSpec &file, lldb::addr_t 
base_addr, bool value_is_offset)
  {
  DynamicLoader* loader = GetDynamicLoader();
  if (!loader)
  return nullptr;
  return loader->LoadModuleAtAddress(file, LLDB_INVALID_ADDRESS, base_addr, 
value_is_offset);
  }

I think this should fix your problem while reducing the amount of code 
duplication we already has (I haven't tested it).


http://reviews.llvm.org/D18531



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

Re: [Lldb-commits] [PATCH] D18547: Fix infinite recursion in DWO file parsing

2016-03-29 Thread Pavel Labath via lldb-commits 
labath marked an inline comment as done.
labath added a comment.

@clayborg: I am going to put this in now, to stabilize the buildbot situation. 
I'll be happy to address any concerns in a follow-up commit.


http://reviews.llvm.org/D18547



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

[Lldb-commits] [lldb] r264729 - Fix infinite recursion in DWO file parsing

2016-03-29 Thread Pavel Labath via lldb-commits 
Author: labath
Date: Tue Mar 29 08:42:02 2016
New Revision: 264729

URL: http://llvm.org/viewvc/llvm-project?rev=264729&view=rev
Log:
Fix infinite recursion in DWO file parsing

Summary:
Since r264316, clang started adding DW_AT_GNU_dwo_name attribute to dwo files 
(previously, this
attribute was only present in main object files), breaking pretty much every 
dwo test. The
problem was that we were treating the presence of said attribute as a signal 
that we should look
for information in an external object file, and caused us to enter an infinite 
loop. I fix this
by making sure we do not go looking for an external dwo file if we already 
*are* parsing a dwo
file.

Reviewers: tberghammer, clayborg

Subscribers: lldb-commits

Differential Revision: http://reviews.llvm.org/D18547

Modified:
lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFCompileUnit.cpp
lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h
lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDwo.h

Modified: lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFCompileUnit.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFCompileUnit.cpp?rev=264729&r1=264728&r2=264729&view=diff
==
--- lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFCompileUnit.cpp (original)
+++ lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFCompileUnit.cpp Tue Mar 29 
08:42:02 2016
@@ -311,46 +311,12 @@ DWARFCompileUnit::AddCompileUnitDIE(DWAR
 {
 assert (m_die_array.empty() && "Compile unit DIE already added");
 AddDIE(die);
-
-DWARFDebugInfoEntry& cu_die = m_die_array.front();
 
-const char* dwo_name = cu_die.GetAttributeValueAsString(m_dwarf2Data,
-this,
-DW_AT_GNU_dwo_name,
-nullptr);
-if (!dwo_name)
+const DWARFDebugInfoEntry &cu_die = m_die_array.front();
+std::unique_ptr dwo_symbol_file = 
m_dwarf2Data->GetDwoSymbolFileForCompileUnit(*this, cu_die);
+if (!dwo_symbol_file)
 return;
 
-FileSpec dwo_file(dwo_name, true);
-if (dwo_file.IsRelative())
-{
-const char* comp_dir = cu_die.GetAttributeValueAsString(m_dwarf2Data,
-this,
-DW_AT_comp_dir,
-nullptr);
-if (!comp_dir)
-return;
-
-dwo_file.SetFile(comp_dir, true);
-dwo_file.AppendPathComponent(dwo_name);
-}
-
-if (!dwo_file.Exists())
-return;
-
-DataBufferSP dwo_file_data_sp;
-lldb::offset_t dwo_file_data_offset = 0;
-ObjectFileSP dwo_obj_file = 
ObjectFile::FindPlugin(m_dwarf2Data->GetObjectFile()->GetModule(),
-   &dwo_file,
-   0 /* file_offset */,
-   dwo_file.GetByteSize(),
-   dwo_file_data_sp,
-   dwo_file_data_offset);
-if (dwo_obj_file == nullptr)
-return;
-
-std::unique_ptr dwo_symbol_file(new 
SymbolFileDWARFDwo(dwo_obj_file, this));
-
 DWARFCompileUnit* dwo_cu = dwo_symbol_file->GetCompileUnit();
 if (!dwo_cu)
 return; // Can't fetch the compile unit from the dwo file.

Modified: lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp?rev=264729&r1=264728&r2=264729&view=diff
==
--- lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp (original)
+++ lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp Tue Mar 29 
08:42:02 2016
@@ -1763,6 +1763,38 @@ SymbolFileDWARF::GetDWOModule (ConstStri
 return lldb::ModuleSP();
 }
 
+std::unique_ptr
+SymbolFileDWARF::GetDwoSymbolFileForCompileUnit(DWARFCompileUnit &dwarf_cu, 
const DWARFDebugInfoEntry &cu_die)
+{
+const char *dwo_name = cu_die.GetAttributeValueAsString(this, &dwarf_cu, 
DW_AT_GNU_dwo_name, nullptr);
+if (!dwo_name)
+return nullptr;
+
+FileSpec dwo_file(dwo_name, true);
+if (dwo_file.IsRelative())
+{
+const char *comp_dir = cu_die.GetAttributeValueAsString(this, 
&dwarf_cu, DW_AT_comp_dir, nullptr);
+if (!comp_dir)
+return nullptr;
+
+dwo_file.SetFile(comp_dir, true);
+dwo_file.AppendPathComponent(dwo_name);
+}
+
+if (!dwo_file.Exists())
+return nullptr;
+
+const lldb::offs

Re: [Lldb-commits] [PATCH] D18547: Fix infinite recursion in DWO file parsing

2016-03-29 Thread Pavel Labath via lldb-commits 
This revision was automatically updated to reflect the committed changes.
Closed by commit rL264729: Fix infinite recursion in DWO file parsing (authored 
by labath).

Changed prior to commit:
  http://reviews.llvm.org/D18547?vs=51896&id=51897#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D18547

Files:
  lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFCompileUnit.cpp
  lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
  lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h
  lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDwo.h

Index: lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDwo.h
===
--- lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDwo.h
+++ lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDwo.h
@@ -38,6 +38,12 @@
 lldb_private::TypeSystem*
 GetTypeSystemForLanguage(lldb::LanguageType language) override;
 
+std::unique_ptr
+GetDwoSymbolFileForCompileUnit(DWARFCompileUnit &dwarf_cu, const DWARFDebugInfoEntry &cu_die) override
+{
+return nullptr;
+}
+
 protected:
 void
 LoadSectionData (lldb::SectionType sect_type, lldb_private::DWARFDataExtractor& data) override;
Index: lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h
===
--- lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h
+++ lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h
@@ -58,6 +58,7 @@
 class DWARFDIECollection;
 class DWARFFormValue;
 class SymbolFileDWARFDebugMap;
+class SymbolFileDWARFDwo;
 
 #define DIE_IS_BEING_PARSED ((lldb_private::Type*)1)
 
@@ -329,6 +330,9 @@
 lldb::ModuleSP
 GetDWOModule (lldb_private::ConstString name);
 
+virtual std::unique_ptr
+GetDwoSymbolFileForCompileUnit(DWARFCompileUnit &dwarf_cu, const DWARFDebugInfoEntry &cu_die);
+
 protected:
 typedef llvm::DenseMap DIEToTypePtr;
 typedef llvm::DenseMap DIEToVariableSP;
Index: lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFCompileUnit.cpp
===
--- lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFCompileUnit.cpp
+++ lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFCompileUnit.cpp
@@ -311,46 +311,12 @@
 {
 assert (m_die_array.empty() && "Compile unit DIE already added");
 AddDIE(die);
-
-DWARFDebugInfoEntry& cu_die = m_die_array.front();
-
-const char* dwo_name = cu_die.GetAttributeValueAsString(m_dwarf2Data,
-this,
-DW_AT_GNU_dwo_name,
-nullptr);
-if (!dwo_name)
-return;
-
-FileSpec dwo_file(dwo_name, true);
-if (dwo_file.IsRelative())
-{
-const char* comp_dir = cu_die.GetAttributeValueAsString(m_dwarf2Data,
-this,
-DW_AT_comp_dir,
-nullptr);
-if (!comp_dir)
-return;
 
-dwo_file.SetFile(comp_dir, true);
-dwo_file.AppendPathComponent(dwo_name);
-}
-
-if (!dwo_file.Exists())
+const DWARFDebugInfoEntry &cu_die = m_die_array.front();
+std::unique_ptr dwo_symbol_file = m_dwarf2Data->GetDwoSymbolFileForCompileUnit(*this, cu_die);
+if (!dwo_symbol_file)
 return;
 
-DataBufferSP dwo_file_data_sp;
-lldb::offset_t dwo_file_data_offset = 0;
-ObjectFileSP dwo_obj_file = ObjectFile::FindPlugin(m_dwarf2Data->GetObjectFile()->GetModule(),
-   &dwo_file,
-   0 /* file_offset */,
-   dwo_file.GetByteSize(),
-   dwo_file_data_sp,
-   dwo_file_data_offset);
-if (dwo_obj_file == nullptr)
-return;
-
-std::unique_ptr dwo_symbol_file(new SymbolFileDWARFDwo(dwo_obj_file, this));
-
 DWARFCompileUnit* dwo_cu = dwo_symbol_file->GetCompileUnit();
 if (!dwo_cu)
 return; // Can't fetch the compile unit from the dwo file.
Index: lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
===
--- lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
+++ lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
@@ -1763,6 +1763,38 @@
 return lldb::ModuleSP();
 }
 
+std::unique_ptr
+SymbolFileDWARF::GetDwoSymbolFileForCompileUnit(DWARFCompileUnit &dwarf_cu, const DWARFDebugInfoEntry &cu_die)
+{
+const char *dwo_name = cu_die.GetAttributeValueAsString(this, &dwarf_cu, DW_AT_GNU_dwo_

Re: [Lldb-commits] [PATCH] D18531: Allow gdbremote process to read modules from memory

2016-03-29 Thread Francis Ricci via lldb-commits 
fjricci added a comment.

That was actually one of the fixes I originally tried. My only concern is that 
LoadModuleAtAddress is a protected method in the dynamic loader. If you think 
it's fine to change it to public, I'll go ahead and do that.


http://reviews.llvm.org/D18531



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

Re: [Lldb-commits] [PATCH] D18531: Allow gdbremote process to read modules from memory

2016-03-29 Thread Tamas Berghammer via lldb-commits 
tberghammer added a comment.

I think it should be fine to make it public as it don't do anything what can 
mess up the private state of the DynamicLoader. In general visibility in LLDB 
are decided in a bit randomly so usually it is fine to change them if the 
implementation looks like it won't break some internal state.


http://reviews.llvm.org/D18531



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

Re: [Lldb-commits] [PATCH] D18519: Allow building LLDB on Windows with MinGW 64/4.9.2 and later

2016-03-29 Thread Pavel Labath via lldb-commits 
labath added inline comments.


Comment at: CMakeLists.txt:3
@@ -2,1 +2,3 @@
 
+if(MINGW_DEBUG)
+# force debugging info into lldb sources

eran.ifrah wrote:
> labath wrote:
> > Why do we need this? Why is `-DCMAKE_BUILD_TYPE=Debug` not sufficient?
> No. As I mentioned in my previous comment the object file generated are too 
> big for as.exe to handle
> and it aborts. This results from Clang files (not LLDB). As a workaround and 
> I added this command line directive to be able to produce debug builds of 
> LLDB so I can actually debug them and provide some more insights if needed
Sorry, I came late to the discussion and I did not catch that.

This sounds like the same problem clang is having with MSVC on windows. For 
MSVC, it is possible to fix this by specifying the `/bigobj` flag to the 
compiler (see clang/lib/ASTMatchers/Dynamic/CMakeLists.txt). A quick search 
 seems to indicate that the same 
solution could be applied to mingw as well. Could see if you could make that 
work instead?


Comment at: cmake/modules/LLDBConfig.cmake:224
@@ -223,2 +223,3 @@
 # Disable Clang warnings
+if (CMAKE_CXX_COMPILER_ID MATCHES "Clang")
 check_cxx_compiler_flag("-Wno-deprecated-register"

eran.ifrah wrote:
> labath wrote:
> > Why is this necessary? The whole purpose `check_cxx_compiler_flag` is to 
> > check whether a compiler supports some flag. Hardcoding the check ourselves 
> > makes that kinda pointless. What error were you getting here?
> Tons of warnings about unrecognized command line directive (or something 
> similar) - can't remember the exact warning message - but its something like 
> this. If really need to know the warning message, I can re-compile without 
> this change
Ok, so it seems the problem is that this check will not work because most 
compilers will not treat an unknown -W flag as a fatal error. The trick seems 
to be to pass `-Werror` as well to force a non-zero exit (see 
llvm/cmake/modules/HandleLLVMOptions.cmake). Perhaps you could do the same here?


http://reviews.llvm.org/D18519



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

Re: [Lldb-commits] [PATCH] D18481: Add argument to expectedFailureAll decorator to xfail for environment variables, and xfail tests for hard float abi and -mthumb on android arm

2016-03-29 Thread Pavel Labath via lldb-commits 
labath added a comment.

So, the way I would achieve this is to have a way to specify "i want to run the 
tests with hard-float", or "I want to use thumb instruction set" when running 
dotest.py and then based on this information, set the correct compiler flags 
**and** xfail/skip tests. When we do it this way, we could actually fix some of 
the tests you are trying to skip here. E.g. the only reason TestLldbGdbServer 
is failing for thumb is because the test does not know the instruction set and 
so it cannot put the right kind of a breakpoint. As for the dotest flags, we 
could either invent some new flags (`--isa` and `--abi`, perhaps?) or shove 
this information into `--arch` somehow (`--arch=arm-softfp`, 
`--arch=thumb-hardfp` ?).


http://reviews.llvm.org/D18481



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

Re: [Lldb-commits] [PATCH] D17027: [expression evaluator] Allow runtimes to execute custom LLVM ModulePasses over the generated IR at various stages after expression compilation.

2016-03-29 Thread Luke Drummond via lldb-commits 
ldrumm added a comment.

Hi Sean

Did you get a chance to look over this? It'd be great to have your input.

Best

Luke


http://reviews.llvm.org/D17027



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

[Lldb-commits] [lldb] r264733 - Revert the "build fix" in r264104

2016-03-29 Thread Pavel Labath via lldb-commits 
Author: labath
Date: Tue Mar 29 09:39:10 2016
New Revision: 264733

URL: http://llvm.org/viewvc/llvm-project?rev=264733&view=rev
Log:
Revert the "build fix" in r264104

this was needed because lldb-mi temporarily contained references to private 
lldb symbols
(lldb_private namespace), which it shouldn't have. The situation has since been 
rectified and
this wasn't the right fix anyway, since it can lead to funny ODR violations.

Modified:
lldb/trunk/tools/lldb-mi/CMakeLists.txt

Modified: lldb/trunk/tools/lldb-mi/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/tools/lldb-mi/CMakeLists.txt?rev=264733&r1=264732&r2=264733&view=diff
==
--- lldb/trunk/tools/lldb-mi/CMakeLists.txt (original)
+++ lldb/trunk/tools/lldb-mi/CMakeLists.txt Tue Mar 29 09:39:10 2016
@@ -82,8 +82,6 @@ if ( CMAKE_SYSTEM_NAME MATCHES "Windows"
 )
 endif ()
 
-include(../../cmake/LLDBDependencies.cmake)
-
 add_lldb_executable(lldb-mi ${LLDB_MI_SOURCES})
 
 target_link_libraries(lldb-mi liblldb)
@@ -91,8 +89,6 @@ if ( NOT CMAKE_SYSTEM_NAME MATCHES "Wind
   target_link_libraries(lldb-mi pthread)
 endif ()
 
-# TODO: why isn't this done by add_lldb_executable?
-target_link_libraries(lldb-mi ${LLDB_USED_LIBS})
 llvm_config(lldb-mi ${LLVM_LINK_COMPONENTS})
 
 set_target_properties(lldb-mi PROPERTIES VERSION ${LLDB_VERSION})


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

[Lldb-commits] [lldb] r264735 - Move DynamicLoader plugins to SystemInitializerFull

2016-03-29 Thread Pavel Labath via lldb-commits 
Author: labath
Date: Tue Mar 29 10:00:26 2016
New Revision: 264735

URL: http://llvm.org/viewvc/llvm-project?rev=264735&view=rev
Log:
Move DynamicLoader plugins to SystemInitializerFull

Summary: These are not needed by lldb-server. Removing them shrinks the server 
by about 0.5%.

Reviewers: zturner

Subscribers: lldb-commits

Differential Revision: http://reviews.llvm.org/D18206

Modified:
lldb/trunk/source/API/SystemInitializerFull.cpp
lldb/trunk/source/Initialization/SystemInitializerCommon.cpp

Modified: lldb/trunk/source/API/SystemInitializerFull.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/API/SystemInitializerFull.cpp?rev=264735&r1=264734&r2=264735&view=diff
==
--- lldb/trunk/source/API/SystemInitializerFull.cpp (original)
+++ lldb/trunk/source/API/SystemInitializerFull.cpp Tue Mar 29 10:00:26 2016
@@ -42,6 +42,9 @@
 #include "Plugins/ABI/SysV-x86_64/ABISysV_x86_64.h"
 #include "Plugins/Disassembler/llvm/DisassemblerLLVMC.h"
 #include "Plugins/DynamicLoader/Static/DynamicLoaderStatic.h"
+#include "Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderMacOSXDYLD.h"
+#include "Plugins/DynamicLoader/POSIX-DYLD/DynamicLoaderPOSIXDYLD.h"
+#include "Plugins/DynamicLoader/Windows-DYLD/DynamicLoaderWindowsDYLD.h"
 #include "Plugins/Instruction/ARM64/EmulateInstructionARM64.h"
 #include 
"Plugins/InstrumentationRuntime/AddressSanitizer/AddressSanitizerRuntime.h"
 #include 
"Plugins/InstrumentationRuntime/ThreadSanitizer/ThreadSanitizerRuntime.h"
@@ -81,6 +84,7 @@
 #include "Plugins/Platform/MacOSX/PlatformAppleWatchSimulator.h"
 #include "Plugins/Platform/MacOSX/PlatformRemoteAppleTV.h"
 #include "Plugins/Platform/MacOSX/PlatformRemoteAppleWatch.h"
+#include "Plugins/DynamicLoader/Darwin-Kernel/DynamicLoaderDarwinKernel.h"
 #endif
 
 #if defined(__FreeBSD__)
@@ -345,6 +349,7 @@ SystemInitializerFull::Initialize()
 PlatformAppleWatchSimulator::Initialize();
 PlatformRemoteAppleTV::Initialize();
 PlatformRemoteAppleWatch::Initialize();
+DynamicLoaderDarwinKernel::Initialize();
 #endif
 //--
 // Platform agnostic plugins
@@ -352,7 +357,10 @@ SystemInitializerFull::Initialize()
 platform_gdb_server::PlatformRemoteGDBServer::Initialize();
 
 process_gdb_remote::ProcessGDBRemote::Initialize();
+DynamicLoaderMacOSXDYLD::Initialize();
+DynamicLoaderPOSIXDYLD::Initialize();
 DynamicLoaderStatic::Initialize();
+DynamicLoaderWindowsDYLD::Initialize();
 
 // Scan for any system or user LLDB plug-ins
 PluginManager::Initialize();
@@ -454,6 +462,7 @@ SystemInitializerFull::Terminate()
 ObjCPlusPlusLanguage::Terminate();
 
 #if defined(__APPLE__)
+DynamicLoaderDarwinKernel::Terminate();
 ProcessMachCore::Terminate();
 ProcessKDP::Terminate();
 SymbolVendorMacOSX::Terminate();
@@ -470,7 +479,10 @@ SystemInitializerFull::Terminate()
 
 platform_gdb_server::PlatformRemoteGDBServer::Terminate();
 process_gdb_remote::ProcessGDBRemote::Terminate();
+DynamicLoaderMacOSXDYLD::Terminate();
+DynamicLoaderPOSIXDYLD::Terminate();
 DynamicLoaderStatic::Terminate();
+DynamicLoaderWindowsDYLD::Terminate();
 
 #ifndef LLDB_DISABLE_PYTHON
 OperatingSystemPython::Terminate();

Modified: lldb/trunk/source/Initialization/SystemInitializerCommon.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Initialization/SystemInitializerCommon.cpp?rev=264735&r1=264734&r2=264735&view=diff
==
--- lldb/trunk/source/Initialization/SystemInitializerCommon.cpp (original)
+++ lldb/trunk/source/Initialization/SystemInitializerCommon.cpp Tue Mar 29 
10:00:26 2016
@@ -15,9 +15,6 @@
 #include "lldb/Core/Timer.h"
 #include "lldb/Symbol/GoASTContext.h"
 #include "lldb/Symbol/ClangASTContext.h"
-#include "Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderMacOSXDYLD.h"
-#include "Plugins/DynamicLoader/POSIX-DYLD/DynamicLoaderPOSIXDYLD.h"
-#include "Plugins/DynamicLoader/Windows-DYLD/DynamicLoaderWindowsDYLD.h"
 #include "Plugins/Instruction/ARM/EmulateInstructionARM.h"
 #include "Plugins/Instruction/MIPS/EmulateInstructionMIPS.h"
 #include "Plugins/Instruction/MIPS64/EmulateInstructionMIPS64.h"
@@ -37,7 +34,6 @@
 
 #if defined(__APPLE__)
 #include "Plugins/Platform/MacOSX/PlatformiOSSimulator.h"
-#include "Plugins/DynamicLoader/Darwin-Kernel/DynamicLoaderDarwinKernel.h"
 #include "Plugins/ObjectFile/Mach-O/ObjectFileMachO.h"
 #include "Plugins/Platform/MacOSX/PlatformDarwinKernel.h"
 #endif
@@ -108,8 +104,6 @@ SystemInitializerCommon::Initialize()
 ObjectContainerBSDArchive::Initialize();
 ObjectFileELF::Initialize();
 ObjectFilePECOFF::Initialize();
-DynamicLoaderPOSIXDYLD::Initialize();
-DynamicLoaderWindowsDYLD::Initialize();
 platform_freebsd::PlatformFreeBSD::Initialize();
 platform_linu

Re: [Lldb-commits] [PATCH] D18206: Move DynamicLoader plugins to SystemInitializerFull

2016-03-29 Thread Pavel Labath via lldb-commits 
This revision was automatically updated to reflect the committed changes.
Closed by commit rL264735: Move DynamicLoader plugins to SystemInitializerFull 
(authored by labath).

Changed prior to commit:
  http://reviews.llvm.org/D18206?vs=50813&id=51917#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D18206

Files:
  lldb/trunk/source/API/SystemInitializerFull.cpp
  lldb/trunk/source/Initialization/SystemInitializerCommon.cpp

Index: lldb/trunk/source/Initialization/SystemInitializerCommon.cpp
===
--- lldb/trunk/source/Initialization/SystemInitializerCommon.cpp
+++ lldb/trunk/source/Initialization/SystemInitializerCommon.cpp
@@ -15,9 +15,6 @@
 #include "lldb/Core/Timer.h"
 #include "lldb/Symbol/GoASTContext.h"
 #include "lldb/Symbol/ClangASTContext.h"
-#include "Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderMacOSXDYLD.h"
-#include "Plugins/DynamicLoader/POSIX-DYLD/DynamicLoaderPOSIXDYLD.h"
-#include "Plugins/DynamicLoader/Windows-DYLD/DynamicLoaderWindowsDYLD.h"
 #include "Plugins/Instruction/ARM/EmulateInstructionARM.h"
 #include "Plugins/Instruction/MIPS/EmulateInstructionMIPS.h"
 #include "Plugins/Instruction/MIPS64/EmulateInstructionMIPS64.h"
@@ -37,7 +34,6 @@
 
 #if defined(__APPLE__)
 #include "Plugins/Platform/MacOSX/PlatformiOSSimulator.h"
-#include "Plugins/DynamicLoader/Darwin-Kernel/DynamicLoaderDarwinKernel.h"
 #include "Plugins/ObjectFile/Mach-O/ObjectFileMachO.h"
 #include "Plugins/Platform/MacOSX/PlatformDarwinKernel.h"
 #endif
@@ -108,8 +104,6 @@
 ObjectContainerBSDArchive::Initialize();
 ObjectFileELF::Initialize();
 ObjectFilePECOFF::Initialize();
-DynamicLoaderPOSIXDYLD::Initialize();
-DynamicLoaderWindowsDYLD::Initialize();
 platform_freebsd::PlatformFreeBSD::Initialize();
 platform_linux::PlatformLinux::Initialize();
 platform_netbsd::PlatformNetBSD::Initialize();
@@ -124,15 +118,13 @@
 //--
 // Apple/Darwin hosted plugins
 //--
-DynamicLoaderMacOSXDYLD::Initialize();
 ObjectContainerUniversalMachO::Initialize();
 
 PlatformRemoteiOS::Initialize();
 PlatformMacOSX::Initialize();
 
 #if defined(__APPLE__)
 PlatformiOSSimulator::Initialize();
-DynamicLoaderDarwinKernel::Initialize();
 PlatformDarwinKernel::Initialize();
 ObjectFileMachO::Initialize();
 #endif
@@ -152,15 +144,12 @@
 ObjectContainerBSDArchive::Terminate();
 ObjectFileELF::Terminate();
 ObjectFilePECOFF::Terminate();
-DynamicLoaderPOSIXDYLD::Terminate();
-DynamicLoaderWindowsDYLD::Terminate();
 platform_freebsd::PlatformFreeBSD::Terminate();
 platform_linux::PlatformLinux::Terminate();
 platform_netbsd::PlatformNetBSD::Terminate();
 PlatformWindows::Terminate();
 PlatformKalimba::Terminate();
 platform_android::PlatformAndroid::Terminate();
-DynamicLoaderMacOSXDYLD::Terminate();
 ObjectContainerUniversalMachO::Terminate();
 PlatformMacOSX::Terminate();
 PlatformRemoteiOS::Terminate();
@@ -174,7 +163,6 @@
 
 #if defined(__APPLE__)
 PlatformiOSSimulator::Terminate();
-DynamicLoaderDarwinKernel::Terminate();
 ObjectFileMachO::Terminate();
 PlatformDarwinKernel::Terminate();
 #endif
Index: lldb/trunk/source/API/SystemInitializerFull.cpp
===
--- lldb/trunk/source/API/SystemInitializerFull.cpp
+++ lldb/trunk/source/API/SystemInitializerFull.cpp
@@ -42,6 +42,9 @@
 #include "Plugins/ABI/SysV-x86_64/ABISysV_x86_64.h"
 #include "Plugins/Disassembler/llvm/DisassemblerLLVMC.h"
 #include "Plugins/DynamicLoader/Static/DynamicLoaderStatic.h"
+#include "Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderMacOSXDYLD.h"
+#include "Plugins/DynamicLoader/POSIX-DYLD/DynamicLoaderPOSIXDYLD.h"
+#include "Plugins/DynamicLoader/Windows-DYLD/DynamicLoaderWindowsDYLD.h"
 #include "Plugins/Instruction/ARM64/EmulateInstructionARM64.h"
 #include "Plugins/InstrumentationRuntime/AddressSanitizer/AddressSanitizerRuntime.h"
 #include "Plugins/InstrumentationRuntime/ThreadSanitizer/ThreadSanitizerRuntime.h"
@@ -81,6 +84,7 @@
 #include "Plugins/Platform/MacOSX/PlatformAppleWatchSimulator.h"
 #include "Plugins/Platform/MacOSX/PlatformRemoteAppleTV.h"
 #include "Plugins/Platform/MacOSX/PlatformRemoteAppleWatch.h"
+#include "Plugins/DynamicLoader/Darwin-Kernel/DynamicLoaderDarwinKernel.h"
 #endif
 
 #if defined(__FreeBSD__)
@@ -345,14 +349,18 @@
 PlatformAppleWatchSimulator::Initialize();
 PlatformRemoteAppleTV::Initialize();
 PlatformRemoteAppleWatch::Initialize();
+DynamicLoaderDarwinKernel::Initialize();
 #endif
 //--
 // Platform agnostic plugins
 //--
 platform_gdb_server::PlatformRemo

Re: [Lldb-commits] [PATCH] D18519: Allow building LLDB on Windows with MinGW 64/4.9.2 and later

2016-03-29 Thread Eran Ifrah via lldb-commits 
eran.ifrah updated this revision to Diff 51918.
eran.ifrah added a comment.

Fixed: WindowsMiniDump should now also compile and work on MinGW by adding 
`Dbghelp` library 
Fixed: DebuggerThread: don't pass std::atomic to the LOG macros as it 
yields g++ error on MinGW, instead use a temp variable
Fixed: Re-enable LOG macros on MinGW


http://reviews.llvm.org/D18519

Files:
  CMakeLists.txt
  cmake/modules/AddLLDB.cmake
  cmake/modules/LLDBConfig.cmake
  include/lldb/Host/windows/win32.h
  source/API/CMakeLists.txt
  source/API/SystemInitializerFull.cpp
  source/Host/common/OptionParser.cpp
  source/Host/windows/EditLineWin.cpp
  source/Host/windows/FileSystem.cpp
  source/Host/windows/ProcessRunLock.cpp
  source/Plugins/ObjectFile/PECOFF/WindowsMiniDump.cpp
  source/Plugins/Process/Windows/Live/DebuggerThread.cpp
  source/Target/ProcessLaunchInfo.cpp
  source/Utility/PseudoTerminal.cpp
  tools/CMakeLists.txt
  tools/argdumper/CMakeLists.txt
  tools/driver/CMakeLists.txt
  tools/driver/Driver.cpp

Index: tools/driver/Driver.cpp
===
--- tools/driver/Driver.cpp
+++ tools/driver/Driver.cpp
@@ -1299,7 +1299,7 @@
 }
 
 int
-#ifdef WIN32
+#if defined(_MSC_VER)
 wmain(int argc, wchar_t const *wargv[])
 #else
 main(int argc, char const *argv[])
@@ -1311,7 +1311,7 @@
 	setvbuf(stdin , NULL, _IONBF, 0);
 #endif
 
-#ifdef _WIN32
+#if defined(_MSC_VER)
 // Convert wide arguments to UTF-8
 std::vector argvStrings(argc);
 std::vector argvPointers(argc);
Index: tools/driver/CMakeLists.txt
===
--- tools/driver/CMakeLists.txt
+++ tools/driver/CMakeLists.txt
@@ -17,7 +17,14 @@
   add_dependencies(lldb debugserver)
 endif()
 
+if(MINGW)
+# link directly against the dll file
+add_dependencies(lldb liblldb)
+target_link_libraries(lldb -L"${CMAKE_BINARY_DIR}/bin" -llldb)
+else()
 target_link_libraries(lldb liblldb)
+endif()
+
 # TODO: why isn't this done by add_lldb_executable?
 #target_link_libraries(lldb ${LLDB_USED_LIBS})
 #llvm_config(lldb ${LLVM_LINK_COMPONENTS})
Index: tools/argdumper/CMakeLists.txt
===
--- tools/argdumper/CMakeLists.txt
+++ tools/argdumper/CMakeLists.txt
@@ -2,7 +2,13 @@
   argdumper.cpp
   )
 
+if(MINGW)
+# link directly against the dll file
+add_dependencies(lldb-argdumper liblldb)
+target_link_libraries(lldb-argdumper -L"${CMAKE_BINARY_DIR}/bin" -llldb)
+else()
 target_link_libraries(lldb-argdumper liblldb)
+endif()
 
 install(TARGETS lldb-argdumper
   RUNTIME DESTINATION bin)
Index: tools/CMakeLists.txt
===
--- tools/CMakeLists.txt
+++ tools/CMakeLists.txt
@@ -4,7 +4,8 @@
 endif()
   add_subdirectory(argdumper)
   add_subdirectory(driver)
-if (NOT __ANDROID_NDK__)
+if (NOT __ANDROID_NDK__ AND NOT MINGW)
+  # TODO: we should really make lldb-mi compile under MinGW
   add_subdirectory(lldb-mi)
 endif()
 if (LLDB_CAN_USE_LLDB_SERVER)
Index: source/Utility/PseudoTerminal.cpp
===
--- source/Utility/PseudoTerminal.cpp
+++ source/Utility/PseudoTerminal.cpp
@@ -20,7 +20,9 @@
 
 #ifdef _WIN32
 #include "lldb/Host/windows/win32.h"
+#if defined(_MSC_VER)
 typedef uint32_t pid_t;
+#endif
 // empty functions
 int posix_openpt(int flag) { return 0; }
 
Index: source/Target/ProcessLaunchInfo.cpp
===
--- source/Target/ProcessLaunchInfo.cpp
+++ source/Target/ProcessLaunchInfo.cpp
@@ -366,7 +366,7 @@
  __FUNCTION__);
 
 int open_flags = O_RDWR | O_NOCTTY;
-#if !defined(_MSC_VER)
+#if !defined(LLVM_ON_WIN32)
 // We really shouldn't be specifying platform specific flags
 // that are intended for a system call in generic code.  But
 // this will have to do for now.
Index: source/Plugins/Process/Windows/Live/DebuggerThread.cpp
===
--- source/Plugins/Process/Windows/Live/DebuggerThread.cpp
+++ source/Plugins/Process/Windows/Live/DebuggerThread.cpp
@@ -377,9 +377,10 @@
 // we use simply to wake up the DebuggerThread so that we can close out the debug loop.
 if (m_pid_to_detach != 0 && info.ExceptionRecord.ExceptionCode == EXCEPTION_BREAKPOINT)
 {
+DWORD dwPidToDetach = m_pid_to_detach;
 WINLOG_IFANY(WINDOWS_LOG_EVENT | WINDOWS_LOG_EXCEPTION | WINDOWS_LOG_PROCESS,
 "Breakpoint exception is cue to detach from process 0x%x",
-m_pid_to_detach);
+dwPidToDetach);
 ::DebugActiveProcessStop(m_pid_to_detach);
 m_detached = true;
 }
Index: source/Plugins/ObjectFile/PECOFF/WindowsMiniDump.cpp
=

Re: [Lldb-commits] [PATCH] D18519: Allow building LLDB on Windows with MinGW 64/4.9.2 and later

2016-03-29 Thread Eran Ifrah via lldb-commits 
On Tue, Mar 29, 2016 at 8:43 AM, Zachary Turner  wrote:

> It's night here, so I will have a detailed look tomorrow.  But in the
> meantime, some of the issues don't appear to be addressed.  For example the
> issue about why logging is disabled,
>
​Fixed with the new patch
​


> the disabled code in ProcessWinMiniDump.cpp,
>
​Fixed
​


> and a few other things.  If you view the diff in Phabricator, you can
> respond inline to each of those with some kind of explanation if possible.
>
> On Mon, Mar 28, 2016 at 10:26 PM Eran Ifrah  wrote:
>
>> eran.ifrah updated this revision to Diff 51873.
>> eran.ifrah marked 21 inline comments as done.
>> eran.ifrah added a comment.
>>
>> An updated patch that fixes all your comments and in includes this one as
>> well: http://reviews.llvm.org/D18520
>> I also added new command line argument option to `CMake` :
>> `-DMINGW_DEBUG=1` when passed from the command line, it adds `-g -O0` to
>> the LLDB sources (only LLDB)
>> Using the standard way `-DCMAKE_BUILD_TYPE=Debug` creates file too large
>> for MinGW to handle
>>
>>
>> http://reviews.llvm.org/D18519
>>
>> Files:
>>   CMakeLists.txt
>>   cmake/modules/AddLLDB.cmake
>>   cmake/modules/LLDBConfig.cmake
>>   include/lldb/Host/windows/win32.h
>>   source/API/SystemInitializerFull.cpp
>>   source/Host/common/OptionParser.cpp
>>   source/Host/windows/EditLineWin.cpp
>>   source/Host/windows/FileSystem.cpp
>>   source/Host/windows/ProcessRunLock.cpp
>>   source/Plugins/ObjectFile/PECOFF/WindowsMiniDump.cpp
>>   source/Plugins/Process/Windows/Common/ProcessWindowsLog.h
>>   source/Target/ProcessLaunchInfo.cpp
>>   source/Utility/PseudoTerminal.cpp
>>   tools/CMakeLists.txt
>>   tools/argdumper/CMakeLists.txt
>>   tools/driver/CMakeLists.txt
>>   tools/driver/Driver.cpp
>>
>>


-- 
Eran Ifrah,
Author of codelite, a cross platform open source C/C++ IDE:
http://www.codelite.org
CodeLite IDE Blog: http://codeliteide.blogspot.com/
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D18558: Fix flakyness in TestWatchpointMultipleThreads

2016-03-29 Thread Pavel Labath via lldb-commits 
labath created this revision.
labath added reviewers: clayborg, jingham.
labath added a subscriber: lldb-commits.

the inferior in the test deliberately does not lock a mutex when accessing the 
watched variable.
The reason for that is unclear as, based on the logs, the original intention of 
the test was to
check whether watchpoints get propagated to newly created threads, which should 
work fine even
with a mutex. Furthermore, in the unlikely event (which I have still observed 
happening from time
to time) that two threads do manage the execute the "critical section" 
simultaneously, the test
will fail, as it is expecting the watchpoint "hit count" to be 1, but in this 
case it will be 2.

Given this, I have simply chose to lock the mutex always, so that we have more 
predictible
behavior. Watchpoints being hit simultaneously is still (and correctly!) tested 
by
TestConcurrentEvents.

http://reviews.llvm.org/D18558

Files:
  
packages/Python/lldbsuite/test/functionalities/watchpoint/multiple_threads/TestWatchpointMultipleThreads.py
  
packages/Python/lldbsuite/test/functionalities/watchpoint/multiple_threads/main.cpp

Index: 
packages/Python/lldbsuite/test/functionalities/watchpoint/multiple_threads/main.cpp
===
--- 
packages/Python/lldbsuite/test/functionalities/watchpoint/multiple_threads/main.cpp
+++ 
packages/Python/lldbsuite/test/functionalities/watchpoint/multiple_threads/main.cpp
@@ -23,27 +23,23 @@
 access_pool (bool flag = false)
 {
 static std::mutex g_access_mutex;
-if (!flag)
-g_access_mutex.lock();
+g_access_mutex.lock();
 
 uint32_t old_val = g_val;
 if (flag)
 {
 printf("changing g_val to %d...\n", old_val + 1);
 g_val = old_val + 1;
 }
 
-if (!flag)
-g_access_mutex.unlock();
+g_access_mutex.unlock();
 return g_val;
 }
 
 void
 thread_func (uint32_t thread_index)
 {
-// Break here in order to allow the thread
-// to inherit the global watchpoint state.
-printf ("%s (thread index = %u) startng...\n", __FUNCTION__, thread_index);
+printf ("%s (thread index = %u) starting...\n", __FUNCTION__, 
thread_index);
 
 uint32_t count = 0;
 uint32_t val;
Index: 
packages/Python/lldbsuite/test/functionalities/watchpoint/multiple_threads/TestWatchpointMultipleThreads.py
===
--- 
packages/Python/lldbsuite/test/functionalities/watchpoint/multiple_threads/TestWatchpointMultipleThreads.py
+++ 
packages/Python/lldbsuite/test/functionalities/watchpoint/multiple_threads/TestWatchpointMultipleThreads.py
@@ -58,9 +58,6 @@
'stop reason = breakpoint'])
 
 # Now let's set a write-type watchpoint for variable 'g_val'.
-# The main.cpp, by design, misbehaves by not following the agreed upon
-# protocol of using a mutex while accessing the global pool and by not
-# writing to the variable.
 self.expect("watchpoint set variable -w write g_val", 
WATCHPOINT_CREATED,
 substrs = ['Watchpoint created', 'size = 4', 'type = w'])
 
@@ -102,9 +99,6 @@
'stop reason = breakpoint'])
 
 # Now let's set a write-type watchpoint for variable 'g_val'.
-# The main.cpp, by design, misbehaves by not following the agreed upon
-# protocol of using a mutex while accessing the global pool and by not
-# writing to the variable.
 self.expect("watchpoint set variable -w write g_val", 
WATCHPOINT_CREATED,
 substrs = ['Watchpoint created', 'size = 4', 'type = w'])
 


Index: packages/Python/lldbsuite/test/functionalities/watchpoint/multiple_threads/main.cpp
===
--- packages/Python/lldbsuite/test/functionalities/watchpoint/multiple_threads/main.cpp
+++ packages/Python/lldbsuite/test/functionalities/watchpoint/multiple_threads/main.cpp
@@ -23,27 +23,23 @@
 access_pool (bool flag = false)
 {
 static std::mutex g_access_mutex;
-if (!flag)
-g_access_mutex.lock();
+g_access_mutex.lock();
 
 uint32_t old_val = g_val;
 if (flag)
 {
 printf("changing g_val to %d...\n", old_val + 1);
 g_val = old_val + 1;
 }
 
-if (!flag)
-g_access_mutex.unlock();
+g_access_mutex.unlock();
 return g_val;
 }
 
 void
 thread_func (uint32_t thread_index)
 {
-// Break here in order to allow the thread
-// to inherit the global watchpoint state.
-printf ("%s (thread index = %u) startng...\n", __FUNCTION__, thread_index);
+printf ("%s (thread index = %u) starting...\n", __FUNCTION__, thread_index);
 
 uint32_t count = 0;
 uint32_t val;
Index: packages/Python/lldbsuite/test/functionalities/watchpoint/multiple_threads/TestWatchpointMultipleThreads.py
===
--- packages/Python/lldbsuite/test/func

[Lldb-commits] [lldb] r264753 - Don't try to call getTypeSize() on a class if it isn't complete as clang will assert and kill the process.

2016-03-29 Thread Greg Clayton via lldb-commits 
Author: gclayton
Date: Tue Mar 29 12:36:38 2016
New Revision: 264753

URL: http://llvm.org/viewvc/llvm-project?rev=264753&view=rev
Log:
Don't try to call getTypeSize() on a class if it isn't complete as clang will 
assert and kill the process.

Modified:
lldb/trunk/source/Symbol/ClangASTContext.cpp

Modified: lldb/trunk/source/Symbol/ClangASTContext.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Symbol/ClangASTContext.cpp?rev=264753&r1=264752&r2=264753&view=diff
==
--- lldb/trunk/source/Symbol/ClangASTContext.cpp (original)
+++ lldb/trunk/source/Symbol/ClangASTContext.cpp Tue Mar 29 12:36:38 2016
@@ -4674,8 +4674,16 @@ ClangASTContext::GetBitSize (lldb::opaqu
 if (GetCompleteType (type))
 {
 clang::QualType qual_type(GetCanonicalQualType(type));
-switch (qual_type->getTypeClass())
+const clang::Type::TypeClass type_class = qual_type->getTypeClass();
+switch (type_class)
 {
+case clang::Type::Record:
+if (GetCompleteType(type))
+return getASTContext()->getTypeSize(qual_type);
+else
+return 0;
+break;
+
 case clang::Type::ObjCInterface:
 case clang::Type::ObjCObject:
 {


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

Re: [Lldb-commits] [PATCH] D18531: Allow gdbremote process to read modules from memory

2016-03-29 Thread Francis Ricci via lldb-commits 
fjricci added a comment.

I see that DynamicLoaderHexagonDYLD also has a LoadModuleAtAddress function, 
which seems to be the same as the one in DynamicLoader, except that the member 
functions it calls are overloaded, and it is also missing the newly added 
ReadFromMemory code.

I think this function should be safe to remove, but I wanted to double check 
before I do that.


http://reviews.llvm.org/D18531



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

[Lldb-commits] [lldb] r264762 - When creating typedefs, don't call Type::GetName() since that might recursively call "lldb_private::Type::ResolveClangType(lldb_private::Type::ResolveStateTag)" and cau

2016-03-29 Thread Greg Clayton via lldb-commits 
Author: gclayton
Date: Tue Mar 29 13:22:07 2016
New Revision: 264762

URL: http://llvm.org/viewvc/llvm-project?rev=264762&view=rev
Log:
When creating typedefs, don't call Type::GetName() since that might recursively 
call 
"lldb_private::Type::ResolveClangType(lldb_private::Type::ResolveStateTag)" and 
cause a crash. A lldb_private::Type should have a valid name if it is created 
without a backing CompilerType. Also provide a name that we can recognize so if 
we see it in a as the typename of a variable, we will know to check it out. 
This crash is happening quite a bit and we need to determine if this is due to 
incorrect debug info, or just due to some bug in LLDBD.



Modified:
lldb/trunk/source/Symbol/Type.cpp

Modified: lldb/trunk/source/Symbol/Type.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Symbol/Type.cpp?rev=264762&r1=264761&r2=264762&view=diff
==
--- lldb/trunk/source/Symbol/Type.cpp (original)
+++ lldb/trunk/source/Symbol/Type.cpp Tue Mar 29 13:22:07 2016
@@ -559,8 +559,8 @@ Type::ResolveClangType (ResolveState com
 break;
 
 case eEncodingIsTypedefUID:
-m_compiler_type = encoding_type->GetForwardCompilerType 
().CreateTypedef(GetName().AsCString(),
-   
   GetSymbolFile()->GetDeclContextContainingUID(GetID()));
+m_compiler_type = encoding_type->GetForwardCompilerType 
().CreateTypedef(m_name.AsCString("__lldb_invalid_typedef_name"),
+   
  GetSymbolFile()->GetDeclContextContainingUID(GetID()));
 m_name.Clear();
 break;
 
@@ -605,8 +605,8 @@ Type::ResolveClangType (ResolveState com
 break;
 
 case eEncodingIsTypedefUID:
-m_compiler_type = 
void_compiler_type.CreateTypedef(GetName().AsCString(),
- 
GetSymbolFile()->GetDeclContextContainingUID(GetID()));
+m_compiler_type = 
void_compiler_type.CreateTypedef(m_name.AsCString("__lldb_invalid_typedef_name"),
+   
GetSymbolFile()->GetDeclContextContainingUID(GetID()));
 break;
 
 case eEncodingIsPointerUID:


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

Re: [Lldb-commits] [PATCH] D18531: Allow gdbremote process to read modules from memory

2016-03-29 Thread Francis Ricci via lldb-commits 
fjricci updated this revision to Diff 51962.
fjricci added a comment.

Refactor to remove code duplication


http://reviews.llvm.org/D18531

Files:
  include/lldb/Target/DynamicLoader.h
  source/Plugins/DynamicLoader/Hexagon-DYLD/DynamicLoaderHexagonDYLD.cpp
  source/Plugins/DynamicLoader/Hexagon-DYLD/DynamicLoaderHexagonDYLD.h
  source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
  source/Plugins/Process/gdb-remote/ProcessGDBRemote.h

Index: source/Plugins/Process/gdb-remote/ProcessGDBRemote.h
===
--- source/Plugins/Process/gdb-remote/ProcessGDBRemote.h
+++ source/Plugins/Process/gdb-remote/ProcessGDBRemote.h
@@ -468,7 +468,8 @@
 GetLoadedModuleList (LoadedModuleInfoList &);
 
 lldb::ModuleSP
-LoadModuleAtAddress (const FileSpec &file, lldb::addr_t base_addr, bool value_is_offset);
+LoadModuleAtAddress (const FileSpec &file, lldb::addr_t link_map, lldb::addr_t base_addr,
+ bool value_is_offset);
 
 private:
 //--
Index: source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
===
--- source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
+++ source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
@@ -4804,25 +4804,14 @@
 }
 
 lldb::ModuleSP
-ProcessGDBRemote::LoadModuleAtAddress (const FileSpec &file, lldb::addr_t base_addr, bool value_is_offset)
+ProcessGDBRemote::LoadModuleAtAddress (const FileSpec &file, lldb::addr_t link_map,
+   lldb::addr_t base_addr, bool value_is_offset)
 {
-Target &target = m_process->GetTarget();
-ModuleList &modules = target.GetImages();
-ModuleSP module_sp;
+DynamicLoader *loader = GetDynamicLoader();
+if (!loader)
+return nullptr;
 
-bool changed = false;
-
-ModuleSpec module_spec (file, target.GetArchitecture());
-if ((module_sp = modules.FindFirstModule (module_spec)))
-{
-module_sp->SetLoadAddress (target, base_addr, value_is_offset, changed);
-}
-else if ((module_sp = target.GetSharedModule (module_spec)))
-{
-module_sp->SetLoadAddress (target, base_addr, value_is_offset, changed);
-}
-
-return module_sp;
+return loader->LoadModuleAtAddress(file, link_map, base_addr, value_is_offset);
 }
 
 size_t
@@ -4841,6 +4830,7 @@
 {
 std::string  mod_name;
 lldb::addr_t mod_base;
+lldb::addr_t link_map;
 bool mod_base_is_offset;
 
 bool valid = true;
@@ -4850,15 +4840,19 @@
 if (!valid)
 continue;
 
+if (!modInfo.get_link_map (link_map))
+link_map = LLDB_INVALID_ADDRESS;
+
 // hack (cleaner way to get file name only?) (win/unix compat?)
 size_t marker = mod_name.rfind ('/');
 if (marker == std::string::npos)
 marker = 0;
 else
 marker += 1;
 
 FileSpec file (mod_name.c_str()+marker, true);
-lldb::ModuleSP module_sp = LoadModuleAtAddress (file, mod_base, mod_base_is_offset);
+lldb::ModuleSP module_sp = LoadModuleAtAddress (file, link_map, mod_base,
+mod_base_is_offset);
 
 if (module_sp.get())
 new_modules.Append (module_sp);
Index: source/Plugins/DynamicLoader/Hexagon-DYLD/DynamicLoaderHexagonDYLD.h
===
--- source/Plugins/DynamicLoader/Hexagon-DYLD/DynamicLoaderHexagonDYLD.h
+++ source/Plugins/DynamicLoader/Hexagon-DYLD/DynamicLoaderHexagonDYLD.h
@@ -123,14 +123,6 @@
 void
 UnloadSections(const lldb::ModuleSP module) override;
 
-/// Locates or creates a module given by @p file and updates/loads the
-/// resulting module at the virtual base address @p base_addr.
-lldb::ModuleSP
-LoadModuleAtAddress(const lldb_private::FileSpec &file,
-lldb::addr_t link_map_addr,
-lldb::addr_t base_addr,
-bool base_addr_is_offset) override;
-
 /// Callback routine invoked when we hit the breakpoint on process entry.
 ///
 /// This routine is responsible for resolving the load addresses of all
Index: source/Plugins/DynamicLoader/Hexagon-DYLD/DynamicLoaderHexagonDYLD.cpp
===
--- source/Plugins/DynamicLoader/Hexagon-DYLD/DynamicLoaderHexagonDYLD.cpp
+++ source/Plugins/DynamicLoader/Hexagon-DYLD/DynamicLoaderHexagonDYLD.cpp
@@ -574,34 +574,6 @@
 m_process->GetTarget().ModulesDidLoad(module_list);
 }
 
-/// Helper for the entry breakpoint callback.  Resolves the load addresses
-/// of all dependent modules.
-ModuleSP
-DynamicLoaderHexagonDYLD::LoadModuleAtAddress(const FileSpec &file,
-  addr_t link_map_addr,
-

[Lldb-commits] [lldb] r264793 - Figure out what the fixed expression is, and print it. Added another target setting to

2016-03-29 Thread Jim Ingham via lldb-commits 
Author: jingham
Date: Tue Mar 29 17:00:08 2016
New Revision: 264793

URL: http://llvm.org/viewvc/llvm-project?rev=264793&view=rev
Log:
Figure out what the fixed expression is, and print it.  Added another target 
setting to
quietly apply fixits for those who really trust clang's fixits.

Also, moved the retry into ClangUserExpression::Evaluate, where I can make a 
whole new ClangUserExpression 
to do the work.  Reusing any of the parts of a UserExpression in situ isn't 
supported at present.



Modified:
lldb/trunk/include/lldb/Expression/DiagnosticManager.h
lldb/trunk/include/lldb/Expression/ExpressionSourceCode.h
lldb/trunk/include/lldb/Expression/UserExpression.h
lldb/trunk/include/lldb/Target/Target.h

lldb/trunk/packages/Python/lldbsuite/test/expression_command/fixits/TestFixIts.py
lldb/trunk/source/Commands/CommandObjectExpression.cpp
lldb/trunk/source/Commands/CommandObjectExpression.h
lldb/trunk/source/Expression/ExpressionSourceCode.cpp
lldb/trunk/source/Expression/REPL.cpp
lldb/trunk/source/Expression/UserExpression.cpp
lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangUserExpression.cpp

lldb/trunk/source/Plugins/InstrumentationRuntime/AddressSanitizer/AddressSanitizerRuntime.cpp
lldb/trunk/source/Target/Target.cpp

Modified: lldb/trunk/include/lldb/Expression/DiagnosticManager.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Expression/DiagnosticManager.h?rev=264793&r1=264792&r2=264793&view=diff
==
--- lldb/trunk/include/lldb/Expression/DiagnosticManager.h (original)
+++ lldb/trunk/include/lldb/Expression/DiagnosticManager.h Tue Mar 29 17:00:08 
2016
@@ -122,7 +122,6 @@ public:
 Clear()
 {
 m_diagnostics.clear();
-m_auto_apply_fixits = true;
 m_fixed_expression.clear();
 }
 
@@ -204,21 +203,9 @@ public:
 fixed_expression.clear();
 }
 
-void
-SetAutoApplyFixIts(bool auto_apply)
-{
-m_auto_apply_fixits = auto_apply;
-}
-
-bool ShouldAutoApplyFixIts()
-{
-return m_auto_apply_fixits;
-}
-
 protected:
 DiagnosticList m_diagnostics;
 std::string m_fixed_expression;
-bool m_auto_apply_fixits = true;
 };
 }
 

Modified: lldb/trunk/include/lldb/Expression/ExpressionSourceCode.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Expression/ExpressionSourceCode.h?rev=264793&r1=264792&r2=264793&view=diff
==
--- lldb/trunk/include/lldb/Expression/ExpressionSourceCode.h (original)
+++ lldb/trunk/include/lldb/Expression/ExpressionSourceCode.h Tue Mar 29 
17:00:08 2016
@@ -58,6 +58,14 @@ public:
   bool static_method,
   ExecutionContext &exe_ctx) const;
 
+// Given a string returned by GetText, find the beginning and end of the 
body passed to CreateWrapped.
+// Return true if the bounds could be found.  This will also work on text 
with FixItHints applied.
+static bool
+GetOriginalBodyBounds(std::string transformed_text,
+  lldb::LanguageType wrapping_language,
+  size_t &start_loc,
+  size_t &end_loc);
+
 private:
 ExpressionSourceCode (const char *name,
   const char *prefix,

Modified: lldb/trunk/include/lldb/Expression/UserExpression.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Expression/UserExpression.h?rev=264793&r1=264792&r2=264793&view=diff
==
--- lldb/trunk/include/lldb/Expression/UserExpression.h (original)
+++ lldb/trunk/include/lldb/Expression/UserExpression.h Tue Mar 29 17:00:08 2016
@@ -281,6 +281,9 @@ public:
 /// @param[in] line_offset
 /// The offset of the first line of the expression from the 
"beginning" of a virtual source file used for error reporting and debug info.
 ///
+/// @param[out] fixed_expression
+/// If non-nullptr, the fixed expression is copied into the provided 
string.
+///
 /// @param[out] jit_module_sp_ptr
 /// If non-nullptr, used to persist the generated IR module.
 ///
@@ -295,9 +298,18 @@ public:
  lldb::ValueObjectSP &result_valobj_sp,
  Error &error,
  uint32_t line_offset = 0,
+ std::string *fixed_expression = nullptr,
  lldb::ModuleSP *jit_module_sp_ptr = nullptr);
 
 static const Error::ValueType kNoResult = 0x1001; ///< 
ValueObject::GetError() returns this if there is no result from the expression.
+
+const char *
+GetFixedText()
+{
+if (m_fixed_text.empty())
+return nullptr;
+return m_fixed_text.c_str();
+}
 
 protected:
 static lldb::addr_t
@@ -321,6 +333,7 @@ protected:
 Address

[Lldb-commits] [lldb] r264794 - LLDB top of tree SVN fails to attach to a MacOSX native process by pid only (no executable).

2016-03-29 Thread Greg Clayton via lldb-commits 
Author: gclayton
Date: Tue Mar 29 17:09:24 2016
New Revision: 264794

URL: http://llvm.org/viewvc/llvm-project?rev=264794&view=rev
Log:
LLDB top of tree SVN fails to attach to a MacOSX native process by pid only (no 
executable). 

The problem was that the static DynamicLoaderDarwinKernel::Initialize() was 
recently changed to come before DynamicLoaderMacOSXDYLD::Initialize() which 
caused the DynamicLoaderDarwinKernel::CreateInstance(...) to be called before 
DynamicLoaderMacOSXDYLD::CreateInstance(...) and DynamicLoaderDarwinKernel 
would claim it could be the dynamic loader for a user space MacOSX process. The 
fix is to make DynamicLoaderDarwinKernel::CreateInstance() a bit more thourough 
when vetting the process so that it doesn't claim MacOSX user space processes.

 


Modified:

lldb/trunk/source/Plugins/DynamicLoader/Darwin-Kernel/DynamicLoaderDarwinKernel.cpp

Modified: 
lldb/trunk/source/Plugins/DynamicLoader/Darwin-Kernel/DynamicLoaderDarwinKernel.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/DynamicLoader/Darwin-Kernel/DynamicLoaderDarwinKernel.cpp?rev=264794&r1=264793&r2=264794&view=diff
==
--- 
lldb/trunk/source/Plugins/DynamicLoader/Darwin-Kernel/DynamicLoaderDarwinKernel.cpp
 (original)
+++ 
lldb/trunk/source/Plugins/DynamicLoader/Darwin-Kernel/DynamicLoaderDarwinKernel.cpp
 Tue Mar 29 17:09:24 2016
@@ -181,8 +181,8 @@ DynamicLoaderDarwinKernel::CreateInstanc
 // At this point if there is an ExecutableModule, it is a kernel and the 
Target is some variant of an Apple system.  
 // If the Process hasn't provided the kernel load address, we need to look 
around in memory to find it.
 
-addr_t kernel_load_address = SearchForDarwinKernel (process);
-if (kernel_load_address != LLDB_INVALID_ADDRESS)
+const addr_t kernel_load_address = SearchForDarwinKernel (process);
+if (CheckForKernelImageAtAddress (kernel_load_address, process).IsValid())
 {
 process->SetCanRunCode(false);
 return new DynamicLoaderDarwinKernel (process, kernel_load_address);


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

[Lldb-commits] [lldb] r264810 - Fixed the failing test TestCommandScriptImmediateOutput on MacOSX. Turns out that there are few things to watch out for when writing pexpect tests:

2016-03-29 Thread Greg Clayton via lldb-commits 
Author: gclayton
Date: Tue Mar 29 19:02:13 2016
New Revision: 264810

URL: http://llvm.org/viewvc/llvm-project?rev=264810&view=rev
Log:
Fixed the failing test TestCommandScriptImmediateOutput on MacOSX. Turns out 
that there are few things to watch out for when writing pexpect tests:

1 - If you plan on looking for the "(lldb) " prompt as a regular expression, 
look for "\(lldb\) " so you don't just find "lldb".
2 - Make sure to not use colors (specify --no-use-colors as an option to lldb 
when launching it) as our editline will print:

"(lldb) (lldb) "

where "" is a work around that is used to allow us to colorize our 
prompts. The bad thing is this will make pexepct code like this not execute as 
you would expect:

prompt = "\(lldb\) "
self.child.sendline("breakpoint set ...", prompt)
self.child.sendline("breakpoint clear ...", prompt)

The problem is the first "sendline" will create two lldb prompts and will match 
both the first and second prompts and you output will get off. So be sure to 
disable colors if you need to.

Fixed a case where "TestCommandScriptImmediateOutput.py" would fail if you have 
spaces in your directory names. I modified custom_command.py to use shlex to 
parse arguments and I quoted the file path we sent down to the 
custom_command.write_file function.


Modified:

lldb/trunk/packages/Python/lldbsuite/test/functionalities/command_script_immediate_output/TestCommandScriptImmediateOutput.py

lldb/trunk/packages/Python/lldbsuite/test/functionalities/command_script_immediate_output/custom_command.py
lldb/trunk/packages/Python/lldbsuite/test/lldbpexpect.py

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/command_script_immediate_output/TestCommandScriptImmediateOutput.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/command_script_immediate_output/TestCommandScriptImmediateOutput.py?rev=264810&r1=264809&r2=264810&view=diff
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/command_script_immediate_output/TestCommandScriptImmediateOutput.py
 (original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/command_script_immediate_output/TestCommandScriptImmediateOutput.py
 Tue Mar 29 19:02:13 2016
@@ -29,8 +29,8 @@ class CommandScriptImmediateOutputTestCa
 self.launch(timeout=60)
 
 script = os.path.join(os.getcwd(), 'custom_command.py')
-prompt = "(lldb)"
-
+prompt = "\(lldb\) "
+  
 self.sendline('command script import %s' % script, patterns=[prompt])
 self.sendline('command script add -f custom_command.command_function 
mycommand', patterns=[prompt])
 self.sendline('mycommand', patterns='this is a test string, just a 
test string')
@@ -52,7 +52,7 @@ class CommandScriptImmediateOutputTestCa
 
 self.sendline('command script add -f custom_command.write_file 
mywrite', patterns=[prompt])
 for path, mode in test_files.iteritems():
-command = 'mywrite ' + path + ' ' + mode
+command = 'mywrite "' + path + '" ' + mode
 
 self.sendline(command, patterns=[prompt])
 

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/command_script_immediate_output/custom_command.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/command_script_immediate_output/custom_command.py?rev=264810&r1=264809&r2=264810&view=diff
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/command_script_immediate_output/custom_command.py
 (original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/command_script_immediate_output/custom_command.py
 Tue Mar 29 19:02:13 2016
@@ -1,16 +1,16 @@
 from __future__ import print_function
 
 import sys
+import shlex
 
 def command_function(debugger, command, exe_ctx, result, internal_dict):
 result.SetImmediateOutputFile(sys.__stdout__)
 print('this is a test string, just a test string', file=result)
 
 def write_file(debugger, command, exe_ctx, result, internal_dict):
-args = command.split(' ')
+args = shlex.split(command)
 path = args[0]
 mode = args[1]
-
 with open(path, mode) as f:
 result.SetImmediateOutputFile(f)
 if not mode in ['r']:

Modified: lldb/trunk/packages/Python/lldbsuite/test/lldbpexpect.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/lldbpexpect.py?rev=264810&r1=264809&r2=264810&view=diff
==
--- lldb/trunk/packages/Python/lldbsuite/test/lldbpexpect.py (original)
+++ lldb/trunk/packages/Python/lldbsuite/test/lldbpexpect.py Tue Mar 29 
19:02:13

Re: [Lldb-commits] [PATCH] D18531: Allow gdbremote process to read modules from memory

2016-03-29 Thread Todd Fiala via lldb-commits 
tfiala added a subscriber: tfiala.
tfiala added a comment.

The general idea looks good. You'll want to reach out to the Hexagon dynamic 
loader author first on any proposed changes there, though.

Thanks!

-Todd


http://reviews.llvm.org/D18531



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

Re: [Lldb-commits] [PATCH] D18531: Allow gdbremote process to read modules from memory

2016-03-29 Thread Todd Fiala via lldb-commits 
The general idea looks good. You'll want to reach out to the Hexagon dynamic 
loader author first on any proposed changes there, though.

Thanks!

-Todd

> On Mar 29, 2016, at 11:45 AM, Francis Ricci  wrote:
> 
> fjricci updated this revision to Diff 51962.
> fjricci added a comment.
> 
> Refactor to remove code duplication
> 
> 
> http://reviews.llvm.org/D18531
> 
> Files:
>  include/lldb/Target/DynamicLoader.h
>  source/Plugins/DynamicLoader/Hexagon-DYLD/DynamicLoaderHexagonDYLD.cpp
>  source/Plugins/DynamicLoader/Hexagon-DYLD/DynamicLoaderHexagonDYLD.h
>  source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
>  source/Plugins/Process/gdb-remote/ProcessGDBRemote.h
> 
> 
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] r264821 - Don't register the addresses of private symbols from expressions.

2016-03-29 Thread Sean Callanan via lldb-commits 
Author: spyffe
Date: Tue Mar 29 22:44:51 2016
New Revision: 264821

URL: http://llvm.org/viewvc/llvm-project?rev=264821&view=rev
Log:
Don't register the addresses of private symbols from expressions.

They're not supposed to go in the symbol table, and in fact the way the JIT
is currently implemented it sometimes crashes when you try to get the
address of such a function.  So we skip them.

Modified:
lldb/trunk/source/Expression/IRExecutionUnit.cpp

Modified: lldb/trunk/source/Expression/IRExecutionUnit.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Expression/IRExecutionUnit.cpp?rev=264821&r1=264820&r2=264821&view=diff
==
--- lldb/trunk/source/Expression/IRExecutionUnit.cpp (original)
+++ lldb/trunk/source/Expression/IRExecutionUnit.cpp Tue Mar 29 22:44:51 2016
@@ -344,7 +344,7 @@ IRExecutionUnit::GetRunnableInfo(Error &
 
 for (llvm::Function &function : *m_module)
 {
-if (function.isDeclaration())
+if (function.isDeclaration() || function.hasPrivateLinkage())
 continue;
 
 const bool external = function.hasExternalLinkage() || 
function.hasLinkOnceODRLinkage();


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