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

[Francis Ricci via lldb-commits]

fjricci added a comment.

Would we want this overloaded method taking an int (fd) instead of a FILE* to 
be present in the API? Or hidden somehow? I'm new to swig, but it looks like 
python-extensions.swig includes some private extensions to the 
CommandReturnObject class already.

Overloading with an fd argument seems quite a bit more complex than doing what 
we do now but setting transfer_ownership in the underlying 
`CommandReturnObject::SetImmediateOutputFile()` call to true (which could 
probably be done either with a new swig extension or by changing the api). Do 
you think it's worth the added complexity?


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]

As long as it only changes the private API and not the public it's probably
fine, if you think that will work feel free to give it a try and upload a
new patch
On Fri, Mar 25, 2016 at 9:12 AM Francis Ricci  wrote:

> fjricci added a comment.
>
> Would we want this overloaded method taking an int (fd) instead of a FILE*
> to be present in the API? Or hidden somehow? I'm new to swig, but it looks
> like python-extensions.swig includes some private extensions to the
> CommandReturnObject class already.
>
> Overloading with an fd argument seems quite a bit more complex than doing
> what we do now but setting transfer_ownership in the underlying
> `CommandReturnObject::SetImmediateOutputFile()` call to true (which could
> probably be done either with a new swig extension or by changing the api).
> Do you think it's worth the added complexity?
>
>
> 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

[Francis Ricci via lldb-commits]

fjricci added a comment.

It appears that `%extend` directives only have access to public class members. 
So my idea won't work. I'll try to overload with a fd call, presumably that 
call can be exposed in the API? Or is it better if it isn't?

The difficulty with overloading is that, for overloaded functions in swig, it 
looks like pointer arguments take precedence over integer arguments. But there 
must be a way to specify.


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

[Greg Clayton via lldb-commits]

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

Seems like we need to just add the following to the API:

  void
  SetImmediateOutputFile (FILE *fh, bool transfer_ownership);
  
  void
  SetImmediateErrorFile (FILE *fh, bool transfer_ownership);

This should solve our problems right? Note you must add these APIs, you can't 
remove or change existing ones since there are programs out there that are 
linking against the old API.


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]

Will do. 
> On Mar 24, 2016, at 3:30 PM, Zachary Turner  wrote:
> 
> 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 
> >>>  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.

I think that would be sufficient to solve the problem.

I could use a `%rename` to rename the `SetImmediateOutputFile (FILE *fh)` call 
to a private function in `%extend`, which will then call 
`SetImmediateOutputFile (FILE *fh, transfer_ownership=true)` instead.

Does that seem reasonable? I don't see any `%rename` calls in the existing lldb 
source, which is my primary hesitation.


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

[Francis Ricci via lldb-commits]

fjricci added a comment.

Actually, I think this may open a new can of worms. Adding that flag to the API 
doesn't necessarily achieve what we want. The current bug is that we take a 
Python file (owned by the Python caller), and we know that the Python caller 
does not want to transfer ownership of the file. So inside of the swig logic, 
we make a copy of the file, which is owned by lldb (although really owned by 
nobody, since lldb doesn't take ownership of it).

This means that the problem is that we take an argument and change its owner, 
which then causes us to want different behavior from the API function we're 
calling. This is why the original swig worked, it didn't do anything to change 
the owner of the file, so it was consistent on both sides of the swig interface.

The only caller that would actually want to tell lldb to take ownership is the 
swig wrapper, not the Python itself. (What would it mean if the python caller 
decided to set that flag to true? Presumably we'd then have to take ownership 
of the python file object as well, which I don't think is something we want, 
and I don't think it would even be possible, given python garbage collection.)


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] [lldb] r264379 - Use Clang's FixItHints to correct expressions with "trivial" mistakes (e.g. "." for "->".)

[Jim Ingham via lldb-commits]

Quoting from the original submission notes below:

> This feature is controlled by an expression command option, a target property 
> and the
> > SBExpressionOptions setting.

To be more explicit, if you don't want this behavior, put:

settings set target.auto-apply-fixits no

in your .lldbinit, or replace your print alias with  "expr -X 0 --".  The test 
suite test I added shows how to do this from the Python side. 

And:

>  At present the fixits are applied silently.  The next step
> > is to tell the user about the applied fixit.

Once I figure out how to tell the user about the applied fixit, I'll add an 
option to just tell about it (and put the fixed expression in the history 
buffer.)  But to do that I have to separate the user's expression out of all 
the goo we wrap it in, which isn't something we've done before.

Jim


> On Mar 24, 2016, at 7:48 PM, Zachary Turner  wrote:
> 
> 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 
> >  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/D

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

[Greg Clayton via lldb-commits]

clayborg added a comment.

We don't necessarily need to expose this new API to swig. We get to pick and 
choose what we expose to Python in the SBCommandReturnObject.i file. So leave 
the .i file as is and use %rename to specify "transfer_ownership = true". Will 
that 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] D18459: Fix FILE * leak in Python API

[Francis Ricci via lldb-commits]

fjricci updated this revision to Diff 51678.
fjricci added a comment.

Extend SBCommandReturnObject API to allow for taking file ownership


http://reviews.llvm.org/D18459

Files:
  include/lldb/API/SBCommandReturnObject.h
  scripts/interface/SBCommandReturnObject.i
  source/API/SBCommandReturnObject.cpp

Index: source/API/SBCommandReturnObject.cpp
===
--- source/API/SBCommandReturnObject.cpp
+++ source/API/SBCommandReturnObject.cpp
@@ -270,6 +270,20 @@
 }
 
 void
+SBCommandReturnObject::SetImmediateOutputFileWithOwnership(FILE *fh)
+{
+if (m_opaque_ap)
+m_opaque_ap->SetImmediateOutputFile(fh, true);
+}
+
+void
+SBCommandReturnObject::SetImmediateErrorFileWithOwnership(FILE *fh)
+{
+if (m_opaque_ap)
+m_opaque_ap->SetImmediateErrorFile(fh, true);
+}
+
+void
 SBCommandReturnObject::PutCString(const char* string, int len)
 {
 if (m_opaque_ap)
Index: scripts/interface/SBCommandReturnObject.i
===
--- scripts/interface/SBCommandReturnObject.i
+++ scripts/interface/SBCommandReturnObject.i
@@ -16,6 +16,7 @@
 
 See SBCommandInterpreter for example usage of SBCommandReturnObject."
 ) SBCommandReturnObject;
+
 class SBCommandReturnObject
 {
 public:
@@ -84,11 +85,14 @@
 bool
 GetDescription (lldb::SBStream &description);
 
+%rename(SetImmediateOutputFile) SetImmediateOutputFileWithOwnership;
+%rename(SetImmediateErrorFile) SetImmediateErrorFileWithOwnership;
+
 void
-SetImmediateOutputFile (FILE *fh);
-
+SetImmediateOutputFileWithOwnership (FILE *fh);
+
 void
-SetImmediateErrorFile (FILE *fh);
+SetImmediateErrorFileWithOwnership (FILE *fh);
 
void
PutCString(const char* string, int len);
Index: include/lldb/API/SBCommandReturnObject.h
===
--- include/lldb/API/SBCommandReturnObject.h
+++ include/lldb/API/SBCommandReturnObject.h
@@ -91,6 +91,12 @@
 SetImmediateErrorFile (FILE *fh);
 
 void
+SetImmediateOutputFileWithOwnership(FILE* file);
+
+void
+SetImmediateErrorFileWithOwnership(FILE* file);
+
+void
 PutCString(const char* string, int len = -1);
 
 size_t


Index: source/API/SBCommandReturnObject.cpp
===
--- source/API/SBCommandReturnObject.cpp
+++ source/API/SBCommandReturnObject.cpp
@@ -270,6 +270,20 @@
 }
 
 void
+SBCommandReturnObject::SetImmediateOutputFileWithOwnership(FILE *fh)
+{
+if (m_opaque_ap)
+m_opaque_ap->SetImmediateOutputFile(fh, true);
+}
+
+void
+SBCommandReturnObject::SetImmediateErrorFileWithOwnership(FILE *fh)
+{
+if (m_opaque_ap)
+m_opaque_ap->SetImmediateErrorFile(fh, true);
+}
+
+void
 SBCommandReturnObject::PutCString(const char* string, int len)
 {
 if (m_opaque_ap)
Index: scripts/interface/SBCommandReturnObject.i
===
--- scripts/interface/SBCommandReturnObject.i
+++ scripts/interface/SBCommandReturnObject.i
@@ -16,6 +16,7 @@
 
 See SBCommandInterpreter for example usage of SBCommandReturnObject."
 ) SBCommandReturnObject;
+
 class SBCommandReturnObject
 {
 public:
@@ -84,11 +85,14 @@
 bool
 GetDescription (lldb::SBStream &description);
 
+%rename(SetImmediateOutputFile) SetImmediateOutputFileWithOwnership;
+%rename(SetImmediateErrorFile) SetImmediateErrorFileWithOwnership;
+
 void
-SetImmediateOutputFile (FILE *fh);
-
+SetImmediateOutputFileWithOwnership (FILE *fh);
+
 void
-SetImmediateErrorFile (FILE *fh);
+SetImmediateErrorFileWithOwnership (FILE *fh);
 
 	void
 	PutCString(const char* string, int len);
Index: include/lldb/API/SBCommandReturnObject.h
===
--- include/lldb/API/SBCommandReturnObject.h
+++ include/lldb/API/SBCommandReturnObject.h
@@ -91,6 +91,12 @@
 SetImmediateErrorFile (FILE *fh);
 
 void
+SetImmediateOutputFileWithOwnership(FILE* file);
+
+void
+SetImmediateErrorFileWithOwnership(FILE* file);
+
+void
 PutCString(const char* string, int len = -1);
 
 size_t
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

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

[Ying Chen via lldb-commits]

chying created this revision.
chying added reviewers: chaoren, zturner.
chying added a subscriber: lldb-commits.
Herald added subscribers: danalbert, tberghammer, rengolin, aemerson.

xfail TestCallUserAnonTypedef.test for -mthumb, 
TestReturnValue.test_with_python for hard fp, 
TestLldbGdbServer.software_breakpoint_set_and_remove_work for hard fp.

http://reviews.llvm.org/D18481

Files:
  packages/Python/lldbsuite/test/decorators.py
  
packages/Python/lldbsuite/test/expression_command/anonymous-struct/TestCallUserAnonTypedef.py
  packages/Python/lldbsuite/test/functionalities/return-value/TestReturnValue.py
  packages/Python/lldbsuite/test/tools/lldb-server/TestLldbGdbServer.py

Index: packages/Python/lldbsuite/test/tools/lldb-server/TestLldbGdbServer.py
===
--- packages/Python/lldbsuite/test/tools/lldb-server/TestLldbGdbServer.py
+++ packages/Python/lldbsuite/test/tools/lldb-server/TestLldbGdbServer.py
@@ -1122,6 +1122,7 @@
 self.set_inferior_startup_launch()
 self.qMemoryRegionInfo_reports_heap_address_as_readable_writeable()
 
+@expectedFailureAll(bugnumber="llvm.org/pr27075", compiler="gcc", 
archs=["arm"], env_flags={"CFLAGS_EXTRAS": "-mthumb"})
 def software_breakpoint_set_and_remove_work(self):
 # Start up the inferior.
 procs = self.prep_debug_monitor_and_inferior(
Index: 
packages/Python/lldbsuite/test/functionalities/return-value/TestReturnValue.py
===
--- 
packages/Python/lldbsuite/test/functionalities/return-value/TestReturnValue.py
+++ 
packages/Python/lldbsuite/test/functionalities/return-value/TestReturnValue.py
@@ -21,6 +21,7 @@
 @expectedFailureAll(oslist=["linux"], compiler="clang", 
compiler_version=["<=", "3.6"], archs=["i386"])
 @expectedFailureAll(bugnumber="llvm.org/pr25785", hostoslist=["windows"], 
compiler="gcc", archs=["i386"], triple='.*-android')
 @expectedFailureAll(oslist=["windows"], bugnumber="llvm.org/pr24778")
+@expectedFailureAll(bugnumber="llvm.org/pr27073", compiler="gcc", 
archs=["arm"], env_flags={"CFLAGS_EXTRAS": "-mfloat-abi=hard"})
 @add_test_categories(['pyapi'])
 def test_with_python(self):
 """Test getting return values from stepping out."""
Index: 
packages/Python/lldbsuite/test/expression_command/anonymous-struct/TestCallUserAnonTypedef.py
===
--- 
packages/Python/lldbsuite/test/expression_command/anonymous-struct/TestCallUserAnonTypedef.py
+++ 
packages/Python/lldbsuite/test/expression_command/anonymous-struct/TestCallUserAnonTypedef.py
@@ -23,6 +23,7 @@
 # Find the breakpoint
 self.line = line_number('main.cpp', '// lldb testsuite break')
 
+@expectedFailureAll(bugnumber="llvm.org/pr27074", compiler="gcc", 
archs=["arm"], env_flags={"CFLAGS_EXTRAS": "-mfloat-abi=hard"})
 def test(self):
 """Test typedeffed untagged struct arguments for function call 
expressions"""
 self.build()
Index: packages/Python/lldbsuite/test/decorators.py
===
--- packages/Python/lldbsuite/test/decorators.py
+++ packages/Python/lldbsuite/test/decorators.py
@@ -132,13 +132,20 @@
 else:
 return skipTestIfFn_impl
 
+def _check_expected_env_flag(env_flags):
+for env, value in env_flags.iteritems():
+env_val = os.environ.get(env)
+if env_val is None or value not in env_val.split():
+return False
+return True
+
 def _decorateTest(mode,
  bugnumber=None, oslist=None, hostoslist=None,
  compiler=None, compiler_version=None,
  archs=None, triple=None,
  debug_info=None,
  swig_version=None, py_version=None,
- remote=None):
+ remote=None, env_flags=None):
 def fn(self):
 skip_for_os = 
_match_decorator_property(lldbplatform.translate(oslist), self.getPlatform())
 skip_for_hostos = 
_match_decorator_property(lldbplatform.translate(hostoslist), 
lldbplatformutil.getHostPlatform())
@@ -151,6 +158,8 @@
 skip_for_swig_version = (swig_version is None) or (not hasattr(lldb, 
'swig_version')) or (_check_expected_version(swig_version[0], swig_version[1], 
lldb.swig_version))
 skip_for_py_version = (py_version is None) or 
_check_expected_version(py_version[0], py_version[1], sys.version_info)
 
+skip_for_env_flags = (env_flags is None) or 
_check_expected_env_flag(env_flags)
+
 # For the test to be skipped, all specified (e.g. not None) parameters 
must be True.
 # An unspecified parameter means "any", so those are marked skip by 
default.  And we skip
 # the final test if all conditions are True.
@@ -162,7 +171,8 @@
   (triple, skip_for_triple, "target triple"),
   (swig_versi

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

[Francis Ricci via lldb-commits]

fjricci updated this revision to Diff 51680.
fjricci added a comment.

Correct whitespace change


http://reviews.llvm.org/D18459

Files:
  include/lldb/API/SBCommandReturnObject.h
  scripts/interface/SBCommandReturnObject.i
  source/API/SBCommandReturnObject.cpp

Index: source/API/SBCommandReturnObject.cpp
===
--- source/API/SBCommandReturnObject.cpp
+++ source/API/SBCommandReturnObject.cpp
@@ -270,6 +270,20 @@
 }
 
 void
+SBCommandReturnObject::SetImmediateOutputFileWithOwnership(FILE *fh)
+{
+if (m_opaque_ap)
+m_opaque_ap->SetImmediateOutputFile(fh, true);
+}
+
+void
+SBCommandReturnObject::SetImmediateErrorFileWithOwnership(FILE *fh)
+{
+if (m_opaque_ap)
+m_opaque_ap->SetImmediateErrorFile(fh, true);
+}
+
+void
 SBCommandReturnObject::PutCString(const char* string, int len)
 {
 if (m_opaque_ap)
Index: scripts/interface/SBCommandReturnObject.i
===
--- scripts/interface/SBCommandReturnObject.i
+++ scripts/interface/SBCommandReturnObject.i
@@ -84,11 +84,14 @@
 bool
 GetDescription (lldb::SBStream &description);
 
+%rename(SetImmediateOutputFile) SetImmediateOutputFileWithOwnership;
+%rename(SetImmediateErrorFile) SetImmediateErrorFileWithOwnership;
+
 void
-SetImmediateOutputFile (FILE *fh);
-
+SetImmediateOutputFileWithOwnership (FILE *fh);
+
 void
-SetImmediateErrorFile (FILE *fh);
+SetImmediateErrorFileWithOwnership (FILE *fh);
 
void
PutCString(const char* string, int len);
Index: include/lldb/API/SBCommandReturnObject.h
===
--- include/lldb/API/SBCommandReturnObject.h
+++ include/lldb/API/SBCommandReturnObject.h
@@ -91,6 +91,12 @@
 SetImmediateErrorFile (FILE *fh);
 
 void
+SetImmediateOutputFileWithOwnership(FILE* file);
+
+void
+SetImmediateErrorFileWithOwnership(FILE* file);
+
+void
 PutCString(const char* string, int len = -1);
 
 size_t


Index: source/API/SBCommandReturnObject.cpp
===
--- source/API/SBCommandReturnObject.cpp
+++ source/API/SBCommandReturnObject.cpp
@@ -270,6 +270,20 @@
 }
 
 void
+SBCommandReturnObject::SetImmediateOutputFileWithOwnership(FILE *fh)
+{
+if (m_opaque_ap)
+m_opaque_ap->SetImmediateOutputFile(fh, true);
+}
+
+void
+SBCommandReturnObject::SetImmediateErrorFileWithOwnership(FILE *fh)
+{
+if (m_opaque_ap)
+m_opaque_ap->SetImmediateErrorFile(fh, true);
+}
+
+void
 SBCommandReturnObject::PutCString(const char* string, int len)
 {
 if (m_opaque_ap)
Index: scripts/interface/SBCommandReturnObject.i
===
--- scripts/interface/SBCommandReturnObject.i
+++ scripts/interface/SBCommandReturnObject.i
@@ -84,11 +84,14 @@
 bool
 GetDescription (lldb::SBStream &description);
 
+%rename(SetImmediateOutputFile) SetImmediateOutputFileWithOwnership;
+%rename(SetImmediateErrorFile) SetImmediateErrorFileWithOwnership;
+
 void
-SetImmediateOutputFile (FILE *fh);
-
+SetImmediateOutputFileWithOwnership (FILE *fh);
+
 void
-SetImmediateErrorFile (FILE *fh);
+SetImmediateErrorFileWithOwnership (FILE *fh);
 
 	void
 	PutCString(const char* string, int len);
Index: include/lldb/API/SBCommandReturnObject.h
===
--- include/lldb/API/SBCommandReturnObject.h
+++ include/lldb/API/SBCommandReturnObject.h
@@ -91,6 +91,12 @@
 SetImmediateErrorFile (FILE *fh);
 
 void
+SetImmediateOutputFileWithOwnership(FILE* file);
+
+void
+SetImmediateErrorFileWithOwnership(FILE* file);
+
+void
 PutCString(const char* string, int len = -1);
 
 size_t
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

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

[Zachary Turner via lldb-commits]

zturner added reviewers: labath, tberghammer.
zturner added a comment.

This seems very strange to me.  What if someone specifies those flags on the 
command line in the makefile instead of via some environment variables?

It also seems like a very specialized argument that we might use once or twice 
ever.

+pavel and tamas in case they have some suggestions.


http://reviews.llvm.org/D18481



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

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

[Chaoren Lin via lldb-commits]

chaoren added a comment.

In http://reviews.llvm.org/D18481#383694, @zturner wrote:

> This seems very strange to me.  What if someone specifies those flags on the 
> command line in the makefile instead of via some environment variables?


I don't think there's anything we can do about that unless we parse the 
Makefiles from within the test suite.  These kinds of flags are bad to hard 
code into the Makefiles anyway, unless there's a way to mark a test as thumb 
specific or hard float specific in the test suite, in which case we'd be using 
*those* indicators instead to filter for xfail. For now I think this is a 
pretty reasonable way to discriminate on the validity of failures based on 
compile flags.

> It also seems like a very specialized argument that we might use once or 
> twice ever.


This applies to arbitrary compile flags. Though you probably won't ever need it 
for x86/x86_64, I can see it being useful for ARM and MIPS due to the sheer 
number of variations.


http://reviews.llvm.org/D18481



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

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

[Zachary Turner via lldb-commits]

zturner added a comment.

Couldn't we have a way to say in the Makefile "never use these flags", then the 
test suite could check the environment and remove them if they are present.  
This woudl allow the test to run.

architecture, compiler, etc are things we don't really have control over.  If a 
flag or an environment variable is causing a test to fail, it seems like the 
right thing to do is not to use that flag or environment variable.


http://reviews.llvm.org/D18481



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

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

[Zachary Turner via lldb-commits]

zturner added a comment.

I'll still wait and see what Pavel and/or Tamas say, but if we are going to go 
this route, I would rather the argument be called `cflags` and now `env_flags`. 
 Xfailing a test based on an arbitrary environment variable just seems like 
something we shouldn't be doing.  I'd rather prime the environment however we 
need in order to get the test to run, than disable it and lose test coverage.


http://reviews.llvm.org/D18481



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

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

[Greg Clayton via lldb-commits]

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

I would prefer to do this with overloading if possible. See inlined comments.



Comment at: include/lldb/API/SBCommandReturnObject.h:87-91
@@ -86,7 +86,7 @@
 
 void
 SetImmediateOutputFile (FILE *fh);
 
 void
 SetImmediateErrorFile (FILE *fh);
 

If we end up using overloading, see below, then these should be marked as 
deprecated with a comment. We should also add some header doc to specify that 
the above two functions do not take ownership of the file handle.


Comment at: include/lldb/API/SBCommandReturnObject.h:93-97
@@ -92,2 +92,7 @@
 
 void
+SetImmediateOutputFileWithOwnership(FILE* file);
+
+void
+SetImmediateErrorFileWithOwnership(FILE* file);
+

It might be better to just overload:

```
void
SetImmediateOutputFile(FILE *fh, bool transfer_ownership);

void
SetImmediateErrorFile (FILE *fh, bool transfer_ownership);
```




Comment at: scripts/interface/SBCommandReturnObject.i:87-94
@@ -86,7 +86,10 @@
 
+%rename(SetImmediateOutputFile) SetImmediateOutputFileWithOwnership;
+%rename(SetImmediateErrorFile) SetImmediateErrorFileWithOwnership;
+
 void
-SetImmediateOutputFile (FILE *fh);
-
+SetImmediateOutputFileWithOwnership (FILE *fh);
+
 void
-SetImmediateErrorFile (FILE *fh);
+SetImmediateErrorFileWithOwnership (FILE *fh);
 

Not sure if we can do this if we overload.


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] D18481: Add argument to expectedFailureAll decorator to xfail for environment variables, and xfail tests for hard float abi and -mthumb on android arm

[Ying Chen via lldb-commits]

chying added a comment.

In http://reviews.llvm.org/D18481#383718, @zturner wrote:

> Couldn't we have a way to say in the Makefile "never use these flags", then 
> the test suite could check the environment and remove them if they are 
> present.  This woudl allow the test to run.
>
> architecture, compiler, etc are things we don't really have control over.  If 
> a flag or an environment variable is causing a test to fail, it seems like 
> the right thing to do is not to use that flag or environment variable.


I don't find a way to pass compiler flags to test suite by current dotest 
options (please let me know if there is), so they're passed by CFLAGS_EXTRAS 
variable, which is checked and applied in the main Makefile. Alternative would 
be adding new dotest options to take compiler flags, then we add xfail based on 
compiler flag, please let me know how you think about this approach.

In http://reviews.llvm.org/D18481#383720, @zturner wrote:

> I'll still wait and see what Pavel and/or Tamas say, but if we are going to 
> go this route, I would rather the argument be called `cflags` and not 
> `env_flags`.  Xfailing a test based on an arbitrary environment variable just 
> seems like something we shouldn't be doing.  I'd rather prime the environment 
> however we need in order to get the test to run, than disable it and lose 
> test coverage.


Yes, let's get more opinions on this.


http://reviews.llvm.org/D18481



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

[Lldb-commits] [lldb] r264468 - Fix an issue with nested aliases where the help system wouldn't correctly track the fact that an alias is an alias to a dash-dash alias

[Enrico Granata via lldb-commits]

Author: enrico
Date: Fri Mar 25 16:59:06 2016
New Revision: 264468

URL: http://llvm.org/viewvc/llvm-project?rev=264468&view=rev
Log:
Fix an issue with nested aliases where the help system wouldn't correctly track 
the fact that an alias is an alias to a dash-dash alias
(and I hope I typed the word 'alias' enough times in this commit message :-)


Modified:
lldb/trunk/include/lldb/Interpreter/CommandAlias.h

lldb/trunk/packages/Python/lldbsuite/test/functionalities/nested_alias/TestNestedAlias.py
lldb/trunk/source/Interpreter/CommandAlias.cpp

Modified: lldb/trunk/include/lldb/Interpreter/CommandAlias.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Interpreter/CommandAlias.h?rev=264468&r1=264467&r2=264468&view=diff
==
--- lldb/trunk/include/lldb/Interpreter/CommandAlias.h (original)
+++ lldb/trunk/include/lldb/Interpreter/CommandAlias.h Fri Mar 25 16:59:06 2016
@@ -106,6 +106,10 @@ public:
 std::pair
 Desugar ();
 
+protected:
+bool
+IsNestedAlias ();
+
 private:
 lldb::CommandObjectSP m_underlying_command_sp;
 std::string m_option_string;

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/nested_alias/TestNestedAlias.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/nested_alias/TestNestedAlias.py?rev=264468&r1=264467&r2=264468&view=diff
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/nested_alias/TestNestedAlias.py
 (original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/nested_alias/TestNestedAlias.py
 Fri Mar 25 16:59:06 2016
@@ -46,6 +46,8 @@ class NestedAliasTestCase(TestBase):
 def cleanup():
 self.runCmd('command unalias read', check=False)
 self.runCmd('command unalias rd', check=False)
+self.runCmd('command unalias fo', check=False)
+self.runCmd('command unalias foself', check=False)
 
 # Execute the cleanup function during test case tear down.
 self.addTearDownHook(cleanup)
@@ -58,3 +60,9 @@ class NestedAliasTestCase(TestBase):
 
 self.expect('memory read -f A -c 3 `&my_ptr[0]`', 
substrs=['deadfeed'], matching=False)
 self.expect('rd `&my_ptr[0]`', substrs=['deadfeed'], matching=False)
+
+self.runCmd('command alias fo frame variable -O --')
+self.runCmd('command alias foself fo self')
+
+self.expect('help foself', substrs=['--show-all-children', 
'--raw-output'], matching=False)
+self.expect('help foself', substrs=['Show frame variables.'], 
matching=True)

Modified: lldb/trunk/source/Interpreter/CommandAlias.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Interpreter/CommandAlias.cpp?rev=264468&r1=264467&r2=264468&view=diff
==
--- lldb/trunk/source/Interpreter/CommandAlias.cpp (original)
+++ lldb/trunk/source/Interpreter/CommandAlias.cpp Fri Mar 25 16:59:06 2016
@@ -236,11 +236,22 @@ CommandAlias::IsDashDashCommand ()
 break;
 }
 }
+// if this is a nested alias, it may be adding arguments on top of 
an already dash-dash alias
+if ((m_is_dashdash_alias == eLazyBoolNo) && IsNestedAlias())
+m_is_dashdash_alias = 
(GetUnderlyingCommand()->IsDashDashCommand() ? eLazyBoolYes : eLazyBoolNo);
 }
 }
 return (m_is_dashdash_alias == eLazyBoolYes);
 }
 
+bool
+CommandAlias::IsNestedAlias ()
+{
+if (GetUnderlyingCommand())
+return GetUnderlyingCommand()->IsAlias();
+return false;
+}
+
 std::pair
 CommandAlias::Desugar ()
 {


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

[Lldb-commits] [PATCH] D18484: Change windows cmake to require debug libraries for a debug build, otherwise release libraries

[Ted Woodward via lldb-commits]

ted created this revision.
ted added a reviewer: zturner.
ted added a subscriber: lldb-commits.

On Windows we require both debug and release python executable/libraries; this 
change requires debug for a debug build and release for other builds.

If CMAKE_BUILD_TYPE is not specified, the llvm CMakeLists.txt defaults to 
"Debug".

http://reviews.llvm.org/D18484

Files:
  cmake/modules/LLDBConfig.cmake

Index: cmake/modules/LLDBConfig.cmake
===
--- cmake/modules/LLDBConfig.cmake
+++ cmake/modules/LLDBConfig.cmake
@@ -122,10 +122,18 @@
 unset(PYTHON_RELEASE_DLL)
   endif()
 
-  if (NOT (PYTHON_DEBUG_EXE AND PYTHON_RELEASE_EXE AND PYTHON_DEBUG_LIB AND 
PYTHON_RELEASE_LIB AND PYTHON_DEBUG_DLL AND PYTHON_RELEASE_DLL))
-message("Python installation is corrupt. Python support will be disabled 
for this build.")
-set(LLDB_DISABLE_PYTHON 1 PARENT_SCOPE)
-return()
+  if (CMAKE_BUILD_TYPE STREQUAL "Debug")
+if (NOT (PYTHON_DEBUG_EXE AND PYTHON_DEBUG_LIB AND PYTHON_DEBUG_DLL))
+  message("Python installation is corrupt. Python support will be disabled 
for this build.")
+  set(LLDB_DISABLE_PYTHON 1 PARENT_SCOPE)
+  return()
+endif()
+  else()
+if (NOT (PYTHON_RELEASE_EXE AND PYTHON_RELEASE_LIB AND PYTHON_RELEASE_DLL))
+  message("Python installation is corrupt. Python support will be disabled 
for this build.")
+  set(LLDB_DISABLE_PYTHON 1 PARENT_SCOPE)
+  return()
+endif()
   endif()
 
   # Generator expressions are evaluated in the context of each build 
configuration generated


Index: cmake/modules/LLDBConfig.cmake
===
--- cmake/modules/LLDBConfig.cmake
+++ cmake/modules/LLDBConfig.cmake
@@ -122,10 +122,18 @@
 unset(PYTHON_RELEASE_DLL)
   endif()
 
-  if (NOT (PYTHON_DEBUG_EXE AND PYTHON_RELEASE_EXE AND PYTHON_DEBUG_LIB AND PYTHON_RELEASE_LIB AND PYTHON_DEBUG_DLL AND PYTHON_RELEASE_DLL))
-message("Python installation is corrupt. Python support will be disabled for this build.")
-set(LLDB_DISABLE_PYTHON 1 PARENT_SCOPE)
-return()
+  if (CMAKE_BUILD_TYPE STREQUAL "Debug")
+if (NOT (PYTHON_DEBUG_EXE AND PYTHON_DEBUG_LIB AND PYTHON_DEBUG_DLL))
+  message("Python installation is corrupt. Python support will be disabled for this build.")
+  set(LLDB_DISABLE_PYTHON 1 PARENT_SCOPE)
+  return()
+endif()
+  else()
+if (NOT (PYTHON_RELEASE_EXE AND PYTHON_RELEASE_LIB AND PYTHON_RELEASE_DLL))
+  message("Python installation is corrupt. Python support will be disabled for this build.")
+  set(LLDB_DISABLE_PYTHON 1 PARENT_SCOPE)
+  return()
+endif()
   endif()
 
   # Generator expressions are evaluated in the context of each build configuration generated
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] r264474 - Add a 'language cplusplus demangle' command. This can be useful to provide a low-friction reproduction for issues with the LLDB demangling of C++ symbols

[Enrico Granata via lldb-commits]

Author: enrico
Date: Fri Mar 25 18:14:24 2016
New Revision: 264474

URL: http://llvm.org/viewvc/llvm-project?rev=264474&view=rev
Log:
Add a 'language cplusplus demangle' command. This can be useful to provide a 
low-friction reproduction for issues with the LLDB demangling of C++ symbols

Modified:

lldb/trunk/source/Plugins/LanguageRuntime/CPlusPlus/ItaniumABI/ItaniumABILanguageRuntime.cpp

Modified: 
lldb/trunk/source/Plugins/LanguageRuntime/CPlusPlus/ItaniumABI/ItaniumABILanguageRuntime.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/LanguageRuntime/CPlusPlus/ItaniumABI/ItaniumABILanguageRuntime.cpp?rev=264474&r1=264473&r2=264474&view=diff
==
--- 
lldb/trunk/source/Plugins/LanguageRuntime/CPlusPlus/ItaniumABI/ItaniumABILanguageRuntime.cpp
 (original)
+++ 
lldb/trunk/source/Plugins/LanguageRuntime/CPlusPlus/ItaniumABI/ItaniumABILanguageRuntime.cpp
 Fri Mar 25 18:14:24 2016
@@ -13,11 +13,15 @@
 #include "lldb/Core/ConstString.h"
 #include "lldb/Core/Error.h"
 #include "lldb/Core/Log.h"
+#include "lldb/Core/Mangled.h"
 #include "lldb/Core/Module.h"
 #include "lldb/Core/PluginManager.h"
 #include "lldb/Core/Scalar.h"
 #include "lldb/Core/ValueObject.h"
 #include "lldb/Core/ValueObjectMemory.h"
+#include "lldb/Interpreter/CommandObject.h"
+#include "lldb/Interpreter/CommandObjectMultiword.h"
+#include "lldb/Interpreter/CommandReturnObject.h"
 #include "lldb/Symbol/ClangASTContext.h"
 #include "lldb/Symbol/Symbol.h"
 #include "lldb/Symbol/SymbolFile.h"
@@ -340,12 +344,96 @@ ItaniumABILanguageRuntime::CreateInstanc
 return NULL;
 }
 
+class CommandObjectMultiwordItaniumABI_Demangle : public CommandObjectParsed
+{
+public:
+CommandObjectMultiwordItaniumABI_Demangle (CommandInterpreter 
&interpreter) :
+CommandObjectParsed (interpreter,
+ "demangle",
+ "Demangle a C++ mangled name.",
+ "language cplusplus demangle")
+{
+CommandArgumentEntry arg;
+CommandArgumentData index_arg;
+
+// Define the first (and only) variant of this arg.
+index_arg.arg_type = eArgTypeSymbol;
+index_arg.arg_repetition = eArgRepeatPlus;
+
+// There is only one variant this argument could be; put it into the 
argument entry.
+arg.push_back (index_arg);
+
+// Push the data for the first argument into the m_arguments vector.
+m_arguments.push_back (arg);
+}
+
+~CommandObjectMultiwordItaniumABI_Demangle() override = default;
+
+protected:
+bool
+DoExecute(Args& command, CommandReturnObject &result) override
+{
+bool demangled_any = false;
+bool error_any = false;
+for (size_t i = 0; i < command.GetArgumentCount(); i++)
+{
+auto arg = command.GetArgumentAtIndex(i);
+if (arg && *arg)
+{
+ConstString mangled_cs(arg);
+
+// the actual Mangled class should be strict about this, but 
on the command line
+// if you're copying mangled names out of 'nm' on Darwin, they 
will come out with
+// an extra underscore - be willing to strip this on behalf of 
the user
+// This is the moral equivalent of the -_/-n options to c++filt
+if (mangled_cs.GetStringRef().startswith("__Z"))
+mangled_cs.SetCString(arg+1);
+
+Mangled mangled(mangled_cs, true);
+if (mangled.GuessLanguage() == lldb::eLanguageTypeC_plus_plus)
+{
+ConstString 
demangled(mangled.GetDisplayDemangledName(lldb::eLanguageTypeC_plus_plus));
+demangled_any = true;
+result.AppendMessageWithFormat("%s ---> %s\n", arg, 
demangled.GetCString());
+}
+else
+{
+error_any = true;
+result.AppendErrorWithFormat("%s is not a valid C++ 
mangled name\n", arg);
+}
+}
+}
+
+result.SetStatus(error_any ? lldb::eReturnStatusFailed :
+ (demangled_any ? 
lldb::eReturnStatusSuccessFinishResult : 
lldb::eReturnStatusSuccessFinishNoResult));
+return result.Succeeded();
+}
+};
+
+class CommandObjectMultiwordItaniumABI : public CommandObjectMultiword
+{
+public:
+CommandObjectMultiwordItaniumABI (CommandInterpreter &interpreter) :
+CommandObjectMultiword (interpreter,
+"cplusplus",
+"A set of commands for operating on the C++ 
Language Runtime.",
+"cplusplus  []")
+{
+LoadSubCommand ("demangle",   CommandObjectSP (new 
CommandObjectMultiwordItaniumABI_Demangle (interpreter)));
+}
+
+~CommandObjectMultiw

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

[Francis Ricci via lldb-commits]

fjricci updated this revision to Diff 51698.
fjricci added a comment.

Use function overloading


http://reviews.llvm.org/D18459

Files:
  include/lldb/API/SBCommandReturnObject.h
  scripts/interface/SBCommandReturnObject.i
  source/API/SBCommandReturnObject.cpp

Index: source/API/SBCommandReturnObject.cpp
===
--- source/API/SBCommandReturnObject.cpp
+++ source/API/SBCommandReturnObject.cpp
@@ -258,15 +258,27 @@
 void
 SBCommandReturnObject::SetImmediateOutputFile(FILE *fh)
 {
-if (m_opaque_ap)
-m_opaque_ap->SetImmediateOutputFile(fh);
+SetImmediateOutputFile(fh, false);
 }
 
 void
 SBCommandReturnObject::SetImmediateErrorFile(FILE *fh)
 {
+SetImmediateErrorFile(fh, false);
+}
+
+void
+SBCommandReturnObject::SetImmediateOutputFile(FILE *fh, bool 
transfer_ownership)
+{
+if (m_opaque_ap)
+m_opaque_ap->SetImmediateOutputFile(fh, transfer_ownership);
+}
+
+void
+SBCommandReturnObject::SetImmediateErrorFile(FILE *fh, bool transfer_ownership)
+{
 if (m_opaque_ap)
-m_opaque_ap->SetImmediateErrorFile(fh);
+m_opaque_ap->SetImmediateErrorFile(fh, transfer_ownership);
 }
 
 void
Index: scripts/interface/SBCommandReturnObject.i
===
--- scripts/interface/SBCommandReturnObject.i
+++ scripts/interface/SBCommandReturnObject.i
@@ -16,6 +16,7 @@
 
 See SBCommandInterpreter for example usage of SBCommandReturnObject."
 ) SBCommandReturnObject;
+
 class SBCommandReturnObject
 {
 public:
@@ -84,11 +85,17 @@
 bool
 GetDescription (lldb::SBStream &description);
 
-void
-SetImmediateOutputFile (FILE *fh);
-
-void
-SetImmediateErrorFile (FILE *fh);
+
+// wrapping here so that lldb takes ownership of the 
+// new FILE* created inside of the swig interface
+%extend {
+void SetImmediateOutputFile(FILE *fh) {
+self->SetImmediateOutputFile(fh, true);
+}
+void SetImmediateErrorFile(FILE *fh) {
+self->SetImmediateErrorFile(fh, true);
+}
+}
 
void
PutCString(const char* string, int len);
Index: include/lldb/API/SBCommandReturnObject.h
===
--- include/lldb/API/SBCommandReturnObject.h
+++ include/lldb/API/SBCommandReturnObject.h
@@ -83,14 +83,22 @@
 
 bool
 GetDescription (lldb::SBStream &description);
-
+   
+// deprecated, these two functions do not take
+// ownership of file handle
 void
 SetImmediateOutputFile (FILE *fh);
 
 void
 SetImmediateErrorFile (FILE *fh);
 
 void
+SetImmediateOutputFile (FILE *fh, bool transfer_ownership);
+
+void
+SetImmediateErrorFile (FILE *fh, bool transfer_ownership);
+
+void
 PutCString(const char* string, int len = -1);
 
 size_t


Index: source/API/SBCommandReturnObject.cpp
===
--- source/API/SBCommandReturnObject.cpp
+++ source/API/SBCommandReturnObject.cpp
@@ -258,15 +258,27 @@
 void
 SBCommandReturnObject::SetImmediateOutputFile(FILE *fh)
 {
-if (m_opaque_ap)
-m_opaque_ap->SetImmediateOutputFile(fh);
+SetImmediateOutputFile(fh, false);
 }
 
 void
 SBCommandReturnObject::SetImmediateErrorFile(FILE *fh)
 {
+SetImmediateErrorFile(fh, false);
+}
+
+void
+SBCommandReturnObject::SetImmediateOutputFile(FILE *fh, bool transfer_ownership)
+{
+if (m_opaque_ap)
+m_opaque_ap->SetImmediateOutputFile(fh, transfer_ownership);
+}
+
+void
+SBCommandReturnObject::SetImmediateErrorFile(FILE *fh, bool transfer_ownership)
+{
 if (m_opaque_ap)
-m_opaque_ap->SetImmediateErrorFile(fh);
+m_opaque_ap->SetImmediateErrorFile(fh, transfer_ownership);
 }
 
 void
Index: scripts/interface/SBCommandReturnObject.i
===
--- scripts/interface/SBCommandReturnObject.i
+++ scripts/interface/SBCommandReturnObject.i
@@ -16,6 +16,7 @@
 
 See SBCommandInterpreter for example usage of SBCommandReturnObject."
 ) SBCommandReturnObject;
+
 class SBCommandReturnObject
 {
 public:
@@ -84,11 +85,17 @@
 bool
 GetDescription (lldb::SBStream &description);
 
-void
-SetImmediateOutputFile (FILE *fh);
-
-void
-SetImmediateErrorFile (FILE *fh);
+
+// wrapping here so that lldb takes ownership of the 
+// new FILE* created inside of the swig interface
+%extend {
+void SetImmediateOutputFile(FILE *fh) {
+self->SetImmediateOutputFile(fh, true);
+}
+void SetImmediateErrorFile(FILE *fh) {
+self->SetImmediateErrorFile(fh, true);
+}
+}
 
 	void
 	PutCString(const char* string, int len);
Index: include/lldb/API/SBCommandReturnObject.h
===
--- include/lldb/API/SBCommandReturnObje

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

[Francis Ricci via lldb-commits]

fjricci updated this revision to Diff 51699.
fjricci added a comment.

Fix whitespace


http://reviews.llvm.org/D18459

Files:
  include/lldb/API/SBCommandReturnObject.h
  scripts/interface/SBCommandReturnObject.i
  source/API/SBCommandReturnObject.cpp

Index: source/API/SBCommandReturnObject.cpp
===
--- source/API/SBCommandReturnObject.cpp
+++ source/API/SBCommandReturnObject.cpp
@@ -258,15 +258,27 @@
 void
 SBCommandReturnObject::SetImmediateOutputFile(FILE *fh)
 {
-if (m_opaque_ap)
-m_opaque_ap->SetImmediateOutputFile(fh);
+SetImmediateOutputFile(fh, false);
 }
 
 void
 SBCommandReturnObject::SetImmediateErrorFile(FILE *fh)
 {
+SetImmediateErrorFile(fh, false);
+}
+
+void
+SBCommandReturnObject::SetImmediateOutputFile(FILE *fh, bool 
transfer_ownership)
+{
+if (m_opaque_ap)
+m_opaque_ap->SetImmediateOutputFile(fh, transfer_ownership);
+}
+
+void
+SBCommandReturnObject::SetImmediateErrorFile(FILE *fh, bool transfer_ownership)
+{
 if (m_opaque_ap)
-m_opaque_ap->SetImmediateErrorFile(fh);
+m_opaque_ap->SetImmediateErrorFile(fh, transfer_ownership);
 }
 
 void
Index: scripts/interface/SBCommandReturnObject.i
===
--- scripts/interface/SBCommandReturnObject.i
+++ scripts/interface/SBCommandReturnObject.i
@@ -84,11 +84,17 @@
 bool
 GetDescription (lldb::SBStream &description);
 
-void
-SetImmediateOutputFile (FILE *fh);
-
-void
-SetImmediateErrorFile (FILE *fh);
+
+// wrapping here so that lldb takes ownership of the 
+// new FILE* created inside of the swig interface
+%extend {
+void SetImmediateOutputFile(FILE *fh) {
+self->SetImmediateOutputFile(fh, true);
+}
+void SetImmediateErrorFile(FILE *fh) {
+self->SetImmediateErrorFile(fh, true);
+}
+}
 
void
PutCString(const char* string, int len);
Index: include/lldb/API/SBCommandReturnObject.h
===
--- include/lldb/API/SBCommandReturnObject.h
+++ include/lldb/API/SBCommandReturnObject.h
@@ -83,14 +83,22 @@
 
 bool
 GetDescription (lldb::SBStream &description);
-
+   
+// deprecated, these two functions do not take
+// ownership of file handle
 void
 SetImmediateOutputFile (FILE *fh);
 
 void
 SetImmediateErrorFile (FILE *fh);
 
 void
+SetImmediateOutputFile (FILE *fh, bool transfer_ownership);
+
+void
+SetImmediateErrorFile (FILE *fh, bool transfer_ownership);
+
+void
 PutCString(const char* string, int len = -1);
 
 size_t


Index: source/API/SBCommandReturnObject.cpp
===
--- source/API/SBCommandReturnObject.cpp
+++ source/API/SBCommandReturnObject.cpp
@@ -258,15 +258,27 @@
 void
 SBCommandReturnObject::SetImmediateOutputFile(FILE *fh)
 {
-if (m_opaque_ap)
-m_opaque_ap->SetImmediateOutputFile(fh);
+SetImmediateOutputFile(fh, false);
 }
 
 void
 SBCommandReturnObject::SetImmediateErrorFile(FILE *fh)
 {
+SetImmediateErrorFile(fh, false);
+}
+
+void
+SBCommandReturnObject::SetImmediateOutputFile(FILE *fh, bool transfer_ownership)
+{
+if (m_opaque_ap)
+m_opaque_ap->SetImmediateOutputFile(fh, transfer_ownership);
+}
+
+void
+SBCommandReturnObject::SetImmediateErrorFile(FILE *fh, bool transfer_ownership)
+{
 if (m_opaque_ap)
-m_opaque_ap->SetImmediateErrorFile(fh);
+m_opaque_ap->SetImmediateErrorFile(fh, transfer_ownership);
 }
 
 void
Index: scripts/interface/SBCommandReturnObject.i
===
--- scripts/interface/SBCommandReturnObject.i
+++ scripts/interface/SBCommandReturnObject.i
@@ -84,11 +84,17 @@
 bool
 GetDescription (lldb::SBStream &description);
 
-void
-SetImmediateOutputFile (FILE *fh);
-
-void
-SetImmediateErrorFile (FILE *fh);
+
+// wrapping here so that lldb takes ownership of the 
+// new FILE* created inside of the swig interface
+%extend {
+void SetImmediateOutputFile(FILE *fh) {
+self->SetImmediateOutputFile(fh, true);
+}
+void SetImmediateErrorFile(FILE *fh) {
+self->SetImmediateErrorFile(fh, true);
+}
+}
 
 	void
 	PutCString(const char* string, int len);
Index: include/lldb/API/SBCommandReturnObject.h
===
--- include/lldb/API/SBCommandReturnObject.h
+++ include/lldb/API/SBCommandReturnObject.h
@@ -83,14 +83,22 @@
 
 bool
 GetDescription (lldb::SBStream &description);
-
+   
+// deprecated, these two functions do not take
+// ownership of file handle
 void
 SetImmediateOutputFile (FILE *fh);
 
 void
 SetImmediateErrorFile (FIL

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

[Greg Clayton via lldb-commits]

clayborg accepted this revision.
clayborg added a comment.

Looks good. Thanks for taking the time to get this working right.


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] [lldb] r264474 - Add a 'language cplusplus demangle' command. This can be useful to provide a low-friction reproduction for issues with the LLDB demangling of C++ symbols

[Zachary Turner via lldb-commits]

Any particular reason this has the word Itanium baked into the name of the
class and description?  MSVC doesn't use the Itanium ABI, but but AFAICT
from looking at this code, it should work for MSVC's abi as well.

Sicne this command isn't actually Itanium ABI specific, I don't think it
should make references to Itanium ABI in its C++ class name or help /
description

On Fri, Mar 25, 2016 at 4:19 PM Enrico Granata via lldb-commits <
lldb-commits@lists.llvm.org> wrote:

> Author: enrico
> Date: Fri Mar 25 18:14:24 2016
> New Revision: 264474
>
> URL: http://llvm.org/viewvc/llvm-project?rev=264474&view=rev
> Log:
> Add a 'language cplusplus demangle' command. This can be useful to provide
> a low-friction reproduction for issues with the LLDB demangling of C++
> symbols
>
> Modified:
>
> lldb/trunk/source/Plugins/LanguageRuntime/CPlusPlus/ItaniumABI/ItaniumABILanguageRuntime.cpp
>
> Modified:
> lldb/trunk/source/Plugins/LanguageRuntime/CPlusPlus/ItaniumABI/ItaniumABILanguageRuntime.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/LanguageRuntime/CPlusPlus/ItaniumABI/ItaniumABILanguageRuntime.cpp?rev=264474&r1=264473&r2=264474&view=diff
>
> ==
> ---
> lldb/trunk/source/Plugins/LanguageRuntime/CPlusPlus/ItaniumABI/ItaniumABILanguageRuntime.cpp
> (original)
> +++
> lldb/trunk/source/Plugins/LanguageRuntime/CPlusPlus/ItaniumABI/ItaniumABILanguageRuntime.cpp
> Fri Mar 25 18:14:24 2016
> @@ -13,11 +13,15 @@
>  #include "lldb/Core/ConstString.h"
>  #include "lldb/Core/Error.h"
>  #include "lldb/Core/Log.h"
> +#include "lldb/Core/Mangled.h"
>  #include "lldb/Core/Module.h"
>  #include "lldb/Core/PluginManager.h"
>  #include "lldb/Core/Scalar.h"
>  #include "lldb/Core/ValueObject.h"
>  #include "lldb/Core/ValueObjectMemory.h"
> +#include "lldb/Interpreter/CommandObject.h"
> +#include "lldb/Interpreter/CommandObjectMultiword.h"
> +#include "lldb/Interpreter/CommandReturnObject.h"
>  #include "lldb/Symbol/ClangASTContext.h"
>  #include "lldb/Symbol/Symbol.h"
>  #include "lldb/Symbol/SymbolFile.h"
> @@ -340,12 +344,96 @@ ItaniumABILanguageRuntime::CreateInstanc
>  return NULL;
>  }
>
> +class CommandObjectMultiwordItaniumABI_Demangle : public
> CommandObjectParsed
> +{
> +public:
> +CommandObjectMultiwordItaniumABI_Demangle (CommandInterpreter
> &interpreter) :
> +CommandObjectParsed (interpreter,
> + "demangle",
> + "Demangle a C++ mangled name.",
> + "language cplusplus demangle")
> +{
> +CommandArgumentEntry arg;
> +CommandArgumentData index_arg;
> +
> +// Define the first (and only) variant of this arg.
> +index_arg.arg_type = eArgTypeSymbol;
> +index_arg.arg_repetition = eArgRepeatPlus;
> +
> +// There is only one variant this argument could be; put it into
> the argument entry.
> +arg.push_back (index_arg);
> +
> +// Push the data for the first argument into the m_arguments
> vector.
> +m_arguments.push_back (arg);
> +}
> +
> +~CommandObjectMultiwordItaniumABI_Demangle() override = default;
> +
> +protected:
> +bool
> +DoExecute(Args& command, CommandReturnObject &result) override
> +{
> +bool demangled_any = false;
> +bool error_any = false;
> +for (size_t i = 0; i < command.GetArgumentCount(); i++)
> +{
> +auto arg = command.GetArgumentAtIndex(i);
> +if (arg && *arg)
> +{
> +ConstString mangled_cs(arg);
> +
> +// the actual Mangled class should be strict about this,
> but on the command line
> +// if you're copying mangled names out of 'nm' on Darwin,
> they will come out with
> +// an extra underscore - be willing to strip this on
> behalf of the user
> +// This is the moral equivalent of the -_/-n options to
> c++filt
> +if (mangled_cs.GetStringRef().startswith("__Z"))
> +mangled_cs.SetCString(arg+1);
> +
> +Mangled mangled(mangled_cs, true);
> +if (mangled.GuessLanguage() ==
> lldb::eLanguageTypeC_plus_plus)
> +{
> +ConstString
> demangled(mangled.GetDisplayDemangledName(lldb::eLanguageTypeC_plus_plus));
> +demangled_any = true;
> +result.AppendMessageWithFormat("%s ---> %s\n", arg,
> demangled.GetCString());
> +}
> +else
> +{
> +error_any = true;
> +result.AppendErrorWithFormat("%s is not a valid C++
> mangled name\n", arg);
> +}
> +}
> +}
> +
> +result.SetStatus(error_any ? lldb::eReturnStatusFailed :
> + (demangled_any ?
> lldb::eReturnStatusSuccessFinishResult :
> lldb::eReturnStatusSu

[Lldb-commits] [lldb] r264476 - Fix FILE * leak in Python API

[Stephane Sezer via lldb-commits]

Author: sas
Date: Fri Mar 25 18:40:32 2016
New Revision: 264476

URL: http://llvm.org/viewvc/llvm-project?rev=264476&view=rev
Log:
Fix FILE * leak in Python API

Summary:
This fixes a leak introduced by some of these changes:
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.

Reviewers: granata.enrico, zturner, clayborg

Subscribers: zturner, lldb-commits, sas

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

Change by Francis Ricci 

Modified:
lldb/trunk/include/lldb/API/SBCommandReturnObject.h
lldb/trunk/scripts/interface/SBCommandReturnObject.i
lldb/trunk/source/API/SBCommandReturnObject.cpp

Modified: lldb/trunk/include/lldb/API/SBCommandReturnObject.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/API/SBCommandReturnObject.h?rev=264476&r1=264475&r2=264476&view=diff
==
--- lldb/trunk/include/lldb/API/SBCommandReturnObject.h (original)
+++ lldb/trunk/include/lldb/API/SBCommandReturnObject.h Fri Mar 25 18:40:32 2016
@@ -83,7 +83,9 @@ public:
 
 bool
 GetDescription (lldb::SBStream &description);
-
+   
+// deprecated, these two functions do not take
+// ownership of file handle
 void
 SetImmediateOutputFile (FILE *fh);
 
@@ -91,6 +93,12 @@ public:
 SetImmediateErrorFile (FILE *fh);
 
 void
+SetImmediateOutputFile (FILE *fh, bool transfer_ownership);
+
+void
+SetImmediateErrorFile (FILE *fh, bool transfer_ownership);
+
+void
 PutCString(const char* string, int len = -1);
 
 size_t

Modified: lldb/trunk/scripts/interface/SBCommandReturnObject.i
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/scripts/interface/SBCommandReturnObject.i?rev=264476&r1=264475&r2=264476&view=diff
==
--- lldb/trunk/scripts/interface/SBCommandReturnObject.i (original)
+++ lldb/trunk/scripts/interface/SBCommandReturnObject.i Fri Mar 25 18:40:32 
2016
@@ -84,11 +84,17 @@ public:
 bool
 GetDescription (lldb::SBStream &description);
 
-void
-SetImmediateOutputFile (FILE *fh);
-
-void
-SetImmediateErrorFile (FILE *fh);
+
+// wrapping here so that lldb takes ownership of the 
+// new FILE* created inside of the swig interface
+%extend {
+void SetImmediateOutputFile(FILE *fh) {
+self->SetImmediateOutputFile(fh, true);
+}
+void SetImmediateErrorFile(FILE *fh) {
+self->SetImmediateErrorFile(fh, true);
+}
+}
 
void
PutCString(const char* string, int len);

Modified: lldb/trunk/source/API/SBCommandReturnObject.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/API/SBCommandReturnObject.cpp?rev=264476&r1=264475&r2=264476&view=diff
==
--- lldb/trunk/source/API/SBCommandReturnObject.cpp (original)
+++ lldb/trunk/source/API/SBCommandReturnObject.cpp Fri Mar 25 18:40:32 2016
@@ -258,15 +258,27 @@ SBCommandReturnObject::GetDescription (S
 void
 SBCommandReturnObject::SetImmediateOutputFile(FILE *fh)
 {
-if (m_opaque_ap)
-m_opaque_ap->SetImmediateOutputFile(fh);
+SetImmediateOutputFile(fh, false);
 }
 
 void
 SBCommandReturnObject::SetImmediateErrorFile(FILE *fh)
 {
+SetImmediateErrorFile(fh, false);
+}
+
+void
+SBCommandReturnObject::SetImmediateOutputFile(FILE *fh, bool 
transfer_ownership)
+{
+if (m_opaque_ap)
+m_opaque_ap->SetImmediateOutputFile(fh, transfer_ownership);
+}
+
+void
+SBCommandReturnObject::SetImmediateErrorFile(FILE *fh, bool transfer_ownership)
+{
 if (m_opaque_ap)
-m_opaque_ap->SetImmediateErrorFile(fh);
+m_opaque_ap->SetImmediateErrorFile(fh, transfer_ownership);
 }
 
 void


___
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

[Stephane Sezer via lldb-commits]

sas added a comment.

Committed as r264476.


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

[Francis Ricci via lldb-commits]

fjricci abandoned this revision.
fjricci added a comment.

Committed.


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] D16488: Fix getCompiler in unit testing framework on compiler symlinks

[Francis Ricci via lldb-commits]

fjricci abandoned this revision.
fjricci added a comment.

Committed.


http://reviews.llvm.org/D16488



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

Re: [Lldb-commits] [lldb] r264474 - Add a 'language cplusplus demangle' command. This can be useful to provide a low-friction reproduction for issues with the LLDB demangling of C++ symbols

[Enrico Granata via lldb-commits]

> On Mar 25, 2016, at 4:39 PM, Zachary Turner  wrote:
> 
> Any particular reason this has the word Itanium baked into the name of the 
> class

The name of the C++ language runtime is ItaniumABI
I don’t think we have a language runtime for the C++ MSVC ABI
We can revisit where this command lives at that time

> and description?

It shouldn’t - it should be “language cplusplus demangle”, no mention of Itanium
If you are referring to the description of the plugin overall, that is correct, 
and should stay as-is

Again, the hierarchy can be revisited when a C++ MSVC ABI runtime plugin exists.

>   MSVC doesn't use the Itanium ABI, but but AFAICT from looking at this code, 
> it should work for MSVC's abi as well.  
> 

I have no way to test it, but I would assume so, yes.

> Sicne this command isn't actually Itanium ABI specific, I don't think it 
> should make references to Itanium ABI in its C++ class name

This seems nitpicking to me, since the entire file is named 
ItaniumABILanguageRuntime.cpp

> or help / description

I don’t think it does

> 
> On Fri, Mar 25, 2016 at 4:19 PM Enrico Granata via lldb-commits 
> mailto:lldb-commits@lists.llvm.org>> wrote:
> Author: enrico
> Date: Fri Mar 25 18:14:24 2016
> New Revision: 264474
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=264474&view=rev 
> 
> Log:
> Add a 'language cplusplus demangle' command. This can be useful to provide a 
> low-friction reproduction for issues with the LLDB demangling of C++ symbols
> 
> Modified:
> 
> lldb/trunk/source/Plugins/LanguageRuntime/CPlusPlus/ItaniumABI/ItaniumABILanguageRuntime.cpp
> 
> Modified: 
> lldb/trunk/source/Plugins/LanguageRuntime/CPlusPlus/ItaniumABI/ItaniumABILanguageRuntime.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/LanguageRuntime/CPlusPlus/ItaniumABI/ItaniumABILanguageRuntime.cpp?rev=264474&r1=264473&r2=264474&view=diff
>  
> 
> ==
> --- 
> lldb/trunk/source/Plugins/LanguageRuntime/CPlusPlus/ItaniumABI/ItaniumABILanguageRuntime.cpp
>  (original)
> +++ 
> lldb/trunk/source/Plugins/LanguageRuntime/CPlusPlus/ItaniumABI/ItaniumABILanguageRuntime.cpp
>  Fri Mar 25 18:14:24 2016
> @@ -13,11 +13,15 @@
>  #include "lldb/Core/ConstString.h"
>  #include "lldb/Core/Error.h"
>  #include "lldb/Core/Log.h"
> +#include "lldb/Core/Mangled.h"
>  #include "lldb/Core/Module.h"
>  #include "lldb/Core/PluginManager.h"
>  #include "lldb/Core/Scalar.h"
>  #include "lldb/Core/ValueObject.h"
>  #include "lldb/Core/ValueObjectMemory.h"
> +#include "lldb/Interpreter/CommandObject.h"
> +#include "lldb/Interpreter/CommandObjectMultiword.h"
> +#include "lldb/Interpreter/CommandReturnObject.h"
>  #include "lldb/Symbol/ClangASTContext.h"
>  #include "lldb/Symbol/Symbol.h"
>  #include "lldb/Symbol/SymbolFile.h"
> @@ -340,12 +344,96 @@ ItaniumABILanguageRuntime::CreateInstanc
>  return NULL;
>  }
> 
> +class CommandObjectMultiwordItaniumABI_Demangle : public CommandObjectParsed
> +{
> +public:
> +CommandObjectMultiwordItaniumABI_Demangle (CommandInterpreter 
> &interpreter) :
> +CommandObjectParsed (interpreter,
> + "demangle",
> + "Demangle a C++ mangled name.",
> + "language cplusplus demangle")
> +{
> +CommandArgumentEntry arg;
> +CommandArgumentData index_arg;
> +
> +// Define the first (and only) variant of this arg.
> +index_arg.arg_type = eArgTypeSymbol;
> +index_arg.arg_repetition = eArgRepeatPlus;
> +
> +// There is only one variant this argument could be; put it into the 
> argument entry.
> +arg.push_back (index_arg);
> +
> +// Push the data for the first argument into the m_arguments vector.
> +m_arguments.push_back (arg);
> +}
> +
> +~CommandObjectMultiwordItaniumABI_Demangle() override = default;
> +
> +protected:
> +bool
> +DoExecute(Args& command, CommandReturnObject &result) override
> +{
> +bool demangled_any = false;
> +bool error_any = false;
> +for (size_t i = 0; i < command.GetArgumentCount(); i++)
> +{
> +auto arg = command.GetArgumentAtIndex(i);
> +if (arg && *arg)
> +{
> +ConstString mangled_cs(arg);
> +
> +// the actual Mangled class should be strict about this, but 
> on the command line
> +// if you're copying mangled names out of 'nm' on Darwin, 
> they will come out with
> +// an extra underscore - be willing to strip this on behalf 
> of the user
> +// This is the moral equivalent of the -_/-n options to 
> c++filt
> +if (mangle

[Lldb-commits] [lldb] r264449 - Fix now-ambiguous references to Error.

[Lang Hames via lldb-commits]

Author: lhames
Date: Fri Mar 25 14:27:24 2016
New Revision: 264449

URL: http://llvm.org/viewvc/llvm-project?rev=264449&view=rev
Log:
Fix now-ambiguous references to Error.

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=264449&r1=264448&r2=264449&view=diff
==
--- lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp 
(original)
+++ lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp 
Fri Mar 25 14:27:24 2016
@@ -793,7 +793,7 @@ static bool FindFunctionInModule (ConstS
 return false;
 }
 
-Error
+lldb_private::Error
 ClangExpressionParser::PrepareForExecution (lldb::addr_t &func_addr,
 lldb::addr_t &func_end,
 lldb::IRExecutionUnitSP 
&execution_unit_sp,
@@ -805,7 +805,7 @@ ClangExpressionParser::PrepareForExecuti
func_end = LLDB_INVALID_ADDRESS;
 Log *log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_EXPRESSIONS));
 
-Error err;
+lldb_private::Error err;
 
 std::unique_ptr llvm_module_ap 
(m_code_generator->ReleaseModule());
 
@@ -872,7 +872,7 @@ ClangExpressionParser::PrepareForExecuti
 
 if (execution_policy != eExecutionPolicyAlways && execution_policy != 
eExecutionPolicyTopLevel)
 {
-Error interpret_error;
+lldb_private::Error interpret_error;
 
 bool interpret_function_calls = !process ? false : 
process->CanInterpretFunctionCalls();
 can_interpret =
@@ -957,11 +957,11 @@ ClangExpressionParser::PrepareForExecuti
 return err;
 }
 
-Error
+lldb_private::Error
 ClangExpressionParser::RunStaticInitializers (lldb::IRExecutionUnitSP 
&execution_unit_sp,
   ExecutionContext &exe_ctx)
 {
-Error err;
+lldb_private::Error err;
 
 lldbassert(execution_unit_sp.get());
 lldbassert(exe_ctx.HasThreadScope());


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

Re: [Lldb-commits] [lldb] r264474 - Add a 'language cplusplus demangle' command. This can be useful to provide a low-friction reproduction for issues with the LLDB demangling of C++ symbols

[Zachary Turner via lldb-commits]

Ahh, I didn't notice that our C++ Language Runtime is already called the
Itanium ABI Runtime.  Kind of unfortunate.

I wonder how it would work if a process had modules loaded with different
languages.  Right now we seem to assume 1 language runtime per process, but
really it's more like 1 per module.

On Fri, Mar 25, 2016 at 4:49 PM Enrico Granata  wrote:

> On Mar 25, 2016, at 4:39 PM, Zachary Turner  wrote:
>
> Any particular reason this has the word Itanium baked into the name of the
> class
>
>
> The name of the C++ language runtime is ItaniumABI
> I don’t think we have a language runtime for the C++ MSVC ABI
> We can revisit where this command lives at that time
>
> and description?
>
>
> It shouldn’t - it should be “language cplusplus demangle”, no mention of
> Itanium
> If you are referring to the description of the plugin overall, that is
> correct, and should stay as-is
>
> Again, the hierarchy can be revisited when a C++ MSVC ABI runtime plugin
> exists.
>
>   MSVC doesn't use the Itanium ABI, but but AFAICT from looking at this
> code, it should work for MSVC's abi as well.
>
>
> I have no way to test it, but I would assume so, yes.
>
> Sicne this command isn't actually Itanium ABI specific, I don't think it
> should make references to Itanium ABI in its C++ class name
>
>
> This seems nitpicking to me, since the entire file is named
> ItaniumABILanguageRuntime.cpp
>
> or help / description
>
>
> I don’t think it does
>
>
> On Fri, Mar 25, 2016 at 4:19 PM Enrico Granata via lldb-commits <
> lldb-commits@lists.llvm.org> wrote:
>
>> Author: enrico
>> Date: Fri Mar 25 18:14:24 2016
>> New Revision: 264474
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=264474&view=rev
>> Log:
>> Add a 'language cplusplus demangle' command. This can be useful to
>> provide a low-friction reproduction for issues with the LLDB demangling of
>> C++ symbols
>>
>> Modified:
>>
>> lldb/trunk/source/Plugins/LanguageRuntime/CPlusPlus/ItaniumABI/ItaniumABILanguageRuntime.cpp
>>
>> Modified:
>> lldb/trunk/source/Plugins/LanguageRuntime/CPlusPlus/ItaniumABI/ItaniumABILanguageRuntime.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/LanguageRuntime/CPlusPlus/ItaniumABI/ItaniumABILanguageRuntime.cpp?rev=264474&r1=264473&r2=264474&view=diff
>>
>> ==
>> ---
>> lldb/trunk/source/Plugins/LanguageRuntime/CPlusPlus/ItaniumABI/ItaniumABILanguageRuntime.cpp
>> (original)
>> +++
>> lldb/trunk/source/Plugins/LanguageRuntime/CPlusPlus/ItaniumABI/ItaniumABILanguageRuntime.cpp
>> Fri Mar 25 18:14:24 2016
>> @@ -13,11 +13,15 @@
>>  #include "lldb/Core/ConstString.h"
>>  #include "lldb/Core/Error.h"
>>  #include "lldb/Core/Log.h"
>> +#include "lldb/Core/Mangled.h"
>>  #include "lldb/Core/Module.h"
>>  #include "lldb/Core/PluginManager.h"
>>  #include "lldb/Core/Scalar.h"
>>  #include "lldb/Core/ValueObject.h"
>>  #include "lldb/Core/ValueObjectMemory.h"
>> +#include "lldb/Interpreter/CommandObject.h"
>> +#include "lldb/Interpreter/CommandObjectMultiword.h"
>> +#include "lldb/Interpreter/CommandReturnObject.h"
>>  #include "lldb/Symbol/ClangASTContext.h"
>>  #include "lldb/Symbol/Symbol.h"
>>  #include "lldb/Symbol/SymbolFile.h"
>> @@ -340,12 +344,96 @@ ItaniumABILanguageRuntime::CreateInstanc
>>  return NULL;
>>  }
>>
>> +class CommandObjectMultiwordItaniumABI_Demangle : public
>> CommandObjectParsed
>> +{
>> +public:
>> +CommandObjectMultiwordItaniumABI_Demangle (CommandInterpreter
>> &interpreter) :
>> +CommandObjectParsed (interpreter,
>> + "demangle",
>> + "Demangle a C++ mangled name.",
>> + "language cplusplus demangle")
>> +{
>> +CommandArgumentEntry arg;
>> +CommandArgumentData index_arg;
>> +
>> +// Define the first (and only) variant of this arg.
>> +index_arg.arg_type = eArgTypeSymbol;
>> +index_arg.arg_repetition = eArgRepeatPlus;
>> +
>> +// There is only one variant this argument could be; put it into
>> the argument entry.
>> +arg.push_back (index_arg);
>> +
>> +// Push the data for the first argument into the m_arguments
>> vector.
>> +m_arguments.push_back (arg);
>> +}
>> +
>> +~CommandObjectMultiwordItaniumABI_Demangle() override = default;
>> +
>> +protected:
>> +bool
>> +DoExecute(Args& command, CommandReturnObject &result) override
>> +{
>> +bool demangled_any = false;
>> +bool error_any = false;
>> +for (size_t i = 0; i < command.GetArgumentCount(); i++)
>> +{
>> +auto arg = command.GetArgumentAtIndex(i);
>> +if (arg && *arg)
>> +{
>> +ConstString mangled_cs(arg);
>> +
>> +// the actual Mangled class should be strict about this,
>> but on the command line
>> +// if you're copying mangled names out of 'nm' on
>> Darwin, the

[Lldb-commits] [lldb] r264478 - Removed LoggingDiagnosticConsumer, an unused class.

[Sean Callanan via lldb-commits]

Author: spyffe
Date: Fri Mar 25 18:51:25 2016
New Revision: 264478

URL: http://llvm.org/viewvc/llvm-project?rev=264478&view=rev
Log:
Removed LoggingDiagnosticConsumer, an unused class.

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=264478&r1=264477&r2=264478&view=diff
==
--- lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp 
(original)
+++ lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp 
Fri Mar 25 18:51:25 2016
@@ -248,56 +248,6 @@ private:
 std::shared_ptr m_passthrough;
 };
 
-class LoggingDiagnosticConsumer : public clang::DiagnosticConsumer
-{
-public:
-LoggingDiagnosticConsumer ()
-{
-m_log = lldb_private::GetLogIfAllCategoriesSet 
(LIBLLDB_LOG_EXPRESSIONS);
-m_passthrough.reset(new clang::TextDiagnosticBuffer);
-}
-
-LoggingDiagnosticConsumer (const 
std::shared_ptr &passthrough)
-{
-m_log = lldb_private::GetLogIfAllCategoriesSet 
(LIBLLDB_LOG_EXPRESSIONS);
-m_passthrough = passthrough;
-}
-
-void HandleDiagnostic (DiagnosticsEngine::Level DiagLevel, const 
clang::Diagnostic &Info)
-{
-if (m_log)
-{
-llvm::SmallVector diag_str;
-Info.FormatDiagnostic(diag_str);
-diag_str.push_back('\0');
-const char *data = diag_str.data();
-m_log->Printf("[clang] COMPILER DIAGNOSTIC: %s", data);
-
-lldbassert(Info.getID() != clang::diag::err_unsupported_ast_node 
&& "'log enable lldb expr' to investigate.");
-}
-
-m_passthrough->HandleDiagnostic(DiagLevel, Info);
-}
-
-void FlushDiagnostics (DiagnosticsEngine &Diags)
-{
-m_passthrough->FlushDiagnostics(Diags);
-}
-
-DiagnosticConsumer *clone (DiagnosticsEngine &Diags) const
-{
-return new LoggingDiagnosticConsumer (m_passthrough);
-}
-
-clang::TextDiagnosticBuffer *GetPassthrough()
-{
-return m_passthrough.get();
-}
-private:
-Log * m_log;
-std::shared_ptr m_passthrough;
-};
-
 
//===--===//
 // Implementation of ClangExpressionParser
 
//===--===//


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

Re: [Lldb-commits] [lldb] r264474 - Add a 'language cplusplus demangle' command. This can be useful to provide a low-friction reproduction for issues with the LLDB demangling of C++ symbols

[Enrico Granata via lldb-commits]

> On Mar 25, 2016, at 4:54 PM, Zachary Turner  wrote:
> 
> Ahh, I didn't notice that our C++ Language Runtime is already called the 
> Itanium ABI Runtime.  Kind of unfortunate.

Not necessarily. The demangling is - indeed - ABI independent (or, rather, 
Mangled.cpp can demangle both MSVC and Itanium manglings); but I imagine 
dynamic type discovery/exception handling would be different on the MSVC ABI. I 
think the name makes sense. Someone would just need to implement a language 
runtime for the MSVC ABI, and then choose which one to load depending on what 
ABI/runtime the process is targeting.

> 
> I wonder how it would work if a process had modules loaded with different 
> languages.  Right now we seem to assume 1 language runtime

per language

> per process, but really it's more like 1 per module.

The language runtimes are actually meant to be per-process since they actually 
respond to dynamic “runtime”-y in nature questions.

The mixing of languages already works today, e.g. we support processes that 
have both Swift and Objective-C code, and questions get dispatched to the 
proper runtime.

> 
> On Fri, Mar 25, 2016 at 4:49 PM Enrico Granata  > wrote:
>> On Mar 25, 2016, at 4:39 PM, Zachary Turner > > wrote:
>> 
>> Any particular reason this has the word Itanium baked into the name of the 
>> class
> 
> The name of the C++ language runtime is ItaniumABI
> I don’t think we have a language runtime for the C++ MSVC ABI
> We can revisit where this command lives at that time
> 
>> and description?
> 
> It shouldn’t - it should be “language cplusplus demangle”, no mention of 
> Itanium
> If you are referring to the description of the plugin overall, that is 
> correct, and should stay as-is
> 
> Again, the hierarchy can be revisited when a C++ MSVC ABI runtime plugin 
> exists.
> 
>>   MSVC doesn't use the Itanium ABI, but but AFAICT from looking at this 
>> code, it should work for MSVC's abi as well.  
>> 
> 
> I have no way to test it, but I would assume so, yes.
> 
>> Sicne this command isn't actually Itanium ABI specific, I don't think it 
>> should make references to Itanium ABI in its C++ class name
> 
> This seems nitpicking to me, since the entire file is named 
> ItaniumABILanguageRuntime.cpp
> 
>> or help / description
> 
> I don’t think it does
> 
>> 
>> On Fri, Mar 25, 2016 at 4:19 PM Enrico Granata via lldb-commits 
>> mailto:lldb-commits@lists.llvm.org>> wrote:
>> Author: enrico
>> Date: Fri Mar 25 18:14:24 2016
>> New Revision: 264474
>> 
>> URL: http://llvm.org/viewvc/llvm-project?rev=264474&view=rev 
>> 
>> Log:
>> Add a 'language cplusplus demangle' command. This can be useful to provide a 
>> low-friction reproduction for issues with the LLDB demangling of C++ symbols
>> 
>> Modified:
>> 
>> lldb/trunk/source/Plugins/LanguageRuntime/CPlusPlus/ItaniumABI/ItaniumABILanguageRuntime.cpp
>> 
>> Modified: 
>> lldb/trunk/source/Plugins/LanguageRuntime/CPlusPlus/ItaniumABI/ItaniumABILanguageRuntime.cpp
>> URL: 
>> http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/LanguageRuntime/CPlusPlus/ItaniumABI/ItaniumABILanguageRuntime.cpp?rev=264474&r1=264473&r2=264474&view=diff
>>  
>> 
>> ==
>> --- 
>> lldb/trunk/source/Plugins/LanguageRuntime/CPlusPlus/ItaniumABI/ItaniumABILanguageRuntime.cpp
>>  (original)
>> +++ 
>> lldb/trunk/source/Plugins/LanguageRuntime/CPlusPlus/ItaniumABI/ItaniumABILanguageRuntime.cpp
>>  Fri Mar 25 18:14:24 2016
>> @@ -13,11 +13,15 @@
>>  #include "lldb/Core/ConstString.h"
>>  #include "lldb/Core/Error.h"
>>  #include "lldb/Core/Log.h"
>> +#include "lldb/Core/Mangled.h"
>>  #include "lldb/Core/Module.h"
>>  #include "lldb/Core/PluginManager.h"
>>  #include "lldb/Core/Scalar.h"
>>  #include "lldb/Core/ValueObject.h"
>>  #include "lldb/Core/ValueObjectMemory.h"
>> +#include "lldb/Interpreter/CommandObject.h"
>> +#include "lldb/Interpreter/CommandObjectMultiword.h"
>> +#include "lldb/Interpreter/CommandReturnObject.h"
>>  #include "lldb/Symbol/ClangASTContext.h"
>>  #include "lldb/Symbol/Symbol.h"
>>  #include "lldb/Symbol/SymbolFile.h"
>> @@ -340,12 +344,96 @@ ItaniumABILanguageRuntime::CreateInstanc
>>  return NULL;
>>  }
>> 
>> +class CommandObjectMultiwordItaniumABI_Demangle : public CommandObjectParsed
>> +{
>> +public:
>> +CommandObjectMultiwordItaniumABI_Demangle (CommandInterpreter 
>> &interpreter) :
>> +CommandObjectParsed (interpreter,
>> + "demangle",
>> + "Demangle a C++ mangled name.",
>> + "language cplusplus demangle")
>> +{
>> +CommandArgumentEntry arg;
>> +CommandArgumentData index_

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

[Zachary Turner via lldb-commits]

Did you get a chance to test this today?

On Fri, Mar 25, 2016 at 9:32 AM Greg Clayton  wrote:

> Will do.
> > On Mar 24, 2016, at 3:30 PM, Zachary Turner  wrote:
> >
> > 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 <
> ztur...@google.com> 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] [lldb] r264483 - Record all translation units with more than one function in them (e.g., blocks).

[Sean Callanan via lldb-commits]

Author: spyffe
Date: Fri Mar 25 19:30:40 2016
New Revision: 264483

URL: http://llvm.org/viewvc/llvm-project?rev=264483&view=rev
Log:
Record all translation units with more than one function in them (e.g., blocks).

Blocks and lambdas have their implementation functions stored in the IR for an
expression.  If we put the block/lambda into a result variable it needs to stay
around.  As a heuristic, remember any execution unit that has more than one
function in it.



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

Modified: 
lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangUserExpression.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangUserExpression.cpp?rev=264483&r1=264482&r2=264483&view=diff
==
--- lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangUserExpression.cpp 
(original)
+++ lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangUserExpression.cpp 
Fri Mar 25 19:30:40 2016
@@ -577,12 +577,18 @@ ClangUserExpression::Parse(DiagnosticMan
 {
 register_execution_unit = true;
 }
+
+// If there is more than one external function in the execution
+// unit, it needs to keep living even if it's not top level, because
+// the result could refer to that function.
+
+if (m_execution_unit_sp->GetJittedFunctions().size() > 1)
+{
+register_execution_unit = true;
+}
 
 if (register_execution_unit)
 {
-// We currently key off there being more than one external 
function in the execution
-// unit to determine whether it needs to live in the process.
-
 llvm::cast(
 
exe_ctx.GetTargetPtr()->GetPersistentExpressionStateForLanguage(m_language))
 ->RegisterExecutionUnit(m_execution_unit_sp);


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

[Lldb-commits] [lldb] r264485 - When we import the definition for a Tagdecl, propagate its completeness too.

[Sean Callanan via lldb-commits]

Author: spyffe
Date: Fri Mar 25 19:37:55 2016
New Revision: 264485

URL: http://llvm.org/viewvc/llvm-project?rev=264485&view=rev
Log:
When we import the definition for a Tagdecl, propagate its completeness too.

The ASTImporter completes the full definiton for a TagDecl in several places,
including the type-deport logic.  When this happens, we should also propagate
the bit that says that this is a complete definition.  This makes (for example)
lambdas callable.



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

Modified: lldb/trunk/source/Symbol/ClangASTImporter.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Symbol/ClangASTImporter.cpp?rev=264485&r1=264484&r2=264485&view=diff
==
--- lldb/trunk/source/Symbol/ClangASTImporter.cpp (original)
+++ lldb/trunk/source/Symbol/ClangASTImporter.cpp Fri Mar 25 19:37:55 2016
@@ -729,8 +729,13 @@ ClangASTImporter::Minion::ExecuteDeportW
 if (TagDecl *tag_decl = dyn_cast(decl))
 {
 if (TagDecl *original_tag_decl = dyn_cast(original_decl))
+{
 if (original_tag_decl->isCompleteDefinition())
+{
 ImportDefinitionTo(tag_decl, original_tag_decl);
+tag_decl->setCompleteDefinition(true);
+}
+}
 
 tag_decl->setHasExternalLexicalStorage(false);
 tag_decl->setHasExternalVisibleStorage(false);
@@ -753,8 +758,6 @@ ClangASTImporter::Minion::ImportDefiniti
 {
 ASTImporter::Imported(from, to);
 
-ObjCInterfaceDecl *to_objc_interface = dyn_cast(to);
-
 /*
 if (to_objc_interface)
 to_objc_interface->startDefinition();
@@ -766,12 +769,20 @@ ClangASTImporter::Minion::ImportDefiniti
 */
 
 ImportDefinition(from);
+
+if (clang::TagDecl *to_tag = dyn_cast(to))
+{
+if (clang::TagDecl *from_tag = dyn_cast(from))
+{
+to_tag->setCompleteDefinition(from_tag->isCompleteDefinition());
+}
+}
  
 // If we're dealing with an Objective-C class, ensure that the inheritance 
has
 // been set up correctly.  The ASTImporter may not do this correctly if 
the 
 // class was originally sourced from symbols.
 
-if (to_objc_interface)
+if (ObjCInterfaceDecl *to_objc_interface = dyn_cast(to))
 {
 do
 {


___
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 51705.
zturner added a comment.

Rebased against ToT


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)
+{
+