Re: [Lldb-commits] [PATCH] D18335: Fix for missing prompt on Windows

[Greg Clayton via lldb-commits]

clayborg added a comment.

Sounds good. This code is very tricky and we need to find a way to control this 
so that these issues never happen. When we do this, it will hopefully fix these 
kinds of issues for everyone. Thanks for taking the extra time to look into it 
and at least you have made the windows experience much better than it used to 
be.


http://reviews.llvm.org/D18335



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

[Lldb-commits] LLVM buildmaster will be updated and restarted tonight

[Galina Kistanova via lldb-commits]

Hello everyone,

LLVM buildmaster will be updated and restarted after 7 PM Pacific time
today.

Thanks

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

Re: [Lldb-commits] [PATCH] D18381: Decouple ClangASTContext from DWARF

[Zachary Turner via lldb-commits]

Having trouble building on OSX.

ERROR:root:Unable to find swig executable: 'module' object has no attribute
'OSError'

Command /bin/sh failed with exit code 250


But "which swig" finds it just fine.  It's been a long time since I've
built on OSX so I don't know if something has changed.

In any case, let me know if there's something I should be doing.

On Wed, Mar 23, 2016 at 4:12 PM Zachary Turner  wrote:

> zturner added a comment.
>
> It's been a while since I've used my Mac.  I'll fire it up and see if I
> can get it going, but no promises.  I'll update tomorrow
>
>
> http://reviews.llvm.org/D18381
>
>
>
>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [PATCH] D18228: Make File option flags consistent for Python API

[Francis Ricci via lldb-commits]

fjricci added a comment.

Friendly ping.


http://reviews.llvm.org/D18228



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

[Lldb-commits] [PATCH] D18459: Fix FILE * leak in Python API

[Francis Ricci via lldb-commits]

fjricci created this revision.
fjricci added reviewers: clayborg, granata.enrico, zturner.
fjricci added subscribers: sas, lldb-commits.

This reverts some of the changes made by:
r257644
r250530
r250525

The changes made in these patches result in leaking the FILE* passed
to SetImmediateOutputFile. GetStream() will dup() the fd held by the
python caller and create a new FILE*. It will then pass this FILE*
to SetImmediateOutputFile, which always uses the flag
transfer_ownership=false when it creates a File from the FILE*.

Since transfer_ownership is false, the lldb File destructor will not
close the underlying FILE*. Because this FILE* came from a dup-ed fd,
it will also not be closed when the python caller closes its file.

Leaking the FILE* causes issues if the same file is used multiple times
by different python callers during the same lldb run, even if these
callers open and close the python file properly, as you can end up
with issues due to multiple buffered writes to the same file.

http://reviews.llvm.org/D18459

Files:
  scripts/Python/python-typemaps.swig

Index: scripts/Python/python-typemaps.swig
===
--- scripts/Python/python-typemaps.swig
+++ scripts/Python/python-typemaps.swig
@@ -520,16 +520,7 @@
   }
}
else
-   {
-  PythonFile py_file(PyRefType::Borrowed, $input);
-  File file;
-  if (!py_file.GetUnderlyingFile(file))
- return nullptr;
-
-  $1 = file.GetStream();
-  if ($1)
- file.Clear();
-}
+ $1 = PyFile_AsFile($input);
 }
 
 %typemap(out) FILE * {


Index: scripts/Python/python-typemaps.swig
===
--- scripts/Python/python-typemaps.swig
+++ scripts/Python/python-typemaps.swig
@@ -520,16 +520,7 @@
   }
}
else
-   {
-  PythonFile py_file(PyRefType::Borrowed, $input);
-  File file;
-  if (!py_file.GetUnderlyingFile(file))
- return nullptr;
-
-  $1 = file.GetStream();
-  if ($1)
- file.Clear();
-}
+ $1 = PyFile_AsFile($input);
 }
 
 %typemap(out) FILE * {
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [PATCH] D18459: Fix FILE * leak in Python API

[Zachary Turner via lldb-commits]

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

This patch won't work.  `PyFile_AsFile` doesn't exist on Python 3.  Anything 
that you need done to make this work has to be wrapped up in `PythonFile` class 
as it was before, because that is the place where you can add Python version 
specific code to do different things with Py2 and Py3.


http://reviews.llvm.org/D18459



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

[Lldb-commits] [lldb] r264332 - Fix for missing prompt on Windows

[Ted Woodward via lldb-commits]

Author: ted
Date: Thu Mar 24 15:35:03 2016
New Revision: 264332

URL: http://llvm.org/viewvc/llvm-project?rev=264332&view=rev
Log:
Fix for missing prompt on Windows

Summary: On Windows (and possibly other hosts with LLDB_DISABLE_LIBEDIT 
defined), the (lldb) prompt won't print after async output, like from a 
breakpoint hit or a step. This patch forces the prompt to be printed out after 
async output.

Reviewers: zturner, clayborg

Subscribers: amccarth, lldb-commits

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

Modified:
lldb/trunk/source/Core/IOHandler.cpp

Modified: lldb/trunk/source/Core/IOHandler.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Core/IOHandler.cpp?rev=264332&r1=264331&r2=264332&view=diff
==
--- lldb/trunk/source/Core/IOHandler.cpp (original)
+++ lldb/trunk/source/Core/IOHandler.cpp Thu Mar 24 15:35:03 2016
@@ -47,6 +47,10 @@
 #include "lldb/Target/StackFrame.h"
 #endif
 
+#ifdef _MSC_VER
+#include 
+#endif
+
 using namespace lldb;
 using namespace lldb_private;
 
@@ -773,7 +777,26 @@ IOHandlerEditline::PrintAsync (Stream *s
 m_editline_ap->PrintAsync(stream, s, len);
 else
 #endif
+{
+const char *prompt = GetPrompt();
+#ifdef _MSC_VER
+if (prompt)
+{
+// Back up over previous prompt using Windows API
+CONSOLE_SCREEN_BUFFER_INFO screen_buffer_info;
+HANDLE console_handle = GetStdHandle(STD_OUTPUT_HANDLE);
+GetConsoleScreenBufferInfo(console_handle, &screen_buffer_info);
+COORD coord = screen_buffer_info.dwCursorPosition;
+coord.X -= strlen(prompt);
+if (coord.X < 0)
+coord.X = 0;
+SetConsoleCursorPosition(console_handle, coord);
+}
+#endif
 IOHandler::PrintAsync(stream, s, len);
+if (prompt)
+IOHandler::PrintAsync(GetOutputStreamFile().get(), prompt, 
strlen(prompt));
+}
 }
 
 // we may want curses to be disabled for some builds


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

Re: [Lldb-commits] [PATCH] D18381: Decouple ClangASTContext from DWARF

[Greg Clayton via lldb-commits]

You you building with Xcode? You should be building by checking out lldb at the 
top level, then typing:

% xcodebuild -configuration Debug


> On Mar 24, 2016, at 12:31 PM, Zachary Turner  wrote:
> 
> Having trouble building on OSX.
> 
> ERROR:root:Unable to find swig executable: 'module' object has no attribute 
> 'OSError'
> 
> Command /bin/sh failed with exit code 250
> 
> 
> 
> But "which swig" finds it just fine.  It's been a long time since I've built 
> on OSX so I don't know if something has changed.
> 
> In any case, let me know if there's something I should be doing.
> 
> 
> On Wed, Mar 23, 2016 at 4:12 PM Zachary Turner  wrote:
> zturner added a comment.
> 
> It's been a while since I've used my Mac.  I'll fire it up and see if I can 
> get it going, but no promises.  I'll update tomorrow
> 
> 
> http://reviews.llvm.org/D18381
> 
> 
> 

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

Re: [Lldb-commits] [PATCH] D18381: Decouple ClangASTContext from DWARF

[Zachary Turner via lldb-commits]

Yes I was doing it from inside the IDE though.  I selected lldb-tool,
64-bit, and hit Product -> Build

On Thu, Mar 24, 2016 at 2:11 PM Greg Clayton  wrote:

> You you building with Xcode? You should be building by checking out lldb
> at the top level, then typing:
>
> % xcodebuild -configuration Debug
>
>
> > On Mar 24, 2016, at 12:31 PM, Zachary Turner  wrote:
> >
> > Having trouble building on OSX.
> >
> > ERROR:root:Unable to find swig executable: 'module' object has no
> attribute 'OSError'
> >
> > Command /bin/sh failed with exit code 250
> >
> >
> >
> > But "which swig" finds it just fine.  It's been a long time since I've
> built on OSX so I don't know if something has changed.
> >
> > In any case, let me know if there's something I should be doing.
> >
> >
> > On Wed, Mar 23, 2016 at 4:12 PM Zachary Turner 
> wrote:
> > zturner added a comment.
> >
> > It's been a while since I've used my Mac.  I'll fire it up and see if I
> can get it going, but no promises.  I'll update tomorrow
> >
> >
> > http://reviews.llvm.org/D18381
> >
> >
> >
>
>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [PATCH] D18381: Decouple ClangASTContext from DWARF

[Greg Clayton via lldb-commits]

I usually select "desktop" as the target. Is this patch up to date? If so, I 
can apply and compile it and let you know what the results are. 

> On Mar 24, 2016, at 2:21 PM, Zachary Turner  wrote:
> 
> Yes I was doing it from inside the IDE though.  I selected lldb-tool, 64-bit, 
> and hit Product -> Build
> 
> On Thu, Mar 24, 2016 at 2:11 PM Greg Clayton  wrote:
> You you building with Xcode? You should be building by checking out lldb at 
> the top level, then typing:
> 
> % xcodebuild -configuration Debug
> 
> 
> > On Mar 24, 2016, at 12:31 PM, Zachary Turner  wrote:
> >
> > Having trouble building on OSX.
> >
> > ERROR:root:Unable to find swig executable: 'module' object has no attribute 
> > 'OSError'
> >
> > Command /bin/sh failed with exit code 250
> >
> >
> >
> > But "which swig" finds it just fine.  It's been a long time since I've 
> > built on OSX so I don't know if something has changed.
> >
> > In any case, let me know if there's something I should be doing.
> >
> >
> > On Wed, Mar 23, 2016 at 4:12 PM Zachary Turner  wrote:
> > zturner added a comment.
> >
> > It's been a while since I've used my Mac.  I'll fire it up and see if I can 
> > get it going, but no promises.  I'll update tomorrow
> >
> >
> > http://reviews.llvm.org/D18381
> >
> >
> >
> 

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

[Lldb-commits] [lldb] r264343 - Make 'type lookup' print an error message instead of complete radio silence when it can't find a type matching user input

[Enrico Granata via lldb-commits]

Author: enrico
Date: Thu Mar 24 16:32:39 2016
New Revision: 264343

URL: http://llvm.org/viewvc/llvm-project?rev=264343&view=rev
Log:
Make 'type lookup' print an error message instead of complete radio silence 
when it can't find a type matching user input

It would be fun to make it provide suggestions (e.g. 'can't find NString, did 
you mean NSString instead?'), but this worries me a little bit on the account 
of just how thorough of a type system scan it would have to do


Modified:

lldb/trunk/packages/Python/lldbsuite/test/functionalities/type_lookup/TestTypeLookup.py
lldb/trunk/source/Commands/CommandObjectType.cpp

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/type_lookup/TestTypeLookup.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/type_lookup/TestTypeLookup.py?rev=264343&r1=264342&r2=264343&view=diff
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/type_lookup/TestTypeLookup.py
 (original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/type_lookup/TestTypeLookup.py
 Thu Mar 24 16:32:39 2016
@@ -42,3 +42,4 @@ class TypeLookupTestCase(TestBase):
 self.expect('type lookup NSURL', substrs=['NSURL'])
 self.expect('type lookup NSArray', substrs=['NSArray'])
 self.expect('type lookup NSObject', substrs=['NSObject', 'isa'])
+self.expect('type lookup PleaseDontBeARealTypeThatExists', 
substrs=["no type was found matching 'PleaseDontBeARealTypeThatExists'"])

Modified: lldb/trunk/source/Commands/CommandObjectType.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Commands/CommandObjectType.cpp?rev=264343&r1=264342&r2=264343&view=diff
==
--- lldb/trunk/source/Commands/CommandObjectType.cpp (original)
+++ lldb/trunk/source/Commands/CommandObjectType.cpp Thu Mar 24 16:32:39 2016
@@ -3404,6 +3404,9 @@ public:
 }
 }
 
+if (!any_found)
+result.AppendMessageWithFormat("no type was found matching 
'%s'\n", name_of_type);
+
 result.SetStatus (any_found ? lldb::eReturnStatusSuccessFinishResult : 
lldb::eReturnStatusSuccessFinishNoResult);
 return true;
 }


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

Re: [Lldb-commits] [PATCH] D18381: Decouple ClangASTContext from DWARF

[Zachary Turner via lldb-commits]

zturner updated this revision to Diff 51605.
zturner added a comment.

Update patch.


http://reviews.llvm.org/D18381

Files:
  include/lldb/Symbol/ClangASTContext.h
  include/lldb/Symbol/ClangASTImporter.h
  include/lldb/Symbol/ClangUtil.h
  include/lldb/Symbol/TypeSystem.h
  source/Plugins/ExpressionParser/Clang/ASTDumper.cpp
  source/Plugins/ExpressionParser/Clang/ClangASTSource.cpp
  source/Plugins/ExpressionParser/Clang/IRForTarget.cpp
  source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCDeclVendor.cpp
  
source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCTypeEncodingParser.cpp
  source/Plugins/SymbolFile/DWARF/DWARFASTParser.h
  source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
  source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.h
  source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
  source/Symbol/CMakeLists.txt
  source/Symbol/ClangASTContext.cpp
  source/Symbol/ClangASTImporter.cpp
  source/Symbol/ClangUtil.cpp

Index: source/Symbol/ClangUtil.cpp
===
--- /dev/null
+++ source/Symbol/ClangUtil.cpp
@@ -0,0 +1,58 @@
+//===-- ClangUtil.cpp ---*- C++ -*-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+// A collection of helper methods and data structures for manipulating clang
+// types and decls.
+//===--===//
+
+#include "lldb/Symbol/ClangUtil.h"
+#include "lldb/Symbol/ClangASTContext.h"
+
+using namespace clang;
+using namespace lldb_private;
+
+bool
+ClangUtil::IsClangType(const CompilerType &ct)
+{
+if (llvm::dyn_cast_or_null(ct.GetTypeSystem()) == nullptr)
+return false;
+
+if (!ct.GetOpaqueQualType())
+return false;
+
+return true;
+}
+
+QualType
+ClangUtil::GetQualType(const CompilerType &ct)
+{
+// Make sure we have a clang type before making a clang::QualType
+if (!IsClangType(ct))
+return QualType();
+
+return QualType::getFromOpaquePtr(ct.GetOpaqueQualType());
+}
+
+QualType
+ClangUtil::GetCanonicalQualType(const CompilerType &ct)
+{
+if (!IsClangType(ct))
+return QualType();
+
+return GetQualType(ct).getCanonicalType();
+}
+
+CompilerType
+ClangUtil::RemoveFastQualifiers(const CompilerType &ct)
+{
+if (!IsClangType(ct))
+return ct;
+
+QualType qual_type(GetQualType(ct));
+qual_type.getQualifiers().removeFastQualifiers();
+return CompilerType(ct.GetTypeSystem(), qual_type.getAsOpaquePtr());
+}
Index: source/Symbol/ClangASTImporter.cpp
===
--- source/Symbol/ClangASTImporter.cpp
+++ source/Symbol/ClangASTImporter.cpp
@@ -7,16 +7,17 @@
 //
 //===--===//
 
-#include "clang/AST/Decl.h"
-#include "clang/AST/DeclCXX.h"
-#include "clang/AST/DeclObjC.h"
-#include "llvm/Support/raw_ostream.h"
+#include "lldb/Symbol/ClangASTImporter.h"
 #include "lldb/Core/Log.h"
 #include "lldb/Core/Module.h"
 #include "lldb/Symbol/ClangASTContext.h"
-#include "lldb/Symbol/ClangASTImporter.h"
 #include "lldb/Symbol/ClangExternalASTSourceCommon.h"
+#include "lldb/Symbol/ClangUtil.h"
 #include "lldb/Utility/LLDBAssert.h"
+#include "clang/AST/Decl.h"
+#include "clang/AST/DeclCXX.h"
+#include "clang/AST/DeclObjC.h"
+#include "llvm/Support/raw_ostream.h"
 
 using namespace lldb_private;
 using namespace clang;
@@ -347,6 +348,211 @@
 return result;
 }
 
+bool
+ClangASTImporter::CanImport(const CompilerType &type)
+{
+if (!ClangUtil::IsClangType(type))
+return false;
+
+// TODO: remove external completion BOOL
+// CompleteAndFetchChildren should get the Decl out and check for the
+
+clang::QualType qual_type(ClangUtil::GetCanonicalQualType(ClangUtil::RemoveFastQualifiers(type)));
+
+const clang::Type::TypeClass type_class = qual_type->getTypeClass();
+switch (type_class)
+{
+case clang::Type::Record:
+{
+const clang::CXXRecordDecl *cxx_record_decl = qual_type->getAsCXXRecordDecl();
+if (cxx_record_decl)
+{
+if (ResolveDeclOrigin(cxx_record_decl, NULL, NULL))
+return true;
+}
+}
+break;
+
+case clang::Type::Enum:
+{
+clang::EnumDecl *enum_decl = llvm::cast(qual_type)->getDecl();
+if (enum_decl)
+{
+if (ResolveDeclOrigin(enum_decl, NULL, NULL))
+return true;
+}
+}
+break;
+
+case clang::Type::ObjCObject:
+case clang::Type::ObjCInterface:
+{
+const clang::ObjCObjectType *objc_class_type = llvm::dyn_cast(qual_type);
+if (objc_class_type)
+{
+  

Re: [Lldb-commits] [PATCH] D18381: Decouple ClangASTContext from DWARF

[Zachary Turner via lldb-commits]

It's updated now.  I'm still getting errors building from inside Xcode when
I use the IDE, but it works from the command line.  But running the test
pops up hundreds of dialogs asking me to enter my password to take control
of another process, so I'm not sure how to disable that.

Anyway I updated my patch if you want to give it a go.  I'm not sure why I
didn't get any linker errors, because I didn't update the Xcode project to
include ClangUtil.cpp, so I was expecting some undefined symbol errors.

On Thu, Mar 24, 2016 at 2:34 PM Greg Clayton  wrote:

> I usually select "desktop" as the target. Is this patch up to date? If so,
> I can apply and compile it and let you know what the results are.
>
> > On Mar 24, 2016, at 2:21 PM, Zachary Turner  wrote:
> >
> > Yes I was doing it from inside the IDE though.  I selected lldb-tool,
> 64-bit, and hit Product -> Build
> >
> > On Thu, Mar 24, 2016 at 2:11 PM Greg Clayton  wrote:
> > You you building with Xcode? You should be building by checking out lldb
> at the top level, then typing:
> >
> > % xcodebuild -configuration Debug
> >
> >
> > > On Mar 24, 2016, at 12:31 PM, Zachary Turner 
> wrote:
> > >
> > > Having trouble building on OSX.
> > >
> > > ERROR:root:Unable to find swig executable: 'module' object has no
> attribute 'OSError'
> > >
> > > Command /bin/sh failed with exit code 250
> > >
> > >
> > >
> > > But "which swig" finds it just fine.  It's been a long time since I've
> built on OSX so I don't know if something has changed.
> > >
> > > In any case, let me know if there's something I should be doing.
> > >
> > >
> > > On Wed, Mar 23, 2016 at 4:12 PM Zachary Turner 
> wrote:
> > > zturner added a comment.
> > >
> > > It's been a while since I've used my Mac.  I'll fire it up and see if
> I can get it going, but no promises.  I'll update tomorrow
> > >
> > >
> > > http://reviews.llvm.org/D18381
> > >
> > >
> > >
> >
>
>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [PATCH] D18381: Decouple ClangASTContext from DWARF

[Enrico Granata via lldb-commits]

> On Mar 24, 2016, at 2:44 PM, Zachary Turner via lldb-commits 
>  wrote:
> 
> It's updated now.  I'm still getting errors building from inside Xcode when I 
> use the IDE, but it works from the command line.  But running the test pops 
> up hundreds of dialogs asking me to enter my password to take control of 
> another process, so I'm not sure how to disable that.  
> 

If you type your password once, then you should be able to dismiss all other 
prompts with no detriment.
Essentially, the first time you try to actually use the lldb_codesign 
certificate to take control of an inferior process, OS X asks for your password 
for extra security

> Anyway I updated my patch if you want to give it a go.  I'm not sure why I 
> didn't get any linker errors, because I didn't update the Xcode project to 
> include ClangUtil.cpp, so I was expecting some undefined symbol errors.
> 
> On Thu, Mar 24, 2016 at 2:34 PM Greg Clayton  > wrote:
> I usually select "desktop" as the target. Is this patch up to date? If so, I 
> can apply and compile it and let you know what the results are.
> 
> > On Mar 24, 2016, at 2:21 PM, Zachary Turner  > > wrote:
> >
> > Yes I was doing it from inside the IDE though.  I selected lldb-tool, 
> > 64-bit, and hit Product -> Build
> >
> > On Thu, Mar 24, 2016 at 2:11 PM Greg Clayton  > > wrote:
> > You you building with Xcode? You should be building by checking out lldb at 
> > the top level, then typing:
> >
> > % xcodebuild -configuration Debug
> >
> >
> > > On Mar 24, 2016, at 12:31 PM, Zachary Turner  > > > wrote:
> > >
> > > Having trouble building on OSX.
> > >
> > > ERROR:root:Unable to find swig executable: 'module' object has no 
> > > attribute 'OSError'
> > >
> > > Command /bin/sh failed with exit code 250
> > >
> > >
> > >
> > > But "which swig" finds it just fine.  It's been a long time since I've 
> > > built on OSX so I don't know if something has changed.
> > >
> > > In any case, let me know if there's something I should be doing.
> > >
> > >
> > > On Wed, Mar 23, 2016 at 4:12 PM Zachary Turner  > > > wrote:
> > > zturner added a comment.
> > >
> > > It's been a while since I've used my Mac.  I'll fire it up and see if I 
> > > can get it going, but no promises.  I'll update tomorrow
> > >
> > >
> > > http://reviews.llvm.org/D18381 
> > >
> > >
> > >
> >
> 
> ___
> lldb-commits mailing list
> lldb-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


Thanks,
- Enrico
📩 egranata@.com ☎️ 27683

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

[Lldb-commits] [lldb] r264346 - Get rid of a global constructor that was causing a warning on MacOSX and make the Timer safe to use after the main threads global destructor chain is called.

[Greg Clayton via lldb-commits]

Author: gclayton
Date: Thu Mar 24 16:46:47 2016
New Revision: 264346

URL: http://llvm.org/viewvc/llvm-project?rev=264346&view=rev
Log:
Get rid of a global constructor that was causing a warning on MacOSX and make 
the Timer safe to use after the main threads global destructor chain is called.


Modified:
lldb/trunk/include/lldb/Core/Timer.h
lldb/trunk/source/Core/Timer.cpp

Modified: lldb/trunk/include/lldb/Core/Timer.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Core/Timer.h?rev=264346&r1=264345&r2=264346&view=diff
==
--- lldb/trunk/include/lldb/Core/Timer.h (original)
+++ lldb/trunk/include/lldb/Core/Timer.h Thu Mar 24 16:46:47 2016
@@ -86,7 +86,6 @@ protected:
 
 static std::atomic g_quiet;
 static std::atomic g_display_depth;
-static std::mutex g_file_mutex;
 
 private:
 Timer();

Modified: lldb/trunk/source/Core/Timer.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Core/Timer.cpp?rev=264346&r1=264345&r2=264346&view=diff
==
--- lldb/trunk/source/Core/Timer.cpp (original)
+++ lldb/trunk/source/Core/Timer.cpp Thu Mar 24 16:46:47 2016
@@ -39,7 +39,18 @@ namespace
 
 std::atomic Timer::g_quiet(true);
 std::atomic Timer::g_display_depth(0);
-std::mutex Timer::g_file_mutex;
+static std::mutex &
+GetFileMutex()
+{
+static std::mutex *g_file_mutex_ptr = nullptr;
+static std::once_flag g_once_flag;
+std::call_once(g_once_flag,  []() {
+// leaked on purpose to ensure this mutex works after main thread has 
run
+// global C++ destructor chain
+g_file_mutex_ptr = new std::mutex();
+});
+return *g_file_mutex_ptr;
+}
 
 
 static Mutex &
@@ -97,7 +108,7 @@ Timer::Timer (const char *category, cons
 {
 if (g_quiet == false)
 {
-std::lock_guard lock(g_file_mutex);
+std::lock_guard lock(GetFileMutex());
 
 // Indent
 ::fprintf(stdout, "%*s", stack->m_depth * TIMER_INDENT_AMOUNT, "");
@@ -152,7 +163,7 @@ Timer::~Timer()
 
 if (g_quiet == false)
 {
-std::lock_guard lock(g_file_mutex);
+std::lock_guard lock(GetFileMutex());
 ::fprintf(stdout, "%*s%.9f sec (%.9f sec)\n", (stack->m_depth - 1) 
* TIMER_INDENT_AMOUNT, "",
   total_nsec / 10.0, timer_nsec / 10.0);
 }


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

Re: [Lldb-commits] [PATCH] D18381: Decouple ClangASTContext from DWARF

[Zachary Turner via lldb-commits]

Is it one time until I reboot, or until the end of the test suite?

On Thu, Mar 24, 2016 at 2:51 PM Enrico Granata  wrote:

> On Mar 24, 2016, at 2:44 PM, Zachary Turner via lldb-commits <
> lldb-commits@lists.llvm.org> wrote:
>
> It's updated now.  I'm still getting errors building from inside Xcode
> when I use the IDE, but it works from the command line.  But running the
> test pops up hundreds of dialogs asking me to enter my password to take
> control of another process, so I'm not sure how to disable that.
>
>
> If you type your password once, then you should be able to dismiss all
> other prompts with no detriment.
> Essentially, the first time you try to actually use the lldb_codesign
> certificate to take control of an inferior process, OS X asks for your
> password for extra security
>
> Anyway I updated my patch if you want to give it a go.  I'm not sure why I
> didn't get any linker errors, because I didn't update the Xcode project to
> include ClangUtil.cpp, so I was expecting some undefined symbol errors.
>
> On Thu, Mar 24, 2016 at 2:34 PM Greg Clayton  wrote:
>
>> I usually select "desktop" as the target. Is this patch up to date? If
>> so, I can apply and compile it and let you know what the results are.
>>
>> > On Mar 24, 2016, at 2:21 PM, Zachary Turner  wrote:
>> >
>> > Yes I was doing it from inside the IDE though.  I selected lldb-tool,
>> 64-bit, and hit Product -> Build
>> >
>> > On Thu, Mar 24, 2016 at 2:11 PM Greg Clayton 
>> wrote:
>> > You you building with Xcode? You should be building by checking out
>> lldb at the top level, then typing:
>> >
>> > % xcodebuild -configuration Debug
>> >
>> >
>> > > On Mar 24, 2016, at 12:31 PM, Zachary Turner 
>> wrote:
>> > >
>> > > Having trouble building on OSX.
>> > >
>> > > ERROR:root:Unable to find swig executable: 'module' object has no
>> attribute 'OSError'
>> > >
>> > > Command /bin/sh failed with exit code 250
>> > >
>> > >
>> > >
>> > > But "which swig" finds it just fine.  It's been a long time since
>> I've built on OSX so I don't know if something has changed.
>> > >
>> > > In any case, let me know if there's something I should be doing.
>> > >
>> > >
>> > > On Wed, Mar 23, 2016 at 4:12 PM Zachary Turner 
>> wrote:
>> > > zturner added a comment.
>> > >
>> > > It's been a while since I've used my Mac.  I'll fire it up and see if
>> I can get it going, but no promises.  I'll update tomorrow
>> > >
>> > >
>> > > http://reviews.llvm.org/D18381
>> > >
>> > >
>> > >
>> >
>>
>> ___
> lldb-commits mailing list
> lldb-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
>
>
>
> Thanks,
> *- Enrico*
> 📩 egranata@.com ☎️ 27683
>
>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] r264347 - Get rid of two global constructors by making things static variables in the only function that uses these variables.

[Greg Clayton via lldb-commits]

Author: gclayton
Date: Thu Mar 24 16:48:10 2016
New Revision: 264347

URL: http://llvm.org/viewvc/llvm-project?rev=264347&view=rev
Log:
Get rid of two global constructors by making things static variables in the 
only function that uses these variables.


Modified:

lldb/trunk/source/Plugins/LanguageRuntime/RenderScript/RenderScriptRuntime/RenderScriptRuntime.cpp

lldb/trunk/source/Plugins/LanguageRuntime/RenderScript/RenderScriptRuntime/RenderScriptRuntime.h

Modified: 
lldb/trunk/source/Plugins/LanguageRuntime/RenderScript/RenderScriptRuntime/RenderScriptRuntime.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/LanguageRuntime/RenderScript/RenderScriptRuntime/RenderScriptRuntime.cpp?rev=264347&r1=264346&r2=264347&view=diff
==
--- 
lldb/trunk/source/Plugins/LanguageRuntime/RenderScript/RenderScriptRuntime/RenderScriptRuntime.cpp
 (original)
+++ 
lldb/trunk/source/Plugins/LanguageRuntime/RenderScript/RenderScriptRuntime/RenderScriptRuntime.cpp
 Thu Mar 24 16:48:10 2016
@@ -757,8 +757,6 @@ const uint32_t RenderScriptRuntime::Allo
 {eFormatVectorOfFloat32, eFormatVectorOfFloat32, sizeof(float) * 4}   // 
RS_TYPE_MATRIX_2X2
 };
 
-const std::string RenderScriptRuntime::s_runtimeExpandSuffix(".expand");
-const std::array 
RenderScriptRuntime::s_runtimeCoordVars{{"rsIndex", "p->current.y", 
"p->current.z"}};
 //--
 // Static Functions
 //--
@@ -3267,6 +3265,9 @@ RenderScriptRuntime::GetFrameVarAsUnsign
 bool
 RenderScriptRuntime::GetKernelCoordinate(RSCoordinate &coord, Thread 
*thread_ptr)
 {
+static const std::string s_runtimeExpandSuffix(".expand");
+static const std::array s_runtimeCoordVars{{"rsIndex", 
"p->current.y", "p->current.z"}};
+
 Log *log(GetLogIfAnyCategoriesSet(LIBLLDB_LOG_LANGUAGE));
 
 if (!thread_ptr)
@@ -3299,13 +3300,13 @@ RenderScriptRuntime::GetKernelCoordinate
 
 // Check if function name has .expand suffix
 std::string func_name(func_name_cstr);
-const int length_difference = func_name.length() - 
RenderScriptRuntime::s_runtimeExpandSuffix.length();
+const int length_difference = func_name.length() - 
s_runtimeExpandSuffix.length();
 if (length_difference <= 0)
 continue;
 
 const int32_t has_expand_suffix = func_name.compare(length_difference,
-
RenderScriptRuntime::s_runtimeExpandSuffix.length(),
-
RenderScriptRuntime::s_runtimeExpandSuffix);
+
s_runtimeExpandSuffix.length(),
+
s_runtimeExpandSuffix);
 
 if (has_expand_suffix != 0)
 continue;
@@ -3315,12 +3316,12 @@ RenderScriptRuntime::GetKernelCoordinate
 
 // Get values for variables in .expand frame that tell us the current 
kernel invocation
 bool found_coord_variables = true;
-assert(RenderScriptRuntime::s_runtimeCoordVars.size() == coord.size());
+assert(s_runtimeCoordVars.size() == coord.size());
 
 for (uint32_t i = 0; i < coord.size(); ++i)
 {
 uint64_t value = 0;
-if (!GetFrameVarAsUnsigned(frame_sp, 
RenderScriptRuntime::s_runtimeCoordVars[i], value))
+if (!GetFrameVarAsUnsigned(frame_sp, s_runtimeCoordVars[i], value))
 {
 found_coord_variables = false;
 break;

Modified: 
lldb/trunk/source/Plugins/LanguageRuntime/RenderScript/RenderScriptRuntime/RenderScriptRuntime.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/LanguageRuntime/RenderScript/RenderScriptRuntime/RenderScriptRuntime.h?rev=264347&r1=264346&r2=264347&view=diff
==
--- 
lldb/trunk/source/Plugins/LanguageRuntime/RenderScript/RenderScriptRuntime/RenderScriptRuntime.h
 (original)
+++ 
lldb/trunk/source/Plugins/LanguageRuntime/RenderScript/RenderScriptRuntime/RenderScriptRuntime.h
 Thu Mar 24 16:48:10 2016
@@ -321,8 +321,6 @@ protected:
 bool m_breakAllKernels;
 static const HookDefn s_runtimeHookDefns[];
 static const size_t s_runtimeHookCount;
-static const std::string s_runtimeExpandSuffix;
-static const std::array s_runtimeCoordVars;
 
 private:
 RenderScriptRuntime(Process *process); // Call CreateInstance instead.


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

Re: [Lldb-commits] [PATCH] D18381: Decouple ClangASTContext from DWARF

[Enrico Granata via lldb-commits]

> On Mar 24, 2016, at 2:53 PM, Zachary Turner  wrote:
> 
> Is it one time until I reboot, or until the end of the test suite?
> 

The former.

> On Thu, Mar 24, 2016 at 2:51 PM Enrico Granata  > wrote:
>> On Mar 24, 2016, at 2:44 PM, Zachary Turner via lldb-commits 
>> mailto:lldb-commits@lists.llvm.org>> wrote:
>> 
>> It's updated now.  I'm still getting errors building from inside Xcode when 
>> I use the IDE, but it works from the command line.  But running the test 
>> pops up hundreds of dialogs asking me to enter my password to take control 
>> of another process, so I'm not sure how to disable that.  
>> 
> 
> If you type your password once, then you should be able to dismiss all other 
> prompts with no detriment.
> Essentially, the first time you try to actually use the lldb_codesign 
> certificate to take control of an inferior process, OS X asks for your 
> password for extra security
> 
> 
>> Anyway I updated my patch if you want to give it a go.  I'm not sure why I 
>> didn't get any linker errors, because I didn't update the Xcode project to 
>> include ClangUtil.cpp, so I was expecting some undefined symbol errors.
>> 
>> On Thu, Mar 24, 2016 at 2:34 PM Greg Clayton > > wrote:
>> I usually select "desktop" as the target. Is this patch up to date? If so, I 
>> can apply and compile it and let you know what the results are.
>> 
>> > On Mar 24, 2016, at 2:21 PM, Zachary Turner > > > wrote:
>> >
>> > Yes I was doing it from inside the IDE though.  I selected lldb-tool, 
>> > 64-bit, and hit Product -> Build
>> >
>> > On Thu, Mar 24, 2016 at 2:11 PM Greg Clayton > > > wrote:
>> > You you building with Xcode? You should be building by checking out lldb 
>> > at the top level, then typing:
>> >
>> > % xcodebuild -configuration Debug
>> >
>> >
>> > > On Mar 24, 2016, at 12:31 PM, Zachary Turner > > > > wrote:
>> > >
>> > > Having trouble building on OSX.
>> > >
>> > > ERROR:root:Unable to find swig executable: 'module' object has no 
>> > > attribute 'OSError'
>> > >
>> > > Command /bin/sh failed with exit code 250
>> > >
>> > >
>> > >
>> > > But "which swig" finds it just fine.  It's been a long time since I've 
>> > > built on OSX so I don't know if something has changed.
>> > >
>> > > In any case, let me know if there's something I should be doing.
>> > >
>> > >
>> > > On Wed, Mar 23, 2016 at 4:12 PM Zachary Turner > > > > wrote:
>> > > zturner added a comment.
>> > >
>> > > It's been a while since I've used my Mac.  I'll fire it up and see if I 
>> > > can get it going, but no promises.  I'll update tomorrow
>> > >
>> > >
>> > > http://reviews.llvm.org/D18381 
>> > >
>> > >
>> > >
>> >
>> 
> 
>> ___
>> lldb-commits mailing list
>> lldb-commits@lists.llvm.org 
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits 
>> 
> 
> 
> Thanks,
> - Enrico
> 📩 egranata@.com ☎️ 27683
> 


Thanks,
- Enrico
📩 egranata@.com ☎️ 27683

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

[Lldb-commits] [lldb] r264348 - Get rid of a global constructor and also make this code safe to use after the global destructor chain has been run on the main thread.

[Greg Clayton via lldb-commits]

Author: gclayton
Date: Thu Mar 24 16:49:22 2016
New Revision: 264348

URL: http://llvm.org/viewvc/llvm-project?rev=264348&view=rev
Log:
Get rid of a global constructor and also make this code safe to use after the 
global destructor chain has been run on the main thread.


Modified:
lldb/trunk/source/Commands/CommandObjectPlatform.cpp

Modified: lldb/trunk/source/Commands/CommandObjectPlatform.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Commands/CommandObjectPlatform.cpp?rev=264348&r1=264347&r2=264348&view=diff
==
--- lldb/trunk/source/Commands/CommandObjectPlatform.cpp (original)
+++ lldb/trunk/source/Commands/CommandObjectPlatform.cpp Thu Mar 24 16:49:22 
2016
@@ -9,6 +9,7 @@
 
 // C Includes
 // C++ Includes
+#include 
 // Other libraries and framework includes
 // Project includes
 #include "CommandObjectPlatform.h"
@@ -1461,10 +1462,30 @@ protected:
 class CommandOptions : public Options
 {
 public:
-CommandOptions (CommandInterpreter &interpreter) :
-Options (interpreter),
-match_info ()
-{
+CommandOptions(CommandInterpreter &interpreter) :
+Options(interpreter),
+match_info(),
+show_args(false),
+verbose(false)
+{
+static std::once_flag g_once_flag;
+std::call_once(g_once_flag,  []() {
+PosixPlatformCommandOptionValidator *posix_validator = new 
PosixPlatformCommandOptionValidator();
+for (size_t i=0; g_option_table[i].short_option != 0; ++i)
+{
+switch (g_option_table[i].short_option)
+{
+case 'u':
+case 'U':
+case 'g':
+case 'G':
+g_option_table[i].validator = posix_validator;
+break;
+default:
+break;
+}
+}
+});
 }
 
 ~CommandOptions() override = default;
@@ -1576,7 +1597,7 @@ protected:
 // Options table: Required for subclasses of Options.
 
 static OptionDefinition g_option_table[];
-
+
 // Instance variables to hold the values for command options.
 
 ProcessInstanceInfoMatch match_info;
@@ -1587,11 +1608,6 @@ protected:
 CommandOptions m_options;
 };
 
-namespace
-{
-PosixPlatformCommandOptionValidator g_posix_validator;
-}
-
 OptionDefinition
 CommandObjectPlatformProcessList::CommandOptions::g_option_table[] =
 {
@@ -1602,10 +1618,10 @@ CommandObjectPlatformProcessList::Comman
 { LLDB_OPT_SET_5, true , "contains"   , 'c', 
OptionParser::eRequiredArgument, nullptr, nullptr, 0, eArgTypeProcessName  
, "Find processes with executable basenames that contain a string." },
 { LLDB_OPT_SET_6, true , "regex"  , 'r', 
OptionParser::eRequiredArgument, nullptr, nullptr, 0, 
eArgTypeRegularExpression, "Find processes with executable basenames that match 
a regular expression." },
 { LLDB_OPT_SET_FROM_TO(2, 6), false, "parent" , 'P', 
OptionParser::eRequiredArgument, nullptr, nullptr, 0, eArgTypePid  
, "Find processes that have a matching parent process ID." },
-{ LLDB_OPT_SET_FROM_TO(2, 6), false, "uid", 'u', 
OptionParser::eRequiredArgument, &g_posix_validator, nullptr, 0, 
eArgTypeUnsignedInteger  , "Find processes that have a matching user ID." },
-{ LLDB_OPT_SET_FROM_TO(2, 6), false, "euid"   , 'U', 
OptionParser::eRequiredArgument, &g_posix_validator, nullptr, 0, 
eArgTypeUnsignedInteger  , "Find processes that have a matching effective user 
ID." },
-{ LLDB_OPT_SET_FROM_TO(2, 6), false, "gid", 'g', 
OptionParser::eRequiredArgument, &g_posix_validator, nullptr, 0, 
eArgTypeUnsignedInteger  , "Find processes that have a matching group ID." },
-{ LLDB_OPT_SET_FROM_TO(2, 6), false, "egid"   , 'G', 
OptionParser::eRequiredArgument, &g_posix_validator, nullptr, 0, 
eArgTypeUnsignedInteger  , "Find processes that have a matching effective group 
ID." },
+{ LLDB_OPT_SET_FROM_TO(2, 6), false, "uid", 'u', 
OptionParser::eRequiredArgument, nullptr, nullptr, 0, eArgTypeUnsignedInteger  
, "Find processes that have a matching user ID." },
+{ LLDB_OPT_SET_FROM_TO(2, 6), false, "euid"   , 'U', 
OptionParser::eRequiredArgument, nullptr, nullptr, 0, eArgTypeUnsignedInteger  
, "Find processes that have a matching effective user ID." },
+{ LLDB_OPT_SET_FROM_TO(2, 6), false, "gid", 'g', 
OptionParser::eRequiredArgument, nullptr, nullptr, 0, eArgTypeUnsignedInteger  
, "Find processes that have a matching group ID." },
+{ LLDB_OPT_SET_FROM_TO(2, 6), false, "egid"   , 'G', 
OptionParser::eRequiredArgument, nullptr, nullptr, 0, eArgTypeUnsignedInteger  
, "Find processes that have a matching effective group

Re: [Lldb-commits] [PATCH] D18381: Decouple ClangASTContext from DWARF

[Jim Ingham via lldb-commits]

Once per login session.  You may also need to run:

sudo /usr/sbin/DevToolsSecurity --enable

if you've never debugged anything before.  You should only need to do this once 
per clean OS install.

Jim

> On Mar 24, 2016, at 2:53 PM, Zachary Turner via lldb-commits 
>  wrote:
> 
> Is it one time until I reboot, or until the end of the test suite?
> 
> On Thu, Mar 24, 2016 at 2:51 PM Enrico Granata  wrote:
>> On Mar 24, 2016, at 2:44 PM, Zachary Turner via lldb-commits 
>>  wrote:
>> 
>> It's updated now.  I'm still getting errors building from inside Xcode when 
>> I use the IDE, but it works from the command line.  But running the test 
>> pops up hundreds of dialogs asking me to enter my password to take control 
>> of another process, so I'm not sure how to disable that.  
>> 
> 
> If you type your password once, then you should be able to dismiss all other 
> prompts with no detriment.
> Essentially, the first time you try to actually use the lldb_codesign 
> certificate to take control of an inferior process, OS X asks for your 
> password for extra security
> 
>> Anyway I updated my patch if you want to give it a go.  I'm not sure why I 
>> didn't get any linker errors, because I didn't update the Xcode project to 
>> include ClangUtil.cpp, so I was expecting some undefined symbol errors.
>> 
>> On Thu, Mar 24, 2016 at 2:34 PM Greg Clayton  wrote:
>> I usually select "desktop" as the target. Is this patch up to date? If so, I 
>> can apply and compile it and let you know what the results are.
>> 
>> > On Mar 24, 2016, at 2:21 PM, Zachary Turner  wrote:
>> >
>> > Yes I was doing it from inside the IDE though.  I selected lldb-tool, 
>> > 64-bit, and hit Product -> Build
>> >
>> > On Thu, Mar 24, 2016 at 2:11 PM Greg Clayton  wrote:
>> > You you building with Xcode? You should be building by checking out lldb 
>> > at the top level, then typing:
>> >
>> > % xcodebuild -configuration Debug
>> >
>> >
>> > > On Mar 24, 2016, at 12:31 PM, Zachary Turner  wrote:
>> > >
>> > > Having trouble building on OSX.
>> > >
>> > > ERROR:root:Unable to find swig executable: 'module' object has no 
>> > > attribute 'OSError'
>> > >
>> > > Command /bin/sh failed with exit code 250
>> > >
>> > >
>> > >
>> > > But "which swig" finds it just fine.  It's been a long time since I've 
>> > > built on OSX so I don't know if something has changed.
>> > >
>> > > In any case, let me know if there's something I should be doing.
>> > >
>> > >
>> > > On Wed, Mar 23, 2016 at 4:12 PM Zachary Turner  
>> > > wrote:
>> > > zturner added a comment.
>> > >
>> > > It's been a while since I've used my Mac.  I'll fire it up and see if I 
>> > > can get it going, but no promises.  I'll update tomorrow
>> > >
>> > >
>> > > http://reviews.llvm.org/D18381
>> > >
>> > >
>> > >
>> >
>> 
>> ___
>> lldb-commits mailing list
>> lldb-commits@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
> 
> 
> Thanks,
> - Enrico
> 📩 egranata@.com ☎️ 27683
> 
> ___
> 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] D18459: Fix FILE * leak in Python API

[Francis Ricci via lldb-commits]

fjricci added a comment.

Because python 3 doesn't use `FILE*` as the underlying implementation anymore, 
I think the only way to make this work is to continue to use `dup()` to make 
the `FILE*`, but then to actually keep track of the ownership of the `FILE*`. 
This can't be done inside `PythonFile`, because the `PythonFile` will go out of 
scope before `SetImmediateOutputFile` is called. This leaves me thinking that 
best possibility would be to expose the `transfer_ownership` flag to the python 
API and then change the call to set this flag. However, this flag isn't 
currently exposed above the implementation level, and I'm not sure that it 
makes sense for it to be from an API point of view.

As an alternative fix, I can also change `PythonFile` to use `PyFile_AsFile()` 
on Python < 3, and the currently existing implementation on Python >= 3. 
However, this won't actually fix the `FILE*` leak on python 3.


http://reviews.llvm.org/D18459



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

Re: [Lldb-commits] [PATCH] D18459: Fix FILE * leak in Python API

[Zachary Turner via lldb-commits]

zturner added a comment.

  if (!StreamIsValid())
  {
  if (DescriptorIsValid())
  {
  const char *mode = GetStreamOpenModeFromOptions (m_options);
  if (mode)
  {
  if (!m_should_close_fd)
  {
  // We must duplicate the file descriptor if we don't own it 
because
  // when you call fdopen, the stream will own the fd
  #ifdef _WIN32
  m_descriptor = ::_dup(GetDescriptor());
  #else
  m_descriptor = dup(GetDescriptor());
  #endif
  m_should_close_fd = true;
  }
  
  do
  {
  m_stream = ::fdopen (m_descriptor, mode);
  } while (m_stream == NULL && errno == EINTR);
  
  // If we got a stream, then we own the stream and should no
  // longer own the descriptor because fclose() will close it for us
  
  if (m_stream)
  {
  m_own_stream = true;
  m_should_close_fd = false;
  }
  }
  }
  }
  return m_stream;

If this is successful, the final `if (m_stream)` check passes, and it sets 
`m_own_stream` to `true`.  This means that in the `File` destructor, it will 
call `fclose`.  It doesn't matter that nobody calls `close`, because after 
you've `fdopen`'ed something, you're not supposed to call `close`, only 
`fclose`.

Am I missing something?


http://reviews.llvm.org/D18459



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

[Lldb-commits] [PATCH] D18464: Implement `target modules dump headers`

[Adrian McCarthy via lldb-commits]

amccarth created this revision.
amccarth added a reviewer: clayborg.
amccarth added a subscriber: lldb-commits.

I set out to add functionality to dump headers from a binary, only to discover 
that the functionality already existed but wasn't (as far as I can tell) hooked 
up to the command line.  (It's accessible through the script bridge by 
enumerating modules and dumping them.)  This patch adds a command line `target 
modules dump headers` to do this interactively.

I'm not wedded to the particulars of the name, so if you think it should be 
called something else, I'm open to suggestions.

http://reviews.llvm.org/D18464

Files:
  source/Commands/CommandObjectTarget.cpp

Index: source/Commands/CommandObjectTarget.cpp
===
--- source/Commands/CommandObjectTarget.cpp
+++ source/Commands/CommandObjectTarget.cpp
@@ -1544,6 +1544,37 @@
 strm.Printf("%-*s", width, "");
 }
 
+static size_t
+DumpModuleHeaders(Stream &strm, ModuleList &module_list)
+{
+size_t num_dumped = 0;
+Mutex::Locker modules_locker(module_list.GetMutex());
+const size_t num_modules = module_list.GetSize();
+if (num_modules > 0)
+{
+strm.Printf("Dumping headers for %" PRIu64 " module(s).\n", static_cast(num_modules));
+strm.IndentMore();
+for (size_t image_idx = 0; image_idx < num_modules; ++image_idx)
+{
+Module *module = module_list.GetModulePointerAtIndexUnlocked(image_idx);
+if (module)
+{
+if (num_dumped++ > 0)
+{
+strm.EOL();
+strm.EOL();
+}
+strm.Printf("Headers for '%s':\n", module->GetSpecificationDescription().c_str());
+strm.IndentMore();
+module->Dump(&strm);
+strm.IndentLess();
+}
+}
+strm.IndentLess();
+}
+return num_dumped;
+}
+
 static void
 DumpModuleSymtab (CommandInterpreter &interpreter, Stream &strm, Module *module, SortOrder sort_order)
 {
@@ -1941,7 +1972,6 @@
ModuleList &module_list, 
bool check_global_list)
 {
-// Dump specified images (by basename or fullpath)
 FileSpec module_file_spec(module_name, false);
 ModuleSpec module_spec (module_file_spec);
 
@@ -2108,6 +2138,76 @@
 }
 };
 
+#pragma mark CommandObjectTargetModulesDumpHeaders
+
+class CommandObjectTargetModulesDumpHeaders : public CommandObjectTargetModulesModuleAutoComplete
+{
+public:
+CommandObjectTargetModulesDumpHeaders(CommandInterpreter &interpreter)
+: CommandObjectTargetModulesModuleAutoComplete(interpreter, "target modules dump headers",
+   "Dump the headers from one or more target modules.", nullptr)
+{
+}
+
+~CommandObjectTargetModulesDumpHeaders() override = default;
+
+protected:
+bool
+DoExecute(Args &command, CommandReturnObject &result) override
+{
+Target *target = m_interpreter.GetDebugger().GetSelectedTarget().get();
+if (target == nullptr)
+{
+result.AppendError("invalid target, create a debug target using the 'target create' command");
+result.SetStatus(eReturnStatusFailed);
+return false;
+}
+
+uint32_t addr_byte_size = target->GetArchitecture().GetAddressByteSize();
+result.GetOutputStream().SetAddressByteSize(addr_byte_size);
+result.GetErrorStream().SetAddressByteSize(addr_byte_size);
+
+size_t num_dumped = 0;
+if (command.GetArgumentCount() == 0)
+{
+// Dump all headers for all modules images
+num_dumped = DumpModuleHeaders(result.GetOutputStream(), target->GetImages());
+if (num_dumped == 0)
+{
+result.AppendError("the target has no associated executable images");
+result.SetStatus(eReturnStatusFailed);
+}
+}
+else
+{
+// Find the modules that match the basename or full path.
+ModuleList module_list;
+const char *arg_cstr;
+for (int arg_idx = 0; (arg_cstr = command.GetArgumentAtIndex(arg_idx)) != nullptr; ++arg_idx)
+{
+size_t num_matched = FindModulesByName(target, arg_cstr, module_list, true);
+if (num_matched == 0)
+{
+result.AppendWarningWithFormat("Unable to find an image that matches '%s'.\n", arg_cstr);
+}
+}
+// Dump all the modules we found.
+num_dumped = DumpModuleHeaders(result.GetOutputStream(), module_list);
+}
+
+if (num_dumped > 0)
+{
+result.SetStatus(eReturnStatusSuccessFinishResult);
+}
+else
+{
+result.AppendError("no matching executable images found");
+  

Re: [Lldb-commits] [PATCH] D18381: Decouple ClangASTContext from DWARF

[Zachary Turner via lldb-commits]

Figured as much.  Thanks for the tip.

Back to the issue of the test suite, I ran the test suite but I get a ton
of errors in Objective C tests even without my patch applied.  So I must
still be doing something worng.  I used the xcodebuild command line, then
ran `test/dotest.py` with no arguments.  I also tried `test/dotest.py
--executable bin/Debug/lldb packages/Python/lldbsuite/test` but that
doesn't seem to work either.  What's the proper way to run the test suite
(given that building from the IDE doesn't work for me)


On Thu, Mar 24, 2016 at 2:54 PM Enrico Granata  wrote:

> On Mar 24, 2016, at 2:53 PM, Zachary Turner  wrote:
>
> Is it one time until I reboot, or until the end of the test suite?
>
>
> The former.
>
> On Thu, Mar 24, 2016 at 2:51 PM Enrico Granata  wrote:
>
>> On Mar 24, 2016, at 2:44 PM, Zachary Turner via lldb-commits <
>> lldb-commits@lists.llvm.org> wrote:
>>
>> It's updated now.  I'm still getting errors building from inside Xcode
>> when I use the IDE, but it works from the command line.  But running the
>> test pops up hundreds of dialogs asking me to enter my password to take
>> control of another process, so I'm not sure how to disable that.
>>
>>
>> If you type your password once, then you should be able to dismiss all
>> other prompts with no detriment.
>> Essentially, the first time you try to actually use the lldb_codesign
>> certificate to take control of an inferior process, OS X asks for your
>> password for extra security
>>
>> Anyway I updated my patch if you want to give it a go.  I'm not sure why
>> I didn't get any linker errors, because I didn't update the Xcode project
>> to include ClangUtil.cpp, so I was expecting some undefined symbol errors.
>>
>> On Thu, Mar 24, 2016 at 2:34 PM Greg Clayton  wrote:
>>
>>> I usually select "desktop" as the target. Is this patch up to date? If
>>> so, I can apply and compile it and let you know what the results are.
>>>
>>> > On Mar 24, 2016, at 2:21 PM, Zachary Turner 
>>> wrote:
>>> >
>>> > Yes I was doing it from inside the IDE though.  I selected lldb-tool,
>>> 64-bit, and hit Product -> Build
>>> >
>>> > On Thu, Mar 24, 2016 at 2:11 PM Greg Clayton 
>>> wrote:
>>> > You you building with Xcode? You should be building by checking out
>>> lldb at the top level, then typing:
>>> >
>>> > % xcodebuild -configuration Debug
>>> >
>>> >
>>> > > On Mar 24, 2016, at 12:31 PM, Zachary Turner 
>>> wrote:
>>> > >
>>> > > Having trouble building on OSX.
>>> > >
>>> > > ERROR:root:Unable to find swig executable: 'module' object has no
>>> attribute 'OSError'
>>> > >
>>> > > Command /bin/sh failed with exit code 250
>>> > >
>>> > >
>>> > >
>>> > > But "which swig" finds it just fine.  It's been a long time since
>>> I've built on OSX so I don't know if something has changed.
>>> > >
>>> > > In any case, let me know if there's something I should be doing.
>>> > >
>>> > >
>>> > > On Wed, Mar 23, 2016 at 4:12 PM Zachary Turner 
>>> wrote:
>>> > > zturner added a comment.
>>> > >
>>> > > It's been a while since I've used my Mac.  I'll fire it up and see
>>> if I can get it going, but no promises.  I'll update tomorrow
>>> > >
>>> > >
>>> > > http://reviews.llvm.org/D18381
>>> > >
>>> > >
>>> > >
>>> >
>>>
>>> ___
>> lldb-commits mailing list
>> lldb-commits@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
>>
>>
>>
>> Thanks,
>> *- Enrico*
>> 📩 egranata@.com ☎️ 27683
>>
>>
>
> Thanks,
> *- Enrico*
> 📩 egranata@.com ☎️ 27683
>
>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [PATCH] D18459: Fix FILE * leak in Python API

[Francis Ricci via lldb-commits]

fjricci added a comment.

When we pass the `FILE*` to `SetImmediateOutputFile`, it then generates a new 
`File` from this `FILE*`, but doesn't take ownership, because the 
transfer_ownership flag is always false. And the `File` destructor only closes 
files if it has ownership of the `FILE*`.


http://reviews.llvm.org/D18459



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

Re: [Lldb-commits] [PATCH] D18464: Implement `target modules dump headers`

[Greg Clayton via lldb-commits]

clayborg added a comment.

What does some sample output of this look like? I can't remember what 
module->Dump(...) does.


http://reviews.llvm.org/D18464



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

Re: [Lldb-commits] [PATCH] D18459: Fix FILE * leak in Python API

[Zachary Turner via lldb-commits]

zturner added inline comments.


Comment at: scripts/Python/python-typemaps.swig:532
@@ -531,3 +524,1 @@
- file.Clear();
-}
 }

fjricci wrote:
> The problem is that here, we save the `FILE*` (`$1`) and let the `File` 
> (`file`) go out of scope. So the `File` gets destructed (but it's after 
> calling `file.Clear()`, so the close doesn't happen). But we still hold onto 
> the `FILE*`, and we pass it, as `$1`, to the API call (not seen here, but it 
> comes right after this block in the generated swig cpp code).
I think SWIG explicitly has a mechanism to handle this.  Let me find it.


http://reviews.llvm.org/D18459



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

Re: [Lldb-commits] [PATCH] D18459: Fix FILE * leak in Python API

[Zachary Turner via lldb-commits]

zturner added inline comments.


Comment at: scripts/Python/python-typemaps.swig:532
@@ -531,3 +524,1 @@
- file.Clear();
-}
 }

zturner wrote:
> fjricci wrote:
> > The problem is that here, we save the `FILE*` (`$1`) and let the `File` 
> > (`file`) go out of scope. So the `File` gets destructed (but it's after 
> > calling `file.Clear()`, so the close doesn't happen). But we still hold 
> > onto the `FILE*`, and we pass it, as `$1`, to the API call (not seen here, 
> > but it comes right after this block in the generated swig cpp code).
> I think SWIG explicitly has a mechanism to handle this.  Let me find it.
It's the `freearg` [[ http://www.swig.org/Doc1.3/Typemaps.html#Typemaps_nn33 | 
typemap ]].

Basically you can put a rule that just calls `fclose()` on the argument, and it 
will generate this code after it's called the API.

Would this work?


http://reviews.llvm.org/D18459



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

Re: [Lldb-commits] [PATCH] D18381: Decouple ClangASTContext from DWARF

[Greg Clayton via lldb-commits]

You might need to set your workspace settings for the lldb.xcworkspace as 
follows:

File -> Workspace Settings...


Derived Data: Workspace-relative Location

and use the value "build" for it

Then click the "Advanced..." button and select "Legacy".

The test suite automatically looks in the lldb root directory's build folder 
for any LLDB stuff. If you built with "xcodebuild -configuration Debug" then 
there will be files. The LLDB should be in:

$(lldb)/build/Debug/lldb
$(lldb)/build/Debug/LLDB.framework

where $(lldb) is your LLDB root folder...





> On Mar 24, 2016, at 3:19 PM, Zachary Turner  wrote:
> 
> Figured as much.  Thanks for the tip.
> 
> Back to the issue of the test suite, I ran the test suite but I get a ton of 
> errors in Objective C tests even without my patch applied.  So I must still 
> be doing something worng.  I used the xcodebuild command line, then ran 
> `test/dotest.py` with no arguments.  I also tried `test/dotest.py 
> --executable bin/Debug/lldb packages/Python/lldbsuite/test` but that doesn't 
> seem to work either.  What's the proper way to run the test suite (given that 
> building from the IDE doesn't work for me)
> 
> 
> On Thu, Mar 24, 2016 at 2:54 PM Enrico Granata  wrote:
>> On Mar 24, 2016, at 2:53 PM, Zachary Turner  wrote:
>> 
>> Is it one time until I reboot, or until the end of the test suite?
>> 
> 
> The former.
> 
>> On Thu, Mar 24, 2016 at 2:51 PM Enrico Granata  wrote:
>>> On Mar 24, 2016, at 2:44 PM, Zachary Turner via lldb-commits 
>>>  wrote:
>>> 
>>> It's updated now.  I'm still getting errors building from inside Xcode when 
>>> I use the IDE, but it works from the command line.  But running the test 
>>> pops up hundreds of dialogs asking me to enter my password to take control 
>>> of another process, so I'm not sure how to disable that.  
>>> 
>> 
>> If you type your password once, then you should be able to dismiss all other 
>> prompts with no detriment.
>> Essentially, the first time you try to actually use the lldb_codesign 
>> certificate to take control of an inferior process, OS X asks for your 
>> password for extra security
>> 
>>> Anyway I updated my patch if you want to give it a go.  I'm not sure why I 
>>> didn't get any linker errors, because I didn't update the Xcode project to 
>>> include ClangUtil.cpp, so I was expecting some undefined symbol errors.
>>> 
>>> On Thu, Mar 24, 2016 at 2:34 PM Greg Clayton  wrote:
>>> I usually select "desktop" as the target. Is this patch up to date? If so, 
>>> I can apply and compile it and let you know what the results are.
>>> 
>>> > On Mar 24, 2016, at 2:21 PM, Zachary Turner  wrote:
>>> >
>>> > Yes I was doing it from inside the IDE though.  I selected lldb-tool, 
>>> > 64-bit, and hit Product -> Build
>>> >
>>> > On Thu, Mar 24, 2016 at 2:11 PM Greg Clayton  wrote:
>>> > You you building with Xcode? You should be building by checking out lldb 
>>> > at the top level, then typing:
>>> >
>>> > % xcodebuild -configuration Debug
>>> >
>>> >
>>> > > On Mar 24, 2016, at 12:31 PM, Zachary Turner  wrote:
>>> > >
>>> > > Having trouble building on OSX.
>>> > >
>>> > > ERROR:root:Unable to find swig executable: 'module' object has no 
>>> > > attribute 'OSError'
>>> > >
>>> > > Command /bin/sh failed with exit code 250
>>> > >
>>> > >
>>> > >
>>> > > But "which swig" finds it just fine.  It's been a long time since I've 
>>> > > built on OSX so I don't know if something has changed.
>>> > >
>>> > > In any case, let me know if there's something I should be doing.
>>> > >
>>> > >
>>> > > On Wed, Mar 23, 2016 at 4:12 PM Zachary Turner  
>>> > > wrote:
>>> > > zturner added a comment.
>>> > >
>>> > > It's been a while since I've used my Mac.  I'll fire it up and see if I 
>>> > > can get it going, but no promises.  I'll update tomorrow
>>> > >
>>> > >
>>> > > http://reviews.llvm.org/D18381
>>> > >
>>> > >
>>> > >
>>> >
>>> 
>>> ___
>>> lldb-commits mailing list
>>> lldb-commits@lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
>> 
>> 
>> Thanks,
>> - Enrico
>> 📩 egranata@.com ☎️ 27683
>> 
> 
> 
> Thanks,
> - Enrico
> 📩 egranata@.com ☎️ 27683
> 

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

[Lldb-commits] [lldb] r264351 - Make File option flags consistent for Python API

[Stephane Sezer via lldb-commits]

Author: sas
Date: Thu Mar 24 17:22:20 2016
New Revision: 264351

URL: http://llvm.org/viewvc/llvm-project?rev=264351&view=rev
Log:
Make File option flags consistent for Python API

Summary:
Fixes SBCommandReturnObject::SetImmediateOutputFile() and
SBCommandReturnObject::SetImmediateOutputFile() for files opened
with "a" or "a+" by resolving inconsistencies between File and
our Python parsing of file objects.

Reviewers: granata.enrico, Eugene.Zelenko, jingham, clayborg

Subscribers: lldb-commits, sas

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

Change by Francis Ricci 

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/source/Plugins/ScriptInterpreter/Python/PythonDataObjects.cpp

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=264351&r1=264350&r2=264351&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
 Thu Mar 24 17:22:20 2016
@@ -26,7 +26,7 @@ class CommandScriptImmediateOutputTestCa
 @expectedFailureAll(oslist=["freebsd","linux"], 
bugnumber="llvm.org/pr26139")
 def test_command_script_immediate_output (self):
 """Test that LLDB correctly allows scripted commands to set an 
immediate output file."""
-self.launch(timeout=5)
+self.launch(timeout=60)
 
 script = os.path.join(os.getcwd(), 'custom_command.py')
 prompt = "(lldb)"
@@ -35,4 +35,38 @@ class CommandScriptImmediateOutputTestCa
 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')
 self.sendline('command script delete mycommand', patterns=[prompt])
+
+test_files = {os.path.join(os.getcwd(), 'read.txt'):'r',
+  os.path.join(os.getcwd(), 'write.txt')   :'w',
+  os.path.join(os.getcwd(), 'append.txt')  :'a',
+  os.path.join(os.getcwd(), 'write_plus.txt')  :'w+',
+  os.path.join(os.getcwd(), 'read_plus.txt')   :'r+',
+  os.path.join(os.getcwd(), 'append_plus.txt') :'a+'}
+
+starter_string = 'Starter Garbage\n'
+write_string   = 'writing to file with mode: '
+
+for path, mode in test_files.iteritems():
+with open(path, 'w+') as init:
+init.write(starter_string)
+
+self.sendline('command script add -f custom_command.write_file 
mywrite', patterns=[prompt])
+for path, mode in test_files.iteritems():
+command = 'mywrite ' + path + ' ' + mode
+
+self.sendline(command, patterns=[prompt])
+
+self.sendline('command script delete mywrite', patterns=[prompt])
+
 self.quit(gracefully=False)
+
+for path, mode in test_files.iteritems():
+with open(path, 'r') as result:
+if mode in ['r', 'a', 'a+']:
+self.assertEquals(result.readline(), starter_string)
+if mode in ['w', 'w+', 'r+', 'a', 'a+']:
+self.assertEquals(result.readline(), write_string + mode + 
'\n')
+
+self.assertTrue(os.path.isfile(path))
+os.remove(path)
+

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=264351&r1=264350&r2=264351&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
 Thu Mar 24 17:22:20 2016
@@ -6,3 +6,12 @@ def command_function(debugger, command,
 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(' ')
+path = args[0]
+mode = args[1]
+
+with open(path, mode) as f:
+  

Re: [Lldb-commits] [PATCH] D18228: Make File option flags consistent for Python API

[Stephane Sezer via lldb-commits]

sas closed this revision.
sas added a comment.

Committed as r264351.


http://reviews.llvm.org/D18228



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

Re: [Lldb-commits] [PATCH] D18459: Fix FILE * leak in Python API

[Francis Ricci via lldb-commits]

fjricci added inline comments.


Comment at: scripts/Python/python-typemaps.swig:532
@@ -531,3 +524,1 @@
- file.Clear();
-}
 }

The problem is that here, we save the `FILE*` (`$1`) and let the `File` 
(`file`) go out of scope. So the `File` gets destructed (but it's after calling 
`file.Clear()`, so the close doesn't happen). But we still hold onto the 
`FILE*`, and we pass it, as `$1`, to the API call (not seen here, but it comes 
right after this block in the generated swig cpp code).


http://reviews.llvm.org/D18459



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

Re: [Lldb-commits] [PATCH] D18381: Decouple ClangASTContext from DWARF

[Zachary Turner via lldb-commits]

Is there any way you could try it out for me?  It still doesn't build
successfully from the IDE with those steps.

The patch should apply cleanly at tip.  Later this week I can try to nuke
my whole lldb directory and start over with a clean repo.

On Thu, Mar 24, 2016 at 3:26 PM Greg Clayton  wrote:

> You might need to set your workspace settings for the lldb.xcworkspace as
> follows:
>
> File -> Workspace Settings...
>
>
> Derived Data: Workspace-relative Location
>
> and use the value "build" for it
>
> Then click the "Advanced..." button and select "Legacy".
>
> The test suite automatically looks in the lldb root directory's build
> folder for any LLDB stuff. If you built with "xcodebuild -configuration
> Debug" then there will be files. The LLDB should be in:
>
> $(lldb)/build/Debug/lldb
> $(lldb)/build/Debug/LLDB.framework
>
> where $(lldb) is your LLDB root folder...
>
>
>
>
>
> > On Mar 24, 2016, at 3:19 PM, Zachary Turner  wrote:
> >
> > Figured as much.  Thanks for the tip.
> >
> > Back to the issue of the test suite, I ran the test suite but I get a
> ton of errors in Objective C tests even without my patch applied.  So I
> must still be doing something worng.  I used the xcodebuild command line,
> then ran `test/dotest.py` with no arguments.  I also tried `test/dotest.py
> --executable bin/Debug/lldb packages/Python/lldbsuite/test` but that
> doesn't seem to work either.  What's the proper way to run the test suite
> (given that building from the IDE doesn't work for me)
> >
> >
> > On Thu, Mar 24, 2016 at 2:54 PM Enrico Granata 
> wrote:
> >> On Mar 24, 2016, at 2:53 PM, Zachary Turner  wrote:
> >>
> >> Is it one time until I reboot, or until the end of the test suite?
> >>
> >
> > The former.
> >
> >> On Thu, Mar 24, 2016 at 2:51 PM Enrico Granata 
> wrote:
> >>> On Mar 24, 2016, at 2:44 PM, Zachary Turner via lldb-commits <
> lldb-commits@lists.llvm.org> wrote:
> >>>
> >>> It's updated now.  I'm still getting errors building from inside Xcode
> when I use the IDE, but it works from the command line.  But running the
> test pops up hundreds of dialogs asking me to enter my password to take
> control of another process, so I'm not sure how to disable that.
> >>>
> >>
> >> If you type your password once, then you should be able to dismiss all
> other prompts with no detriment.
> >> Essentially, the first time you try to actually use the lldb_codesign
> certificate to take control of an inferior process, OS X asks for your
> password for extra security
> >>
> >>> Anyway I updated my patch if you want to give it a go.  I'm not sure
> why I didn't get any linker errors, because I didn't update the Xcode
> project to include ClangUtil.cpp, so I was expecting some undefined symbol
> errors.
> >>>
> >>> On Thu, Mar 24, 2016 at 2:34 PM Greg Clayton 
> wrote:
> >>> I usually select "desktop" as the target. Is this patch up to date? If
> so, I can apply and compile it and let you know what the results are.
> >>>
> >>> > On Mar 24, 2016, at 2:21 PM, Zachary Turner 
> wrote:
> >>> >
> >>> > Yes I was doing it from inside the IDE though.  I selected
> lldb-tool, 64-bit, and hit Product -> Build
> >>> >
> >>> > On Thu, Mar 24, 2016 at 2:11 PM Greg Clayton 
> wrote:
> >>> > You you building with Xcode? You should be building by checking out
> lldb at the top level, then typing:
> >>> >
> >>> > % xcodebuild -configuration Debug
> >>> >
> >>> >
> >>> > > On Mar 24, 2016, at 12:31 PM, Zachary Turner 
> wrote:
> >>> > >
> >>> > > Having trouble building on OSX.
> >>> > >
> >>> > > ERROR:root:Unable to find swig executable: 'module' object has no
> attribute 'OSError'
> >>> > >
> >>> > > Command /bin/sh failed with exit code 250
> >>> > >
> >>> > >
> >>> > >
> >>> > > But "which swig" finds it just fine.  It's been a long time since
> I've built on OSX so I don't know if something has changed.
> >>> > >
> >>> > > In any case, let me know if there's something I should be doing.
> >>> > >
> >>> > >
> >>> > > On Wed, Mar 23, 2016 at 4:12 PM Zachary Turner 
> wrote:
> >>> > > zturner added a comment.
> >>> > >
> >>> > > It's been a while since I've used my Mac.  I'll fire it up and see
> if I can get it going, but no promises.  I'll update tomorrow
> >>> > >
> >>> > >
> >>> > > http://reviews.llvm.org/D18381
> >>> > >
> >>> > >
> >>> > >
> >>> >
> >>>
> >>> ___
> >>> lldb-commits mailing list
> >>> lldb-commits@lists.llvm.org
> >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
> >>
> >>
> >> Thanks,
> >> - Enrico
> >> 📩 egranata@.com ☎️ 27683
> >>
> >
> >
> > Thanks,
> > - Enrico
> > 📩 egranata@.com ☎️ 27683
> >
>
>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] r264353 - Update the INFOPLIST_FILE setting in the xcode project file

[Jason Molenda via lldb-commits]

Author: jmolenda
Date: Thu Mar 24 17:27:52 2016
New Revision: 264353

URL: http://llvm.org/viewvc/llvm-project?rev=264353&view=rev
Log:
Update the INFOPLIST_FILE setting in the xcode project file
so that the lldb command line binary's version #'s are updated
correctly.
 

Modified:
lldb/trunk/lldb.xcodeproj/project.pbxproj
lldb/trunk/tools/driver/lldb-Info.plist

Modified: lldb/trunk/lldb.xcodeproj/project.pbxproj
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/lldb.xcodeproj/project.pbxproj?rev=264353&r1=264352&r2=264353&view=diff
==
--- lldb/trunk/lldb.xcodeproj/project.pbxproj (original)
+++ lldb/trunk/lldb.xcodeproj/project.pbxproj Thu Mar 24 17:27:52 2016
@@ -8159,7 +8159,7 @@
GCC_INLINES_ARE_PRIVATE_EXTERN = NO;
GCC_SYMBOLS_PRIVATE_EXTERN = NO;
HEADER_SEARCH_PATHS = "";
-   INFOPLIST_FILE = "lldb-Info.plist";
+   INFOPLIST_FILE = "tools/driver/lldb-Info.plist";
INSTALL_PATH = "$(LLDB_TOOLS_INSTALL_DIR)";
LIBRARY_SEARCH_PATHS = "$(inherited)";
"OTHER_LDFLAGS[sdk=iphoneos*]" = (
@@ -8719,7 +8719,7 @@
GCC_OPTIMIZATION_LEVEL = 0;
GCC_SYMBOLS_PRIVATE_EXTERN = NO;
HEADER_SEARCH_PATHS = "";
-   INFOPLIST_FILE = "lldb-Info.plist";
+   INFOPLIST_FILE = "tools/driver/lldb-Info.plist";
INSTALL_PATH = "$(LLDB_TOOLS_INSTALL_DIR)";
LIBRARY_SEARCH_PATHS = "$(inherited)";
OTHER_LDFLAGS = (
@@ -8747,7 +8747,7 @@
GCC_INLINES_ARE_PRIVATE_EXTERN = NO;
GCC_SYMBOLS_PRIVATE_EXTERN = NO;
HEADER_SEARCH_PATHS = "";
-   INFOPLIST_FILE = "lldb-Info.plist";
+   INFOPLIST_FILE = "tools/driver/lldb-Info.plist";
INSTALL_PATH = "$(LLDB_TOOLS_INSTALL_DIR)";
LIBRARY_SEARCH_PATHS = "$(inherited)";
OTHER_LDFLAGS = (
@@ -8894,7 +8894,7 @@
GCC_OPTIMIZATION_LEVEL = 0;
GCC_SYMBOLS_PRIVATE_EXTERN = NO;
HEADER_SEARCH_PATHS = "";
-   INFOPLIST_FILE = "lldb-Info.plist";
+   INFOPLIST_FILE = "tools/driver/lldb-Info.plist";
INSTALL_PATH = "$(LLDB_TOOLS_INSTALL_DIR)";
LIBRARY_SEARCH_PATHS = "$(inherited)";
OTHER_LDFLAGS = (

Modified: lldb/trunk/tools/driver/lldb-Info.plist
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/tools/driver/lldb-Info.plist?rev=264353&r1=264352&r2=264353&view=diff
==
--- lldb/trunk/tools/driver/lldb-Info.plist (original)
+++ lldb/trunk/tools/driver/lldb-Info.plist Thu Mar 24 17:27:52 2016
@@ -11,7 +11,7 @@
CFBundleName
lldb
CFBundleVersion
-   2
+   360.99.0
SecTaskAccess

allowed


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

Re: [Lldb-commits] [PATCH] D18464: Implement `target modules dump headers`

[Adrian McCarthy via lldb-commits]

amccarth added a comment.

I'm using it with PE files (Windows), so I see

A table of where the debug info exists
MSDOS Header
COFF Header
PECOFF header
a table of section headers (.rdata, .bss, etc.).

The section headers table is redundant with `target modules dump sections`, but 
I don't see another way to get the rest of it.  I'm particularly interested int 
he COFF and PECOFF headers.


http://reviews.llvm.org/D18464



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

Re: [Lldb-commits] [PATCH] D18464: Implement `target modules dump headers`

[Adrian McCarthy via lldb-commits]

amccarth added a comment.

Literally:

  Dumping headers for 1 module(s).
  Headers for 'd:\src\fizzbuzz\a.exe':
  Module d:\src\fizzbuzz\a.exe
  04189230:   ObjectFilePECOFF, file = 'd:\src\fizzbuzz\a.exe', arch = i386
SectID Type File Address 
File Off.  File Size  Flags  Section Name
--  ---  
-- -- -- 
  
0x0001 data [0x00401000-0x004085cc)  
0x0400 0x7600 0x4040 a.exe..rdata
0x0002 zero-fill[0x00409000-0x0040b244)  
0x 0x 0xc080 a.exe..bss
0x0003 data [0x0040c000-0x0040da8c)  
0x7a00 0x1c00 0xc040 a.exe..data
0x0004 code [0x0040e000-0x0042c7b8)  
0x9600 0x0001e800 0x6020 a.exe..text
0x0005 data [0x0042d000-0x0042d93c)  
0x00027e00 0x0a00 0x4040 a.exe..xdata
0x0006 data [0x0042e000-0x0042e887)  
0x00028800 0x0a00 0x4040 a.exe..idata
0x0007 dwarf-abbrev [0x0042f000-0x0042f6c1)  
0x00029200 0x0800 0x4240 a.exe..debug_abbrev
0x0008 dwarf-info   [0x0043-0x0043ac12)  
0x00029a00 0xae00 0x4240 a.exe..debug_info
0x0009 dwarf-line   [0x0043b000-0x0043ec3a)  
0x00034800 0x3e00 0x4240 a.exe..debug_line
0x000a dwarf-loc[0x0043f000-0x0043f08e)  
0x00038600 0x0200 0x4240 a.exe..debug_loc
0x000b dwarf-pubnames   [0x0044-0x00442ca3)  
0x00038800 0x2e00 0x4240 a.exe..debug_pubnames
0x000c dwarf-pubtypes   [0x00443000-0x00443b59)  
0x0003b600 0x0c00 0x4240 a.exe..debug_pubtypes
0x000d dwarf-ranges [0x00444000-0x00444888)  
0x0003c200 0x0a00 0x4240 a.exe..debug_ranges
0x000e dwarf-str[0x00445000-0x00450a55)  
0x0003cc00 0xbc00 0x4240 a.exe..debug_str
0x000f regular  [0x00451000-0x0045336c)  
0x00048800 0x2400 0x4240 a.exe..reloc
  MSDOS Header
e_magic= 0x5a4d
e_cblp = 0x
e_cp   = 0x
e_crlc = 0x
e_cparhdr  = 0x
e_minalloc = 0x
e_maxalloc = 0x
e_ss   = 0x
e_sp   = 0x
e_csum = 0x
e_ip   = 0x
e_cs   = 0x
e_lfarlc   = 0x0040
e_ovno = 0x
e_res[4]   = { 0x, 0x, 0x, 0x }
e_oemid= 0x
e_oeminfo  = 0x
e_res2[10] = { 0x, 0x, 0x, 0x, 0x, 0x, 0x, 
0x, 0x, 0x }
e_lfanew   = 0x0040
  COFF Header
machine = 0x014c
nsects  = 0x000f
modtime = 0x
symoff  = 0x0004ac00
nsyms   = 0x15f2
hdrsize = 0x00e0
  Optional COFF Header
magic   = 0x010b
major_linker_version= 0x00
minor_linker_version= 0x00
code_size   = 0x0001e800
data_size   = 0x0002c000
bss_size= 0x
entry   = 0x000187b3
code_offset = 0xe000
data_offset = 0x
image_base  = 0x0040
sect_alignment  = 0x1000
file_alignment  = 0x0200
major_os_system_version = 0x0006
minor_os_system_version = 0x
major_image_version = 0x
minor_image_version = 0x
major_subsystem_version = 0x0006
minor_subsystem_version = 0x
reserved1   = 0x
image_size  = 0x00053400
header_size = 0x0400
checksum= 0x
subsystem   = 0x0003
dll_flags   = 0x8140
stack_reserve_size  = 0x0010
stack_commit_size   = 0x1000
heap_reserve_size   = 0x0010
heap_commit_size= 0x1000
loader_flags= 0x
num_data_dir_entries= 0x0010
data_dirs[ 0] vmaddr = 0x, vmsize = 0x
data_dirs[ 1] vmaddr = 0x0002e000, vmsize = 0x0028
data_dirs[ 2] vmaddr = 0x, vmsize = 0x
data_dirs[ 3] vmaddr = 0x, vmsize = 0x
data_dirs[ 4] vmaddr = 0x, vmsize = 0x
data_dirs[ 5] vmaddr = 0x00051000, vmsize = 0x236c
data_dirs[ 6] vmaddr = 0x, vmsize = 0x
data_dirs[ 7] vmaddr = 0x, vmsize = 0x
data_dirs[ 8] vmaddr = 0x, vmsize = 0x
data_dirs[ 9] vmaddr = 0x, vmsize = 0x
data_dirs[10] vmaddr = 0x00

Re: [Lldb-commits] [PATCH] D18459: Fix FILE * leak in Python API

[Francis Ricci via lldb-commits]

fjricci added inline comments.


Comment at: scripts/Python/python-typemaps.swig:532
@@ -531,3 +524,1 @@
- file.Clear();
-}
 }

zturner wrote:
> zturner wrote:
> > fjricci wrote:
> > > The problem is that here, we save the `FILE*` (`$1`) and let the `File` 
> > > (`file`) go out of scope. So the `File` gets destructed (but it's after 
> > > calling `file.Clear()`, so the close doesn't happen). But we still hold 
> > > onto the `FILE*`, and we pass it, as `$1`, to the API call (not seen 
> > > here, but it comes right after this block in the generated swig cpp code).
> > I think SWIG explicitly has a mechanism to handle this.  Let me find it.
> It's the `freearg` [[ http://www.swig.org/Doc1.3/Typemaps.html#Typemaps_nn33 
> | typemap ]].
> 
> Basically you can put a rule that just calls `fclose()` on the argument, and 
> it will generate this code after it's called the API.
> 
> Would this work?
So the issue is that we don't want to `fclose()` after 
`SetImmediateOutputFile()`, we want it to `fclose()` when we're done writing to 
the `FILE*`, which happens when the `CommandReturnObject` is destructed.


http://reviews.llvm.org/D18459



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

Re: [Lldb-commits] [PATCH] D18459: Fix FILE * leak in Python API

[Zachary Turner via lldb-commits]

Could there be an overload of SBCommandReturnObject constructor that takes
an fd instead of a FILE*, and pass through to the private method which does
its own duping? Then this typemap could be changed to convert to int
instead of to FILE*

Also I'm OOO until tomorrow now, so I can't look at the code again until
then
On Thu, Mar 24, 2016 at 3:56 PM Francis Ricci  wrote:

> fjricci added inline comments.
>
> 
> Comment at: scripts/Python/python-typemaps.swig:532
> @@ -531,3 +524,1 @@
> - file.Clear();
> -}
>  }
> 
> zturner wrote:
> > zturner wrote:
> > > fjricci wrote:
> > > > The problem is that here, we save the `FILE*` (`$1`) and let the
> `File` (`file`) go out of scope. So the `File` gets destructed (but it's
> after calling `file.Clear()`, so the close doesn't happen). But we still
> hold onto the `FILE*`, and we pass it, as `$1`, to the API call (not seen
> here, but it comes right after this block in the generated swig cpp code).
> > > I think SWIG explicitly has a mechanism to handle this.  Let me find
> it.
> > It's the `freearg` [[
> http://www.swig.org/Doc1.3/Typemaps.html#Typemaps_nn33 | typemap ]].
> >
> > Basically you can put a rule that just calls `fclose()` on the argument,
> and it will generate this code after it's called the API.
> >
> > Would this work?
> So the issue is that we don't want to `fclose()` after
> `SetImmediateOutputFile()`, we want it to `fclose()` when we're done
> writing to the `FILE*`, which happens when the `CommandReturnObject` is
> destructed.
>
>
> http://reviews.llvm.org/D18459
>
>
>
>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] r264356 - Make it possible for language plugins to provide additional custom help for 'type lookup'

[Enrico Granata via lldb-commits]

Author: enrico
Date: Thu Mar 24 18:06:42 2016
New Revision: 264356

URL: http://llvm.org/viewvc/llvm-project?rev=264356&view=rev
Log:
Make it possible for language plugins to provide additional custom help for 
'type lookup'


Modified:
lldb/trunk/include/lldb/Target/Language.h
lldb/trunk/source/Commands/CommandObjectType.cpp
lldb/trunk/source/Target/Language.cpp

Modified: lldb/trunk/include/lldb/Target/Language.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Target/Language.h?rev=264356&r1=264355&r2=264356&view=diff
==
--- lldb/trunk/include/lldb/Target/Language.h (original)
+++ lldb/trunk/include/lldb/Target/Language.h Thu Mar 24 18:06:42 2016
@@ -113,6 +113,9 @@ public:
 virtual std::unique_ptr
 GetTypeScavenger ();
 
+virtual const char*
+GetLanguageSpecificTypeLookupHelp ();
+
 // if an individual data formatter can apply to several types and cross a 
language boundary
 // it makes sense for individual languages to want to customize the 
printing of values of that
 // type by appending proper prefix/suffix information in language-specific 
ways

Modified: lldb/trunk/source/Commands/CommandObjectType.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Commands/CommandObjectType.cpp?rev=264356&r1=264355&r2=264356&view=diff
==
--- lldb/trunk/source/Commands/CommandObjectType.cpp (original)
+++ lldb/trunk/source/Commands/CommandObjectType.cpp Thu Mar 24 18:06:42 2016
@@ -3265,8 +3265,8 @@ public:
 CommandObjectTypeLookup (CommandInterpreter &interpreter) :
 CommandObjectRaw (interpreter,
   "type lookup",
-  "Lookup a type by name in the select target.",
-  "type lookup ",
+  "Lookup types and declarations in the current target, 
following language-specific naming conventions.",
+  "type lookup ",
   eCommandRequiresTarget),
 m_option_group(interpreter),
 m_command_options()
@@ -3283,6 +3283,32 @@ public:
 return &m_option_group;
 }
 
+const char*
+GetHelpLong () override
+{
+if (m_cmd_help_long.empty())
+{
+StreamString stream;
+// FIXME: hardcoding languages is not good
+lldb::LanguageType languages[] = 
{eLanguageTypeObjC,eLanguageTypeC_plus_plus};
+
+for(const auto lang_type : languages)
+{
+if (auto language = Language::FindPlugin(lang_type))
+{
+if (const char* help = 
language->GetLanguageSpecificTypeLookupHelp())
+{
+stream.Printf("%s\n", help);
+}
+}
+}
+
+if (stream.GetData())
+m_cmd_help_long.assign(stream.GetString());
+}
+return this->CommandObject::GetHelpLong();
+}
+
 bool
 DoExecute (const char *raw_command_line, CommandReturnObject &result) 
override
 {

Modified: lldb/trunk/source/Target/Language.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Target/Language.cpp?rev=264356&r1=264355&r2=264356&view=diff
==
--- lldb/trunk/source/Target/Language.cpp (original)
+++ lldb/trunk/source/Target/Language.cpp Thu Mar 24 18:06:42 2016
@@ -368,6 +368,12 @@ Language::GetTypeScavenger ()
 return nullptr;
 }
 
+const char*
+Language::GetLanguageSpecificTypeLookupHelp ()
+{
+return nullptr;
+}
+
 size_t
 Language::TypeScavenger::Find (ExecutionContextScope *exe_scope,
const char *key,


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

[Lldb-commits] [lldb] r264361 - Ignore global constructor warning in clang.

[Greg Clayton via lldb-commits]

Author: gclayton
Date: Thu Mar 24 18:50:03 2016
New Revision: 264361

URL: http://llvm.org/viewvc/llvm-project?rev=264361&view=rev
Log:
Ignore global constructor warning in clang.

Modified:
lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp

Modified: 
lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp?rev=264361&r1=264360&r2=264361&view=diff
==
--- lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp 
(original)
+++ lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp 
Thu Mar 24 18:50:03 2016
@@ -39,7 +39,11 @@
 #include "llvm/Support/FileSystem.h"
 #include "llvm/Support/TargetSelect.h"
 
+#pragma clang diagnostic push
+#pragma clang diagnostic ignored "-Wglobal-constructors"
 #include "llvm/ExecutionEngine/MCJIT.h"
+#pragma clang diagnostic pop
+
 #include "llvm/IR/LLVMContext.h"
 #include "llvm/IR/Module.h"
 #include "llvm/Support/ErrorHandling.h"


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

[Lldb-commits] [lldb] r264379 - Use Clang's FixItHints to correct expressions with "trivial" mistakes (e.g. "." for "->".)

[Jim Ingham via lldb-commits]

Author: jingham
Date: Thu Mar 24 20:57:14 2016
New Revision: 264379

URL: http://llvm.org/viewvc/llvm-project?rev=264379&view=rev
Log:
Use Clang's FixItHints to correct expressions with "trivial" mistakes (e.g. "." 
for "->".)
This feature is controlled by an expression command option, a target property 
and the
SBExpressionOptions setting.  FixIt's are only applied to UserExpressions, not 
UtilityFunctions,
those you have to get right when you make them.

This is just a first stage.  At present the fixits are applied silently.  The 
next step
is to tell the user about the applied fixit.



Added:
lldb/trunk/packages/Python/lldbsuite/test/expression_command/fixits/
lldb/trunk/packages/Python/lldbsuite/test/expression_command/fixits/Makefile

lldb/trunk/packages/Python/lldbsuite/test/expression_command/fixits/TestFixIts.py
lldb/trunk/packages/Python/lldbsuite/test/expression_command/fixits/main.cpp
lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangDiagnostic.h
Modified:
lldb/trunk/include/lldb/API/SBExpressionOptions.h
lldb/trunk/include/lldb/Expression/DiagnosticManager.h
lldb/trunk/include/lldb/Expression/ExpressionParser.h
lldb/trunk/include/lldb/Target/Target.h
lldb/trunk/lldb.xcodeproj/project.pbxproj
lldb/trunk/scripts/interface/SBExpressionOptions.i
lldb/trunk/source/API/SBExpressionOptions.cpp
lldb/trunk/source/Commands/CommandObjectExpression.cpp
lldb/trunk/source/Commands/CommandObjectExpression.h
lldb/trunk/source/Expression/DiagnosticManager.cpp
lldb/trunk/source/Expression/UserExpression.cpp
lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.h
lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangUserExpression.cpp
lldb/trunk/source/Target/Target.cpp

Modified: lldb/trunk/include/lldb/API/SBExpressionOptions.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/API/SBExpressionOptions.h?rev=264379&r1=264378&r2=264379&view=diff
==
--- lldb/trunk/include/lldb/API/SBExpressionOptions.h (original)
+++ lldb/trunk/include/lldb/API/SBExpressionOptions.h Thu Mar 24 20:57:14 2016
@@ -110,6 +110,12 @@ public:
 
 void
 SetPrefix (const char *prefix);
+
+void
+SetAutoApplyFixIts(bool b = true);
+
+bool
+GetAutoApplyFixIts();
 
 protected:
 

Modified: lldb/trunk/include/lldb/Expression/DiagnosticManager.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Expression/DiagnosticManager.h?rev=264379&r1=264378&r2=264379&view=diff
==
--- lldb/trunk/include/lldb/Expression/DiagnosticManager.h (original)
+++ lldb/trunk/include/lldb/Expression/DiagnosticManager.h Thu Mar 24 20:57:14 
2016
@@ -38,15 +38,82 @@ enum DiagnosticSeverity
 
 const uint32_t LLDB_INVALID_COMPILER_ID = UINT32_MAX;
 
-struct Diagnostic
+class Diagnostic
 {
-std::string message;
-uint32_t compiler_id; // Compiler-specific diagnostic ID
-DiagnosticSeverity severity;
-DiagnosticOrigin origin;
+friend class DiagnosticManager;
+
+public:
+DiagnosticOrigin getKind() const { return m_origin; }
+
+static bool classof(const Diagnostic *diag)
+{
+DiagnosticOrigin kind =  diag->getKind();
+switch (kind)
+{
+case eDiagnosticOriginUnknown:
+case eDiagnosticOriginLLDB:
+case eDiagnosticOriginGo:
+case eDiagnosticOriginLLVM:
+return true;
+case eDiagnosticOriginClang:
+case eDiagnosticOriginSwift:
+return false;
+}
+}
+
+Diagnostic(const char *message, DiagnosticSeverity severity, 
DiagnosticOrigin origin, uint32_t compiler_id) :
+m_message(message),
+m_severity(severity),
+m_origin(origin),
+m_compiler_id(compiler_id)
+{
+}
+
+Diagnostic(const Diagnostic &rhs) :
+m_message(rhs.m_message),
+m_severity(rhs.m_severity),
+m_origin(rhs.m_origin),
+m_compiler_id(rhs.m_compiler_id)
+{
+}
+
+virtual ~Diagnostic() = default;
+
+virtual bool HasFixIts () const { return false; }
+
+DiagnosticSeverity
+GetSeverity() const
+{
+return m_severity;
+}
+
+uint32_t
+GetCompilerID() const
+{
+return m_compiler_id;
+}
+
+const char *
+GetMessage() const
+{
+return m_message.c_str();
+}
+
+void AppendMessage(const char *message, bool precede_with_newline = true)
+{
+if (precede_with_newline)
+m_message.push_back('\n');
+m_message.append(message);
+}
+
+protected:
+std::string m_message;
+DiagnosticSeverity m_severity;
+DiagnosticOrigin m_origin;
+uint32_t 

[Lldb-commits] [lldb] r264380 - Add the same host logging that I added to PlatformRemoteiOS a few

[Jason Molenda via lldb-commits]

Author: jmolenda
Date: Thu Mar 24 21:17:27 2016
New Revision: 264380

URL: http://llvm.org/viewvc/llvm-project?rev=264380&view=rev
Log:
Add the same host logging that I added to PlatformRemoteiOS a few
months back to PlatformRemoteAppleTV and PlatformRemoteAppleWatch
to help understand what's happening when lldb can't find binaries
that it should be finding.


Modified:
lldb/trunk/source/Plugins/Platform/MacOSX/PlatformRemoteAppleTV.cpp
lldb/trunk/source/Plugins/Platform/MacOSX/PlatformRemoteAppleWatch.cpp

Modified: lldb/trunk/source/Plugins/Platform/MacOSX/PlatformRemoteAppleTV.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/Platform/MacOSX/PlatformRemoteAppleTV.cpp?rev=264380&r1=264379&r2=264380&view=diff
==
--- lldb/trunk/source/Plugins/Platform/MacOSX/PlatformRemoteAppleTV.cpp 
(original)
+++ lldb/trunk/source/Plugins/Platform/MacOSX/PlatformRemoteAppleTV.cpp Thu Mar 
24 21:17:27 2016
@@ -314,9 +314,14 @@ PlatformRemoteAppleTV::GetContainedFiles
 bool
 PlatformRemoteAppleTV::UpdateSDKDirectoryInfosIfNeeded()
 {
+Log *log = lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_HOST);
 if (m_sdk_directory_infos.empty())
 {
 const char *device_support_dir = GetDeviceSupportDirectory();
+if (log)
+{
+log->Printf 
("PlatformRemoteAppleTV::UpdateSDKDirectoryInfosIfNeeded Got DeviceSupport 
directory %s", device_support_dir);
+}
 if (device_support_dir)
 {
 const bool find_directories = true;
@@ -341,12 +346,20 @@ PlatformRemoteAppleTV::UpdateSDKDirector
 if (sdk_symbols_symlink_fspec.Exists())
 {
 m_sdk_directory_infos.push_back(sdk_directory_info);
+if (log)
+{
+log->Printf 
("PlatformRemoteAppleTV::UpdateSDKDirectoryInfosIfNeeded added builtin SDK 
directory %s", sdk_symbols_symlink_fspec.GetPath().c_str());
+}
 }
 else
 {
 
sdk_symbols_symlink_fspec.GetFilename().SetCString("Symbols");
 if (sdk_symbols_symlink_fspec.Exists())
 m_sdk_directory_infos.push_back(sdk_directory_info);
+if (log)
+{
+log->Printf 
("PlatformRemoteAppleTV::UpdateSDKDirectoryInfosIfNeeded added builtin SDK 
directory %s", sdk_symbols_symlink_fspec.GetPath().c_str());
+}
 }
 }
 
@@ -374,6 +387,10 @@ PlatformRemoteAppleTV::UpdateSDKDirector
 }
 if (local_sdk_cache.Exists())
 {
+if (log)
+{
+log->Printf 
("PlatformRemoteAppleTV::UpdateSDKDirectoryInfosIfNeeded searching %s for 
additional SDKs", local_sdk_cache.GetPath().c_str());
+}
 char path[PATH_MAX];
 if (local_sdk_cache.GetPath(path, sizeof(path)))
 {
@@ -388,6 +405,10 @@ PlatformRemoteAppleTV::UpdateSDKDirector
 for (uint32_t i=num_installed; iPrintf 
("PlatformRemoteAppleTV::UpdateSDKDirectoryInfosIfNeeded user SDK directory 
%s", m_sdk_directory_infos[i].directory.GetPath().c_str());
+}
 }
 }
 }
@@ -572,6 +593,7 @@ uint32_t
 PlatformRemoteAppleTV::FindFileInAllSDKs (const char *platform_file_path,
   FileSpecList &file_list)
 {
+Log *log = lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_HOST | 
LIBLLDB_LOG_VERBOSE);
 if (platform_file_path && platform_file_path[0] && 
UpdateSDKDirectoryInfosIfNeeded())
 {
 const uint32_t num_sdk_infos = m_sdk_directory_infos.size();
@@ -579,6 +601,10 @@ PlatformRemoteAppleTV::FindFileInAllSDKs
 // First try for an exact match of major, minor and update
 for (uint32_t sdk_idx=0; sdk_idxPrintf ("Searching for %s in sdk path %s", 
platform_file_path, m_sdk_directory_infos[sdk_idx].directory.GetPath().c_str());
+}
 if (GetFileInSDK (platform_file_path,
   sdk_idx,
   local_file))
@@ -618,6 +644,7 @@ PlatformRemoteAppleTV::GetFileInSDKRoot
  bool symbols_dirs_only,
  lldb_private::FileSpec &local_file)
 {
+Log *log = lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_HOST);
 if (sdkroot_path && sdkroot_path[0] && platform_file_path && 
platform_file_path[0])
 {
 char resolved_path[PATH_MAX];
@@ -632,7 +659,13 @@ PlatformRemoteAppleTV::GetFileInSDKRoot
 
 local_file.SetFile(resolved_path, true);
 if (local_file.Exists())
+{
+if (log)
+{
+

Re: [Lldb-commits] [lldb] r264379 - Use Clang's FixItHints to correct expressions with "trivial" mistakes (e.g. "." for "->".)

[Zachary Turner via lldb-commits]

This seems like an odd thing to do by default. Is there going to be a
setting to turn this off? Seems to me like off should be default

An enumerated setting would be even nicer, where one option is "report"
that just doesn't apply any FixIts, but prints a message saying "did you
mean Foo->bar()?"
On Thu, Mar 24, 2016 at 7:02 PM Jim Ingham via lldb-commits <
lldb-commits@lists.llvm.org> wrote:

> Author: jingham
> Date: Thu Mar 24 20:57:14 2016
> New Revision: 264379
>
> URL: http://llvm.org/viewvc/llvm-project?rev=264379&view=rev
> Log:
> Use Clang's FixItHints to correct expressions with "trivial" mistakes
> (e.g. "." for "->".)
> This feature is controlled by an expression command option, a target
> property and the
> SBExpressionOptions setting.  FixIt's are only applied to UserExpressions,
> not UtilityFunctions,
> those you have to get right when you make them.
>
> This is just a first stage.  At present the fixits are applied silently.
> The next step
> is to tell the user about the applied fixit.
>
> 
>
> Added:
> lldb/trunk/packages/Python/lldbsuite/test/expression_command/fixits/
>
> lldb/trunk/packages/Python/lldbsuite/test/expression_command/fixits/Makefile
>
> lldb/trunk/packages/Python/lldbsuite/test/expression_command/fixits/TestFixIts.py
>
> lldb/trunk/packages/Python/lldbsuite/test/expression_command/fixits/main.cpp
> lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangDiagnostic.h
> Modified:
> lldb/trunk/include/lldb/API/SBExpressionOptions.h
> lldb/trunk/include/lldb/Expression/DiagnosticManager.h
> lldb/trunk/include/lldb/Expression/ExpressionParser.h
> lldb/trunk/include/lldb/Target/Target.h
> lldb/trunk/lldb.xcodeproj/project.pbxproj
> lldb/trunk/scripts/interface/SBExpressionOptions.i
> lldb/trunk/source/API/SBExpressionOptions.cpp
> lldb/trunk/source/Commands/CommandObjectExpression.cpp
> lldb/trunk/source/Commands/CommandObjectExpression.h
> lldb/trunk/source/Expression/DiagnosticManager.cpp
> lldb/trunk/source/Expression/UserExpression.cpp
>
> lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
>
> lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.h
>
> lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangUserExpression.cpp
> lldb/trunk/source/Target/Target.cpp
>
> Modified: lldb/trunk/include/lldb/API/SBExpressionOptions.h
> URL:
> http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/API/SBExpressionOptions.h?rev=264379&r1=264378&r2=264379&view=diff
>
> ==
> --- lldb/trunk/include/lldb/API/SBExpressionOptions.h (original)
> +++ lldb/trunk/include/lldb/API/SBExpressionOptions.h Thu Mar 24 20:57:14
> 2016
> @@ -110,6 +110,12 @@ public:
>
>  void
>  SetPrefix (const char *prefix);
> +
> +void
> +SetAutoApplyFixIts(bool b = true);
> +
> +bool
> +GetAutoApplyFixIts();
>
>  protected:
>
>
> Modified: lldb/trunk/include/lldb/Expression/DiagnosticManager.h
> URL:
> http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Expression/DiagnosticManager.h?rev=264379&r1=264378&r2=264379&view=diff
>
> ==
> --- lldb/trunk/include/lldb/Expression/DiagnosticManager.h (original)
> +++ lldb/trunk/include/lldb/Expression/DiagnosticManager.h Thu Mar 24
> 20:57:14 2016
> @@ -38,15 +38,82 @@ enum DiagnosticSeverity
>
>  const uint32_t LLDB_INVALID_COMPILER_ID = UINT32_MAX;
>
> -struct Diagnostic
> +class Diagnostic
>  {
> -std::string message;
> -uint32_t compiler_id; // Compiler-specific diagnostic ID
> -DiagnosticSeverity severity;
> -DiagnosticOrigin origin;
> +friend class DiagnosticManager;
> +
> +public:
> +DiagnosticOrigin getKind() const { return m_origin; }
> +
> +static bool classof(const Diagnostic *diag)
> +{
> +DiagnosticOrigin kind =  diag->getKind();
> +switch (kind)
> +{
> +case eDiagnosticOriginUnknown:
> +case eDiagnosticOriginLLDB:
> +case eDiagnosticOriginGo:
> +case eDiagnosticOriginLLVM:
> +return true;
> +case eDiagnosticOriginClang:
> +case eDiagnosticOriginSwift:
> +return false;
> +}
> +}
> +
> +Diagnostic(const char *message, DiagnosticSeverity severity,
> DiagnosticOrigin origin, uint32_t compiler_id) :
> +m_message(message),
> +m_severity(severity),
> +m_origin(origin),
> +m_compiler_id(compiler_id)
> +{
> +}
> +
> +Diagnostic(const Diagnostic &rhs) :
> +m_message(rhs.m_message),
> +m_severity(rhs.m_severity),
> +m_origin(rhs.m_origin),
> +m_compiler_id(rhs.m_compiler_id)
> +{
> +}
> +
> +virtual ~Diagnostic() = default;
> +
> +virtual bool HasFixIts () const { return false; }
> +
> +DiagnosticSeverity
> +G

Re: [Lldb-commits] [lldb] r264379 - Use Clang's FixItHints to correct expressions with "trivial" mistakes (e.g. "." for "->".)

[Jason Molenda via lldb-commits]

The specific example Jim gave (./->) is a very common complaint of people 
coming from gdb.  

gdb's hand-rolled parser would realize that when you -> on an object, that 
doesn't make sense and silently correct it to . for you.  In practice, when 
you're examining local variables, you often don't remember whether something is 
an object or a pointer to an object - especially when you are dereferencing 
down a few levels (e.g. "p myvar->subelem.valcontainer->value").  

Because lldb uses clang, we have to follow the rules of the language (for the 
most part) - this is likely the only way we could accomplish something similar 
in lldb.


> On Mar 24, 2016, at 7:23 PM, Zachary Turner via lldb-commits 
>  wrote:
> 
> This seems like an odd thing to do by default. Is there going to be a setting 
> to turn this off? Seems to me like off should be default 
> 
> An enumerated setting would be even nicer, where one option is "report" that 
> just doesn't apply any FixIts, but prints a message saying "did you mean 
> Foo->bar()?"
> On Thu, Mar 24, 2016 at 7:02 PM Jim Ingham via lldb-commits 
>  wrote:
> Author: jingham
> Date: Thu Mar 24 20:57:14 2016
> New Revision: 264379
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=264379&view=rev
> Log:
> Use Clang's FixItHints to correct expressions with "trivial" mistakes (e.g. 
> "." for "->".)
> This feature is controlled by an expression command option, a target property 
> and the
> SBExpressionOptions setting.  FixIt's are only applied to UserExpressions, 
> not UtilityFunctions,
> those you have to get right when you make them.
> 
> This is just a first stage.  At present the fixits are applied silently.  The 
> next step
> is to tell the user about the applied fixit.
> 
> 
> 
> Added:
> lldb/trunk/packages/Python/lldbsuite/test/expression_command/fixits/
> 
> lldb/trunk/packages/Python/lldbsuite/test/expression_command/fixits/Makefile
> 
> lldb/trunk/packages/Python/lldbsuite/test/expression_command/fixits/TestFixIts.py
> 
> lldb/trunk/packages/Python/lldbsuite/test/expression_command/fixits/main.cpp
> lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangDiagnostic.h
> Modified:
> lldb/trunk/include/lldb/API/SBExpressionOptions.h
> lldb/trunk/include/lldb/Expression/DiagnosticManager.h
> lldb/trunk/include/lldb/Expression/ExpressionParser.h
> lldb/trunk/include/lldb/Target/Target.h
> lldb/trunk/lldb.xcodeproj/project.pbxproj
> lldb/trunk/scripts/interface/SBExpressionOptions.i
> lldb/trunk/source/API/SBExpressionOptions.cpp
> lldb/trunk/source/Commands/CommandObjectExpression.cpp
> lldb/trunk/source/Commands/CommandObjectExpression.h
> lldb/trunk/source/Expression/DiagnosticManager.cpp
> lldb/trunk/source/Expression/UserExpression.cpp
> lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
> lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.h
> lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangUserExpression.cpp
> lldb/trunk/source/Target/Target.cpp
> 
> Modified: lldb/trunk/include/lldb/API/SBExpressionOptions.h
> URL: 
> http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/API/SBExpressionOptions.h?rev=264379&r1=264378&r2=264379&view=diff
> ==
> --- lldb/trunk/include/lldb/API/SBExpressionOptions.h (original)
> +++ lldb/trunk/include/lldb/API/SBExpressionOptions.h Thu Mar 24 20:57:14 2016
> @@ -110,6 +110,12 @@ public:
> 
>  void
>  SetPrefix (const char *prefix);
> +
> +void
> +SetAutoApplyFixIts(bool b = true);
> +
> +bool
> +GetAutoApplyFixIts();
> 
>  protected:
> 
> 
> Modified: lldb/trunk/include/lldb/Expression/DiagnosticManager.h
> URL: 
> http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Expression/DiagnosticManager.h?rev=264379&r1=264378&r2=264379&view=diff
> ==
> --- lldb/trunk/include/lldb/Expression/DiagnosticManager.h (original)
> +++ lldb/trunk/include/lldb/Expression/DiagnosticManager.h Thu Mar 24 
> 20:57:14 2016
> @@ -38,15 +38,82 @@ enum DiagnosticSeverity
> 
>  const uint32_t LLDB_INVALID_COMPILER_ID = UINT32_MAX;
> 
> -struct Diagnostic
> +class Diagnostic
>  {
> -std::string message;
> -uint32_t compiler_id; // Compiler-specific diagnostic ID
> -DiagnosticSeverity severity;
> -DiagnosticOrigin origin;
> +friend class DiagnosticManager;
> +
> +public:
> +DiagnosticOrigin getKind() const { return m_origin; }
> +
> +static bool classof(const Diagnostic *diag)
> +{
> +DiagnosticOrigin kind =  diag->getKind();
> +switch (kind)
> +{
> +case eDiagnosticOriginUnknown:
> +case eDiagnosticOriginLLDB:
> +case eDiagnosticOriginGo:
> +case eDiagnosticOriginLLVM:
> +return true;
> +case eDiagnosticOriginClang:
> +  

Re: [Lldb-commits] [lldb] r264379 - Use Clang's FixItHints to correct expressions with "trivial" mistakes (e.g. "." for "->".)

[Zachary Turner via lldb-commits]

I can see how it would be useful, but i do think it should be possible to
disable and/or warn about
On Thu, Mar 24, 2016 at 7:40 PM Jason Molenda  wrote:

> The specific example Jim gave (./->) is a very common complaint of people
> coming from gdb.
>
> gdb's hand-rolled parser would realize that when you -> on an object, that
> doesn't make sense and silently correct it to . for you.  In practice, when
> you're examining local variables, you often don't remember whether
> something is an object or a pointer to an object - especially when you are
> dereferencing down a few levels (e.g. "p
> myvar->subelem.valcontainer->value").
>
> Because lldb uses clang, we have to follow the rules of the language (for
> the most part) - this is likely the only way we could accomplish something
> similar in lldb.
>
>
> > On Mar 24, 2016, at 7:23 PM, Zachary Turner via lldb-commits <
> lldb-commits@lists.llvm.org> wrote:
> >
> > This seems like an odd thing to do by default. Is there going to be a
> setting to turn this off? Seems to me like off should be default
> >
> > An enumerated setting would be even nicer, where one option is "report"
> that just doesn't apply any FixIts, but prints a message saying "did you
> mean Foo->bar()?"
> > On Thu, Mar 24, 2016 at 7:02 PM Jim Ingham via lldb-commits <
> lldb-commits@lists.llvm.org> wrote:
> > Author: jingham
> > Date: Thu Mar 24 20:57:14 2016
> > New Revision: 264379
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=264379&view=rev
> > Log:
> > Use Clang's FixItHints to correct expressions with "trivial" mistakes
> (e.g. "." for "->".)
> > This feature is controlled by an expression command option, a target
> property and the
> > SBExpressionOptions setting.  FixIt's are only applied to
> UserExpressions, not UtilityFunctions,
> > those you have to get right when you make them.
> >
> > This is just a first stage.  At present the fixits are applied
> silently.  The next step
> > is to tell the user about the applied fixit.
> >
> > 
> >
> > Added:
> > lldb/trunk/packages/Python/lldbsuite/test/expression_command/fixits/
> >
>  lldb/trunk/packages/Python/lldbsuite/test/expression_command/fixits/Makefile
> >
>  
> lldb/trunk/packages/Python/lldbsuite/test/expression_command/fixits/TestFixIts.py
> >
>  lldb/trunk/packages/Python/lldbsuite/test/expression_command/fixits/main.cpp
> > lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangDiagnostic.h
> > Modified:
> > lldb/trunk/include/lldb/API/SBExpressionOptions.h
> > lldb/trunk/include/lldb/Expression/DiagnosticManager.h
> > lldb/trunk/include/lldb/Expression/ExpressionParser.h
> > lldb/trunk/include/lldb/Target/Target.h
> > lldb/trunk/lldb.xcodeproj/project.pbxproj
> > lldb/trunk/scripts/interface/SBExpressionOptions.i
> > lldb/trunk/source/API/SBExpressionOptions.cpp
> > lldb/trunk/source/Commands/CommandObjectExpression.cpp
> > lldb/trunk/source/Commands/CommandObjectExpression.h
> > lldb/trunk/source/Expression/DiagnosticManager.cpp
> > lldb/trunk/source/Expression/UserExpression.cpp
> >
>  lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
> >
>  lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.h
> >
>  lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangUserExpression.cpp
> > lldb/trunk/source/Target/Target.cpp
> >
> > Modified: lldb/trunk/include/lldb/API/SBExpressionOptions.h
> > URL:
> http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/API/SBExpressionOptions.h?rev=264379&r1=264378&r2=264379&view=diff
> >
> ==
> > --- lldb/trunk/include/lldb/API/SBExpressionOptions.h (original)
> > +++ lldb/trunk/include/lldb/API/SBExpressionOptions.h Thu Mar 24
> 20:57:14 2016
> > @@ -110,6 +110,12 @@ public:
> >
> >  void
> >  SetPrefix (const char *prefix);
> > +
> > +void
> > +SetAutoApplyFixIts(bool b = true);
> > +
> > +bool
> > +GetAutoApplyFixIts();
> >
> >  protected:
> >
> >
> > Modified: lldb/trunk/include/lldb/Expression/DiagnosticManager.h
> > URL:
> http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Expression/DiagnosticManager.h?rev=264379&r1=264378&r2=264379&view=diff
> >
> ==
> > --- lldb/trunk/include/lldb/Expression/DiagnosticManager.h (original)
> > +++ lldb/trunk/include/lldb/Expression/DiagnosticManager.h Thu Mar 24
> 20:57:14 2016
> > @@ -38,15 +38,82 @@ enum DiagnosticSeverity
> >
> >  const uint32_t LLDB_INVALID_COMPILER_ID = UINT32_MAX;
> >
> > -struct Diagnostic
> > +class Diagnostic
> >  {
> > -std::string message;
> > -uint32_t compiler_id; // Compiler-specific diagnostic ID
> > -DiagnosticSeverity severity;
> > -DiagnosticOrigin origin;
> > +friend class DiagnosticManager;
> > +
> > +public:
> > +DiagnosticOrigin getKind() const { return m_origin; }
> > +
> > +static bool classof(const Di