[Lldb-commits] [lldb] r253444 - [MIPS][LLDB]Fix TestBreakpointCondition.py for MIPS

[Sagar Thakur via lldb-commits]

Author: slthakur
Date: Wed Nov 18 02:12:34 2015
New Revision: 253444

URL: http://llvm.org/viewvc/llvm-project?rev=253444&view=rev
Log:
[MIPS][LLDB]Fix TestBreakpointCondition.py for MIPS

Patch by Nitesh Jain

Summary: The self.getArchitecture() returns the architecture based on the value 
of -A flag passed to dotest.py script.
There are many possible values for MIPS to this option (like mips32r2, 
mips32r6, mips64, mips64r2, ).
This patch uses re.match(mips,arch) to check if architecture string starts with 
mips.

Subscribers: lldb-commits, mohit.bhakkad, sagar, bhushan, jaydeep
Reviewers: clayborg, ovyalov
Differential: http://reviews.llvm.org/D14493

Modified:

lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/breakpoint_conditions/TestBreakpointConditions.py

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/breakpoint_conditions/TestBreakpointConditions.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/breakpoint_conditions/TestBreakpointConditions.py?rev=253444&r1=253443&r2=253444&view=diff
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/breakpoint_conditions/TestBreakpointConditions.py
 (original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/breakpoint_conditions/TestBreakpointConditions.py
 Wed Nov 18 02:12:34 2015
@@ -103,12 +103,15 @@ class BreakpointConditionsTestCase(TestB
 self.runCmd("breakpoint disable")
 
 self.runCmd("breakpoint set -p Loop")
-if self.getArchitecture() in ['x86_64', 'i386']:
+arch = self.getArchitecture()
+if arch in ['x86_64', 'i386']:
 self.runCmd("breakpoint modify -c ($eax&&i)")
-elif self.getArchitecture() in ['aarch64']:
+elif arch in ['aarch64']:
 self.runCmd("breakpoint modify -c ($x1&&i)")
-elif self.getArchitecture() in ['arm']:
+elif arch in ['arm']:
 self.runCmd("breakpoint modify -c ($r0&&i)")
+elif re.match("mips",arch):
+self.runCmd("breakpoint modify -c ($r2&&i)")
 self.runCmd("run")
 
 self.expect("process status", PROCESS_STOPPED,


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

Re: [Lldb-commits] [PATCH] D14493: [MIPS][LLDB]Fix TestBreakpointCondition.py for MIPS

[Sagar Thakur via lldb-commits]

sagar closed this revision.
sagar added a comment.

Committed in r253444 on behalf of @nitesh.jain


Repository:
  rL LLVM

http://reviews.llvm.org/D14493



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

[Lldb-commits] [lldb] r253445 - [LLDB][MIPS] Fix TestDisassembleBreakpoint.py for MIPS

[Sagar Thakur via lldb-commits]

Author: slthakur
Date: Wed Nov 18 02:18:03 2015
New Revision: 253445

URL: http://llvm.org/viewvc/llvm-project?rev=253445&view=rev
Log:
[LLDB][MIPS] Fix TestDisassembleBreakpoint.py for MIPS

Patch by Nitesh Jain

Summary: The break is opcode for breakpoint instruction.

Subscribers: lldb-commits, mohit.bhakkad, sagar, bhushan
Reviewers: clayborg, ovyalov, jaydeep
Differential: http://reviews.llvm.org/D14634

Modified:

lldb/trunk/packages/Python/lldbsuite/test/functionalities/disassembly/TestDisassembleBreakpoint.py

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/disassembly/TestDisassembleBreakpoint.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/disassembly/TestDisassembleBreakpoint.py?rev=253445&r1=253444&r2=253445&view=diff
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/disassembly/TestDisassembleBreakpoint.py
 (original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/disassembly/TestDisassembleBreakpoint.py
 Wed Nov 18 02:18:03 2015
@@ -32,12 +32,16 @@ class DisassemblyTestCase(TestBase):
 disassembly = self.res.GetOutput()
 
 # ARCH, if not specified, defaults to x86_64.
-if self.getArchitecture() in ["", 'x86_64', 'i386', 'i686']:
+arch = self.getArchitecture()
+if arch in ["", 'x86_64', 'i386', 'i686']:
 breakpoint_opcodes = ["int3"]
 instructions = [' mov', ' addl ', 'ret']
-elif self.getArchitecture() in ["arm", "aarch64"]:
+elif arch in ["arm", "aarch64"]:
 breakpoint_opcodes = ["brk", "udf"]
 instructions = [' add ', ' ldr ', ' str ']
+elif re.match("mips" , arch):
+breakpoint_opcodes = ["break"]
+instructions = ['lw', 'sw', 'jr']
 else:
 # TODO please add your arch here
 self.fail('unimplemented for arch = 
"{arch}"'.format(arch=self.getArchitecture()))


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

Re: [Lldb-commits] [PATCH] D14634: [LLDB][MIPS] Fix TestDisassembleBreakpoint.py for MIPS

[Sagar Thakur via lldb-commits]

sagar added a comment.

Committed in r253445 on behalf of @nitesh.jain


Repository:
  rL LLVM

http://reviews.llvm.org/D14634



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

[Lldb-commits] [lldb] r253448 - prepare_bindings.py: enable static bindings

[Todd Fiala via lldb-commits]

Author: tfiala
Date: Wed Nov 18 02:52:33 2015
New Revision: 253448

URL: http://llvm.org/viewvc/llvm-project?rev=253448&view=rev
Log:
prepare_bindings.py: enable static bindings

Added a new flag, --allow-static-binding.  When specified,
if (and only if) the swig binary cannot be found, then the
LLDBWrapPython.cpp and lldb.py from the
scripts/Python/{static-binding-dir} are copied into the place where
swig would have generated them.

{static-binding-dir} defaults to static-binding, and can be
overridden with the --static-binding-dir command line argument.

The static bindings checked in are from r253424.

Added:
lldb/trunk/scripts/Python/static-binding/
lldb/trunk/scripts/Python/static-binding/LLDBWrapPython.cpp
lldb/trunk/scripts/Python/static-binding/lldb.py
Modified:
lldb/trunk/lldb.xcodeproj/project.pbxproj
lldb/trunk/scripts/Python/prepare_binding_Python.py
lldb/trunk/scripts/prepare_bindings.py

Modified: lldb/trunk/lldb.xcodeproj/project.pbxproj
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/lldb.xcodeproj/project.pbxproj?rev=253448&r1=253447&r2=253448&view=diff
==
--- lldb/trunk/lldb.xcodeproj/project.pbxproj (original)
+++ lldb/trunk/lldb.xcodeproj/project.pbxproj Wed Nov 18 02:52:33 2015
@@ -6226,7 +6226,7 @@
);
runOnlyForDeploymentPostprocessing = 0;
shellPath = /bin/bash;
-   shellScript = "/usr/bin/python 
$SRCROOT/scripts/prepare_bindings.py --find-swig --framework --src-root 
$SRCROOT --target-dir $TARGET_BUILD_DIR --config-build-dir 
$CONFIGURATION_BUILD_DIR";
+   shellScript = "/usr/bin/python 
$SRCROOT/scripts/prepare_bindings.py --find-swig --framework --src-root 
$SRCROOT --target-dir $TARGET_BUILD_DIR --config-build-dir 
$CONFIGURATION_BUILD_DIR --allow-static-binding";
};
4959511A1A1ACE9500F6F8FC /* Install Clang compiler headers */ = 
{
isa = PBXShellScriptBuildPhase;

Modified: lldb/trunk/scripts/Python/prepare_binding_Python.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/scripts/Python/prepare_binding_Python.py?rev=253448&r1=253447&r2=253448&view=diff
==
--- lldb/trunk/scripts/Python/prepare_binding_Python.py (original)
+++ lldb/trunk/scripts/Python/prepare_binding_Python.py Wed Nov 18 02:52:33 2015
@@ -251,6 +251,42 @@ def do_swig_rebuild(options, dependency_
 sys.exit(-10)
 
 
+def copy_static_bindings(options, config_build_dir, settings):
+"""Copies the static Python bindings over to the build dir.
+"""
+
+# Copy the LLDBWrapPython.cpp C++ binding file impl over.
+lldb_wrap_python_src_path = os.path.join(
+options.src_root,
+"scripts",
+"Python",
+options.static_binding_dir,
+"LLDBWrapPython.cpp")
+if not os.path.exists(lldb_wrap_python_src_path):
+logging.error(
+"failed to find static Python binding .cpp file at '%s'",
+lldb_wrap_python_src_path)
+sys.exit(-12)
+shutil.copyfile(lldb_wrap_python_src_path, settings.output_file)
+
+# Copy the lldb.py impl over.
+lldb_py_src_path = os.path.join(
+options.src_root,
+"scripts",
+"Python",
+options.static_binding_dir,
+"lldb.py")
+if not os.path.exists(lldb_py_src_path):
+logging.error(
+"failed to find static Python binding .py file at '%s'",
+lldb_py_src_path)
+sys.exit(-13)
+lldb_py_dest_path = os.path.join(
+os.path.dirname(settings.output_file),
+"lldb.py")
+shutil.copyfile(lldb_py_src_path, lldb_py_dest_path)
+
+
 def run_python_script(script_and_args):
 """Runs a python script, logging appropriately.
 
@@ -418,14 +454,21 @@ def main(options):
 "Skipping Python binding generation: everything is up to date")
 return
 
-# Generate the Python binding with swig.
-logging.info("Python binding is out of date, regenerating")
-do_swig_rebuild(options, dependency_file, config_build_dir, settings)
-if options.generate_dependency_file:
-return
+# Generate the Python binding with swig, or use the static bindings if no 
swig.
+if not options.swig_executable or not 
os.path.exists(options.swig_executable):
+# Copy over the static bindings.  We capture the the modified (i.e. 
post-processed)
+# binding, so we don't do the modify step here - the modifications have
+# already been applied.
+copy_static_bindings(options, config_build_dir, settings)
+else:
+# Generate the bindings with swig.
+logging.info("Python binding is out of date, regenerating")
+do_swig_rebuild(options, dependency_file, config_build_dir, settings)
+if options.generate_dep

Re: [Lldb-commits] [lldb] r253317 - Add Pythonic language binding wrapper generation script.

[Todd Fiala via lldb-commits]

Usage of static bindings for the prepare_bindings.py script went in here:
r253448.

Only Xcode provides the flag to use it.  The commit description indicates
how it works in this incarnation.  Essentially it only uses the static
Python binding if and only if a swig isn't specified or cannot be found.

I'll be testing this on Ubuntu 14.04 and 15.10 in the morning.  Once I have
that working, I'll provide a cmake flag to vector over to it, defaulting to
not do so.

-Todd


On Tue, Nov 17, 2015 at 8:12 PM, Todd Fiala  wrote:

> > that comes out of python
>
> that comes out of swig, rather (i.e. the binding generation output).
>
> On Tue, Nov 17, 2015 at 8:03 PM, Todd Fiala  wrote:
>
>> Nothing concrete at the moment; however, it could be interesting to look
>> at the clang community and see what could be done for llvm-based language
>> implementations.  The angle that I think would be interesting would be if
>> we can generate bindings more effectively based on the in-depth
>> understanding of the language that is afforded by languages built on top of
>> LLVM.  This is probably less interesting for Python (particularly since we
>> have a functioning solution) and more interesting for languages built on
>> LLVM or clang.
>>
>> Honestly, though, I haven't spent much time on that.
>>
>> For the time being, I am going to not change the path for everyone on
>> swig, and only use a static binding if swig cannot be found.  This will be
>> minimal impact for everyone and doesn't interfere with anyone using a
>> specific version of swig.  We can revisit larger questions about
>> who/what/when on static bindings after we gain some experience with
>> enabling them for those who don't have swig.  We can review and adjust
>> based on our collective experience.  The two files this seems like it will
>> be are the LLDBWrapPython.cpp and the lldb.py file that comes out of
>> python.  I hope to have this working in the next day or so.
>>
>>
>> On Tue, Nov 17, 2015 at 7:26 PM, Bruce Mitchener <
>> bruce.mitche...@gmail.com> wrote:
>>
>>> Stepping one step back further in the thread ...
>>>
>>> On Wed, Nov 18, 2015 at 8:35 AM, Zachary Turner via lldb-commits <
>>> lldb-commits@lists.llvm.org> wrote:
>>>
 Moving this back over to the list since I'm sure others have some input
 here.  Also +lldb-dev since it has more visibility than lldb-commits.


 On Tue, Nov 17, 2015 at 11:25 AM Zachary Turner 
 wrote:

> On Tue, Nov 17, 2015 at 8:18 AM Todd Fiala 
> wrote:
>
>> Breaking out the binding generation into a separate step will also be
>> important for a couple reasons:
>>
>> * (from before) I want to eliminate the requirement for the vast
>> majority of the builds to have a swig on their system, and
>>
>> * (not stated before) we'd like to move away from swig for binding
>> generation at some point.
>>
>
>>> Is there any discussion or thoughts about what the options would be for
>>> moving away from swig?
>>>
>>>  - Bruce
>>>
>>>
>>
>>
>>
>> --
>> -Todd
>>
>
>
>
> --
> -Todd
>



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

Re: [Lldb-commits] [lldb] r253317 - Add Pythonic language binding wrapper generation script.

[Zachary Turner via lldb-commits]

On Tue, Nov 17, 2015 at 8:03 PM Todd Fiala  wrote:

> Nothing concrete at the moment; however, it could be interesting to look
> at the clang community and see what could be done for llvm-based language
> implementations.  The angle that I think would be interesting would be if
> we can generate bindings more effectively based on the in-depth
> understanding of the language that is afforded by languages built on top of
> LLVM.  This is probably less interesting for Python (particularly since we
> have a functioning solution) and more interesting for languages built on
> LLVM or clang.
>
> Honestly, though, I haven't spent much time on that.
>
> For the time being, I am going to not change the path for everyone on
> swig, and only use a static binding if swig cannot be found.  This will be
> minimal impact for everyone and doesn't interfere with anyone using a
> specific version of swig.  We can revisit larger questions about
> who/what/when on static bindings after we gain some experience with
> enabling them for those who don't have swig.  We can review and adjust
> based on our collective experience.  The two files this seems like it will
> be are the LLDBWrapPython.cpp and the lldb.py file that comes out of
> python.  I hope to have this working in the next day or so.
>
To try this another way, I really would like to voice my opinion very very
strongly for moving away from having different ways of doing things for
different platforms / build configurations / etc unless it is *required* to
support a hard requirement of someone's environment.

Here's our current configuration matrix.

Platforms: Windows, Linux, FreeBSD, Darwin, NetBSD, Other(?)
Build Systems: CMake, Xcode
SWIG version: 1.3x, latest
Python version: None, 2.7, 3.x (in progress)
SWIG Binding Generation: on-the-fly, static (proposed)

In all of these cases (except the proposed), the matrix choices are
justifiable because they are there to support a hard requirement of
someone's environment, and I do not think we should grow for anything that
is not also a hard requirement of someone's environment.  We definitely
should not grow it out of convenience, and *especially* not if it's only a
minor convenience.  So I still am looking for a clear answer regarding what
problem this is solving.  Is not having a swig binary on every machine a
hard requirement?  You said

> We can revisit larger questions about who/what/when on static bindings
after we gain some experience with enabling them *for those who don't have
swig*"

And my question is, who doesn't have swig?  Maybe there is a legitimate use
case, I just want to understand what that is before we add more different
ways of building.

I mentioned earlier that one way there would be a definite tangible benefit
is if we could use these static bindings in conjunction with a swig bot
that would automatically generate swig on a remote server and send you back
the result.  This way we could remove one item from the configuration
matrix, which I think we all agree is a good thing based on the fact that
the original idea was to get everyone on 1.3x (which isn't possible since
it doesn't work well with Python 3.5).  Compare:

Platforms: Windows, Linux, FreeBSD, OSX, NetBSD, Other(?)
Build Systems: CMake, Xcode
SWIG version: 1.3x, latest
Python version: None, 2.7, 3.x (in progress)
SWIG Binding Generation: on-the-fly, static

with

Platforms: Windows, Linux, FreeBSD, OSX, NetBSD, Other(?)
Build Systems: CMake, Xcode
Python version: None, 2.7, 3.x (in progress)

The latter is much better, right?  Can we discuss whether this swig server
is a viable solution for getting to a single system that works for
everyone?  Again, I'm willing to do the brunt of the work getting it up and
running if it is (I can probably reuse the portion of work you've already
done related to running swig on the input files)

If the goal is just some kind of cleanup where it would be nice to not have
to install swig, I'm specifically arguing against that, because I don't
think that's a strong enough case to add one item to the configuration
matrix.

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

Re: [Lldb-commits] [lldb-dev] [lldb] r253317 - Add Pythonic language binding wrapper generation script.

[Pavel Labath via lldb-commits]

On 18 November 2015 at 09:02, Zachary Turner via lldb-dev
 wrote:
> On Tue, Nov 17, 2015 at 8:03 PM Todd Fiala  wrote:
>>
>> Nothing concrete at the moment; however, it could be interesting to look
>> at the clang community and see what could be done for llvm-based language
>> implementations.  The angle that I think would be interesting would be if we
>> can generate bindings more effectively based on the in-depth understanding
>> of the language that is afforded by languages built on top of LLVM.  This is
>> probably less interesting for Python (particularly since we have a
>> functioning solution) and more interesting for languages built on LLVM or
>> clang.
>>
>> Honestly, though, I haven't spent much time on that.
>>
>> For the time being, I am going to not change the path for everyone on
>> swig, and only use a static binding if swig cannot be found.  This will be
>> minimal impact for everyone and doesn't interfere with anyone using a
>> specific version of swig.  We can revisit larger questions about
>> who/what/when on static bindings after we gain some experience with enabling
>> them for those who don't have swig.  We can review and adjust based on our
>> collective experience.  The two files this seems like it will be are the
>> LLDBWrapPython.cpp and the lldb.py file that comes out of python.  I hope to
>> have this working in the next day or so.
>
> To try this another way, I really would like to voice my opinion very very
> strongly for moving away from having different ways of doing things for
> different platforms / build configurations / etc unless it is *required* to
> support a hard requirement of someone's environment.
>
> Here's our current configuration matrix.
>
> Platforms: Windows, Linux, FreeBSD, Darwin, NetBSD, Other(?)
> Build Systems: CMake, Xcode
> SWIG version: 1.3x, latest
> Python version: None, 2.7, 3.x (in progress)
> SWIG Binding Generation: on-the-fly, static (proposed)
>
> In all of these cases (except the proposed), the matrix choices are
> justifiable because they are there to support a hard requirement of
> someone's environment, and I do not think we should grow for anything that
> is not also a hard requirement of someone's environment.  We definitely
> should not grow it out of convenience, and *especially* not if it's only a
> minor convenience.  So I still am looking for a clear answer regarding what
> problem this is solving.  Is not having a swig binary on every machine a
> hard requirement?

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

Re: [Lldb-commits] [PATCH] D14633: [LLDB][MIPS] Clear bug 25194 - LLDB-Server Assertion raised when single stepping on MIPS

[Sagar Thakur via lldb-commits]

sagar added a comment.

Hi,

@tberghammer : For both mips32 and mips64 big endian 'T' packet response 
contains the register values in target byte order only. But for mips32 big 
endian when we set the value of the register in RegisterValue using 
RegisterValue::SetUInt() the upper half of the container in RegisterValue 
contains zero value and the lower half contains the actual value. And when we 
fetch a pointer to the container in RegisterValue using 
RegisterValue::GetBytes() we get the start address of upper half of the 
container. Therefore while constructing 'T' packet response the function 
AppendHexValue() in GDBRemoteCommunicationServerLLGS.cpp called from 
WriteRegisterValueInHexFixedWidth() will read only the next 4 bytes it sees 
which are all zero. Therefore we get zero values for all registers at the 
client side:

> <   5> send packet: $?#3f

> < 680> read packet:

> $T17thread:774d;name:step_32eb.elf;threads:774d;jstopinfo:5b7b226e616d65223a22737465705f333265622e656c66222c22726561736f6e223a227369676e616c222c227369676e616c223a32332c22746964223a33303534317d5d;

> 00:;01:;02:;03:;04:;05:;06:;07:;08:;09:;

> 0a:;0b:;0c:;0d:;0e:;0f:;10:;11:;12:;13:;

> 14:;15:;16:;17:;18:;19:;1a:;1b:;1c:;1d:;

> 1e:;1f:;20:;21:;22:;23:;24:;25:;26:;reason:signal;#47


@clayborg: After this change will submit a separate patch to read all GPRs in a 
single call for once and then extract the register value as needed in the MIPS 
register context.

Regards,
Sagar


Repository:
  rL LLVM

http://reviews.llvm.org/D14633



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

[Lldb-commits] [lldb] r253455 - Revert 2 commits breaking the MSVC build

[Tamas Berghammer via lldb-commits]

Author: tberghammer
Date: Wed Nov 18 06:11:34 2015
New Revision: 253455

URL: http://llvm.org/viewvc/llvm-project?rev=253455&view=rev
Log:
Revert 2 commits breaking the MSVC build

Revert "Remove a few vestigial typedefs from the old world"
This reverts commit 05872cda2a00fbd988c4fc761b1f87fe9edce224.

Revert "Cleanup the type X list commands to use the new ForEach goodness"
This reverts commit 85b1d83819a22cdc9ef12f58fd4fa92b473a4f81.

Modified:
lldb/trunk/include/lldb/DataFormatters/DataVisualization.h
lldb/trunk/include/lldb/DataFormatters/FormatManager.h
lldb/trunk/include/lldb/DataFormatters/FormattersContainer.h
lldb/trunk/include/lldb/DataFormatters/TypeCategory.h
lldb/trunk/include/lldb/DataFormatters/TypeCategoryMap.h
lldb/trunk/include/lldb/DataFormatters/TypeFormat.h
lldb/trunk/include/lldb/DataFormatters/TypeSummary.h
lldb/trunk/include/lldb/DataFormatters/TypeSynthetic.h
lldb/trunk/include/lldb/DataFormatters/TypeValidator.h
lldb/trunk/source/API/SBTypeCategory.cpp
lldb/trunk/source/Commands/CommandObjectType.cpp
lldb/trunk/source/DataFormatters/DataVisualization.cpp
lldb/trunk/source/DataFormatters/FormatManager.cpp
lldb/trunk/source/DataFormatters/TypeCategoryMap.cpp

Modified: lldb/trunk/include/lldb/DataFormatters/DataVisualization.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/DataFormatters/DataVisualization.h?rev=253455&r1=253454&r2=253455&view=diff
==
--- lldb/trunk/include/lldb/DataFormatters/DataVisualization.h (original)
+++ lldb/trunk/include/lldb/DataFormatters/DataVisualization.h Wed Nov 18 
06:11:34 2015
@@ -101,7 +101,7 @@ public:
 Clear ();
 
 static void
-ForEach (std::function callback);
+LoopThrough (TypeSummaryImpl::SummaryCallback callback, void* 
callback_baton);
 
 static uint32_t
 GetCount ();
@@ -158,6 +158,9 @@ public:
 DisableStar ();
 
 static void
+LoopThrough (FormatManager::CategoryCallback callback, void* 
callback_baton);
+
+static void
 ForEach (TypeCategoryMap::ForEachCallback callback);
 
 static uint32_t

Modified: lldb/trunk/include/lldb/DataFormatters/FormatManager.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/DataFormatters/FormatManager.h?rev=253455&r1=253454&r2=253455&view=diff
==
--- lldb/trunk/include/lldb/DataFormatters/FormatManager.h (original)
+++ lldb/trunk/include/lldb/DataFormatters/FormatManager.h Wed Nov 18 06:11:34 
2015
@@ -43,6 +43,8 @@ class FormatManager : public IFormatChan
 public:
 typedef std::map 
LanguageCategories;
 
+typedef TypeCategoryMap::CallbackType CategoryCallback;
+
 FormatManager();
 
 ~FormatManager() override = default;
@@ -138,6 +140,9 @@ public:
 }
 
 void
+LoopThroughCategories (CategoryCallback callback, void* param);
+
+void
 ForEachCategory (TypeCategoryMap::ForEachCallback callback);
 
 lldb::TypeCategoryImplSP

Modified: lldb/trunk/include/lldb/DataFormatters/FormattersContainer.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/DataFormatters/FormattersContainer.h?rev=253455&r1=253454&r2=253455&view=diff
==
--- lldb/trunk/include/lldb/DataFormatters/FormattersContainer.h (original)
+++ lldb/trunk/include/lldb/DataFormatters/FormattersContainer.h Wed Nov 18 
06:11:34 2015
@@ -80,6 +80,8 @@ public:
 typedef typename ValueType::SharedPointer ValueSP;
 typedef std::map MapType;
 typedef typename MapType::iterator MapIterator;
+typedef std::function CallbackType;
+
 typedef std::function ForEachCallback;
 
 FormatMap(IFormatChangeListener* lst) :
@@ -139,6 +141,22 @@ public:
 }
 
 void
+LoopThrough (CallbackType callback, void* param)
+{
+if (callback)
+{
+Mutex::Locker locker(m_map_mutex);
+MapIterator pos, end = m_map.end();
+for (pos = m_map.begin(); pos != end; pos++)
+{
+KeyType type = pos->first;
+if (!callback(param, type, pos->second))
+break;
+}
+}
+}
+
+void
 ForEach (ForEachCallback callback)
 {
 if (callback)
@@ -224,6 +242,7 @@ public:
 typedef typename MapType::iterator MapIterator;
 typedef typename MapType::key_type MapKeyType;
 typedef typename MapType::mapped_type MapValueType;
+typedef typename BackEndType::CallbackType CallbackType;
 typedef typename BackEndType::ForEachCallback ForEachCallback;
 typedef typename std::shared_ptr > 
SharedPointer;
 
@@ -297,6 +316,12 @@ public:
 }
 
 void
+LoopThrough (Callbac

Re: [Lldb-commits] [PATCH] D13350: [lldb] Fix evaluation of qualified global variables

[Eugene Leviant via lldb-commits]

evgeny777 updated this revision to Diff 40497.
evgeny777 added a comment.

Hi folks!

The clang patch has been landed. I've added test cases, so please look at the 
new patch. Thanks


http://reviews.llvm.org/D13350

Files:
  packages/Python/lldbsuite/test/lang/cpp/namespace/TestNamespace.py
  packages/Python/lldbsuite/test/lang/cpp/namespace/main.cpp
  packages/Python/lldbsuite/test/lang/cpp/nsimport/TestCppNsImport.py
  source/Plugins/ExpressionParser/Clang/ClangExpressionDeclMap.cpp

Index: source/Plugins/ExpressionParser/Clang/ClangExpressionDeclMap.cpp
===
--- source/Plugins/ExpressionParser/Clang/ClangExpressionDeclMap.cpp
+++ source/Plugins/ExpressionParser/Clang/ClangExpressionDeclMap.cpp
@@ -1337,10 +1337,17 @@
 
 if (frame && !namespace_decl)
 {
-CompilerDeclContext compiler_decl_context = sym_ctx.block != nullptr ? sym_ctx.block->GetDeclContext() : CompilerDeclContext();
-
+CompilerDeclContext compiler_decl_context = sym_ctx.block != nullptr ? sym_ctx.block->GetDeclContext() : CompilerDeclContext();
 if (compiler_decl_context)
-{
+{
+if (context.m_decl_context->shouldUseQualifiedLookup())
+{
+// We're looking for global variable, so we need root DeclContext
+clang::DeclContext* dc = (clang::DeclContext*)compiler_decl_context.GetOpaqueDeclContext();
+while (dc->getParent())
+dc = dc->getParent();
+compiler_decl_context.SetDeclContext(compiler_decl_context.GetTypeSystem(), dc);
+}
 // Make sure that the variables are parsed so that we have the declarations
 VariableListSP vars = frame->GetInScopeVariableList(true);
 for (size_t i = 0; i < vars->GetSize(); i++)
Index: packages/Python/lldbsuite/test/lang/cpp/nsimport/TestCppNsImport.py
===
--- packages/Python/lldbsuite/test/lang/cpp/nsimport/TestCppNsImport.py
+++ packages/Python/lldbsuite/test/lang/cpp/nsimport/TestCppNsImport.py
@@ -72,9 +72,8 @@
 test_result = frame.EvaluateExpression("not_imported")
 self.assertTrue(test_result.IsValid() and test_result.GetValueAsSigned() == 35, "not_imported = 35")
 
-# Currently there is no way to distinguish between "::imported" and "imported" in ClangExpressionDeclMap so this fails
-#test_result = frame.EvaluateExpression("::imported")
-#self.assertTrue(test_result.IsValid() and test_result.GetValueAsSigned() == 89, "::imported = 89")
+test_result = frame.EvaluateExpression("::imported")
+self.assertTrue(test_result.IsValid() and test_result.GetValueAsSigned() == 89, "::imported = 89")
 
 test_result = frame.EvaluateExpression("Imported::imported")
 self.assertTrue(test_result.IsValid() and test_result.GetValueAsSigned() == 99, "Imported::imported = 99")
Index: packages/Python/lldbsuite/test/lang/cpp/namespace/main.cpp
===
--- packages/Python/lldbsuite/test/lang/cpp/namespace/main.cpp
+++ packages/Python/lldbsuite/test/lang/cpp/namespace/main.cpp
@@ -9,6 +9,8 @@
 
 #include 
 
+int gvar = 10;
+
 namespace {
 typedef unsigned int my_uint_t;
 int i; // Find the line number for anonymous namespace variable i.
@@ -74,18 +76,25 @@
 
 namespace ns1 {
 int value = 100;
+int gvar = 20;
 }
 
 namespace ns2 {
 int value = 200;
 }
 
 #include 
 void test_namespace_scopes() {
+int gvar = 1;
 do {
 using namespace ns1;
 printf("ns1::value = %d\n", value); // Evaluate ns1::value
 } while(0);
+
+do {
+using namespace ns1;
+printf("gvar=%d, ns1::gvar=%d, ::gvar=%d\n", gvar, ns1::gvar, ::gvar);
+} while(0);
 
 do {
 using namespace ns2;
Index: packages/Python/lldbsuite/test/lang/cpp/namespace/TestNamespace.py
===
--- packages/Python/lldbsuite/test/lang/cpp/namespace/TestNamespace.py
+++ packages/Python/lldbsuite/test/lang/cpp/namespace/TestNamespace.py
@@ -51,10 +51,14 @@
 self.runToBkpt("run")
 # Evaluate ns1::value
 self.expect("expression -- value", startstr = "(int) $0 = 100")
-
+# Evaluate gvar in different scopes
+self.expect("expression -- gvar", startstr = "(int) $1 = 1")
+self.expect("expression -- ns1::gvar", startstr = "(int) $2 = 20")
+self.expect("expression -- ::gvar", startstr = "(int) $3 = 10")
+
 self.runToBkpt("continue")
 # Evaluate ns2::value
-self.expect("expression -- value", startstr = "(int) $1 = 200")
+self.expect("expression -- value", startstr = "(int) $4 = 200")
 
 self.runToBkpt("

Re: [Lldb-commits] [PATCH] D14633: [LLDB][MIPS] Clear bug 25194 - LLDB-Server Assertion raised when single stepping on MIPS

[Tamas Berghammer via lldb-commits]

tberghammer added a comment.

Hi,

I checked out the implementation of RegisterValue and this is my understanding 
what is happening:

- When we call RegisterValue::SetUInt it will be creating a 32bit unsigned 
llvm::APInt
- The llvm::APInt will store the data in a uint64_t
- Calling RegisterValue::GetBytes() will return with APInt::getRawData() what 
will return a pointer to the uint64_t

The problem is that the pointer returned from getRawData isn't pointing to the 
32bit data of the underlying storage but it points to the full 64bit storage 
slot.

I don't know what is the best solution in the current situation but using 
SetBytes directly and managing the endianness by hand looks like a bad solution 
for me because then we practically say that SetUInt (and all other similar 
functions) are not big endian compatible (what should be fixed or they should 
be removed).

I see 2 option at the moment but none of them is perfect:

- Add a new function to llvm::APInt what returns the pointer to the actual data 
in case of both endian (possibly the best option)
- Don't use llvm::APInt inside Scalar as we don't need most of it's 
functionality and just have a big enough byte buffer in RegisterValue

Cheers,
Tamas


Repository:
  rL LLVM

http://reviews.llvm.org/D14633



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

Re: [Lldb-commits] [PATCH] D13350: [lldb] Fix evaluation of qualified global variables

[Eugene Leviant via lldb-commits]

evgeny777 updated this revision to Diff 40508.
evgeny777 added a comment.

Minor code cleanups


http://reviews.llvm.org/D13350

Files:
  packages/Python/lldbsuite/test/lang/cpp/namespace/TestNamespace.py
  packages/Python/lldbsuite/test/lang/cpp/namespace/main.cpp
  packages/Python/lldbsuite/test/lang/cpp/nsimport/TestCppNsImport.py
  source/Plugins/ExpressionParser/Clang/ClangExpressionDeclMap.cpp

Index: source/Plugins/ExpressionParser/Clang/ClangExpressionDeclMap.cpp
===
--- source/Plugins/ExpressionParser/Clang/ClangExpressionDeclMap.cpp
+++ source/Plugins/ExpressionParser/Clang/ClangExpressionDeclMap.cpp
@@ -1337,10 +1337,17 @@
 
 if (frame && !namespace_decl)
 {
-CompilerDeclContext compiler_decl_context = sym_ctx.block != nullptr ? sym_ctx.block->GetDeclContext() : CompilerDeclContext();
-
+CompilerDeclContext compiler_decl_context = sym_ctx.block != nullptr ? sym_ctx.block->GetDeclContext() : CompilerDeclContext();
 if (compiler_decl_context)
-{
+{
+if (context.m_decl_context->shouldUseQualifiedLookup())
+{
+// We're looking for global variable, so we need root DeclContext
+clang::DeclContext* dc = (clang::DeclContext*)compiler_decl_context.GetOpaqueDeclContext();
+while (dc->getParent())
+dc = dc->getParent();
+compiler_decl_context.SetDeclContext(compiler_decl_context.GetTypeSystem(), dc);
+}
 // Make sure that the variables are parsed so that we have the declarations
 VariableListSP vars = frame->GetInScopeVariableList(true);
 for (size_t i = 0; i < vars->GetSize(); i++)
Index: packages/Python/lldbsuite/test/lang/cpp/nsimport/TestCppNsImport.py
===
--- packages/Python/lldbsuite/test/lang/cpp/nsimport/TestCppNsImport.py
+++ packages/Python/lldbsuite/test/lang/cpp/nsimport/TestCppNsImport.py
@@ -72,9 +72,8 @@
 test_result = frame.EvaluateExpression("not_imported")
 self.assertTrue(test_result.IsValid() and test_result.GetValueAsSigned() == 35, "not_imported = 35")
 
-# Currently there is no way to distinguish between "::imported" and "imported" in ClangExpressionDeclMap so this fails
-#test_result = frame.EvaluateExpression("::imported")
-#self.assertTrue(test_result.IsValid() and test_result.GetValueAsSigned() == 89, "::imported = 89")
+test_result = frame.EvaluateExpression("::imported")
+self.assertTrue(test_result.IsValid() and test_result.GetValueAsSigned() == 89, "::imported = 89")
 
 test_result = frame.EvaluateExpression("Imported::imported")
 self.assertTrue(test_result.IsValid() and test_result.GetValueAsSigned() == 99, "Imported::imported = 99")
Index: packages/Python/lldbsuite/test/lang/cpp/namespace/main.cpp
===
--- packages/Python/lldbsuite/test/lang/cpp/namespace/main.cpp
+++ packages/Python/lldbsuite/test/lang/cpp/namespace/main.cpp
@@ -9,6 +9,8 @@
 
 #include 
 
+int gvar = 10;
+
 namespace {
 typedef unsigned int my_uint_t;
 int i; // Find the line number for anonymous namespace variable i.
@@ -74,19 +76,21 @@
 
 namespace ns1 {
 int value = 100;
+int gvar = 20;
 }
 
 namespace ns2 {
 int value = 200;
 }
 
 #include 
 void test_namespace_scopes() {
+int gvar = 1;
 do {
 using namespace ns1;
-printf("ns1::value = %d\n", value); // Evaluate ns1::value
+printf("ns1::value = %d, gvar=%d, ::gvar=%d\n", value, gvar, ::gvar); // Evaluate ns1::value and gvar
 } while(0);
-
+
 do {
 using namespace ns2;
 printf("ns2::value = %d\n", value); // Evaluate ns2::value
Index: packages/Python/lldbsuite/test/lang/cpp/namespace/TestNamespace.py
===
--- packages/Python/lldbsuite/test/lang/cpp/namespace/TestNamespace.py
+++ packages/Python/lldbsuite/test/lang/cpp/namespace/TestNamespace.py
@@ -27,7 +27,7 @@
 self.line_break = line_number('main.cpp',
 '// Set break point at this line.')
 # Break inside do {} while and evaluate value
-self.line_break_ns1 = line_number('main.cpp', '// Evaluate ns1::value')
+self.line_break_ns1 = line_number('main.cpp', '// Evaluate ns1::value and gvar')
 self.line_break_ns2 = line_number('main.cpp', '// Evaluate ns2::value')
 
 def runToBkpt(self, command):
@@ -51,10 +51,14 @@
 self.runToBkpt("run")
 # Evaluate ns1::value
 self.expect("expression -- value", startstr = "(int) $0 = 100")
-
+# Evaluate gvar in different scopes
+self.expect("expression -- gvar", startstr = "(i

[Lldb-commits] [lldb] r253478 - Switched cmake build from using buildSwigWrapperClases.py to the cleaned up version.

[Todd Fiala via lldb-commits]

Author: tfiala
Date: Wed Nov 18 11:36:15 2015
New Revision: 253478

URL: http://llvm.org/viewvc/llvm-project?rev=253478&view=rev
Log:
Switched cmake build from using buildSwigWrapperClases.py to the cleaned up 
version.

This change does not introduce static bindings.  It is simply using
the pylinted cleaned up code in prepare_bindings.py.

If this breaks anyting, I'll revert immediately and figure out what
needs to be addressed.  I'm looking to wrap up
the cleanup aspect of the code change (pylinted, removal of code that
implements existing python stdlib code, fixes for Xcode adoption, etc.).

Modified:
lldb/trunk/CMakeLists.txt
lldb/trunk/scripts/CMakeLists.txt

Modified: lldb/trunk/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/CMakeLists.txt?rev=253478&r1=253477&r2=253478&view=diff
==
--- lldb/trunk/CMakeLists.txt (original)
+++ lldb/trunk/CMakeLists.txt Wed Nov 18 11:36:15 2015
@@ -33,6 +33,7 @@ if (NOT LLDB_DISABLE_PYTHON)
 add_custom_target( finish_swig ALL
 COMMAND ${PYTHON_EXECUTABLE} 
${CMAKE_CURRENT_SOURCE_DIR}/scripts/finishSwigWrapperClasses.py 
"--srcRoot=${LLDB_SOURCE_DIR}" 
"--targetDir=${CMAKE_CURRENT_BINARY_DIR}/scripts" 
"--cfgBldDir=${CMAKE_CURRENT_BINARY_DIR}/scripts" 
"--prefix=${CMAKE_BINARY_DIR}" "--cmakeBuildConfiguration=${CMAKE_CFG_INTDIR}" 
-m
 DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/scripts/finishSwigWrapperClasses.py
+DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/lldb.py
 COMMENT "Python script sym-linking LLDB Python API")
 # We depend on liblldb being built before we can do this step.
 add_dependencies(finish_swig liblldb lldb-argdumper)

Modified: lldb/trunk/scripts/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/scripts/CMakeLists.txt?rev=253478&r1=253477&r2=253478&view=diff
==
--- lldb/trunk/scripts/CMakeLists.txt (original)
+++ lldb/trunk/scripts/CMakeLists.txt Wed Nov 18 11:36:15 2015
@@ -18,9 +18,10 @@ add_custom_command(
   DEPENDS ${SWIG_HEADERS}
   DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/Python/buildSwigPython.py
   DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/Python/modify-python-lldb.py
-  COMMAND ${PYTHON_EXECUTABLE} 
${CMAKE_CURRENT_SOURCE_DIR}/buildSwigWrapperClasses.py 
"--srcRoot=${LLDB_SOURCE_DIR}" "--targetDir=${CMAKE_CURRENT_BINARY_DIR}" 
"--cfgBldDir=${CMAKE_CURRENT_BINARY_DIR}" "--prefix=${CMAKE_BINARY_DIR}" 
"--swigExecutable=${SWIG_EXECUTABLE}" -m
+  COMMAND ${PYTHON_EXECUTABLE} ${CMAKE_CURRENT_SOURCE_DIR}/prepare_bindings.py 
"--srcRoot=${LLDB_SOURCE_DIR}" "--targetDir=${CMAKE_CURRENT_BINARY_DIR}" 
"--cfgBldDir=${CMAKE_CURRENT_BINARY_DIR}" "--prefix=${CMAKE_BINARY_DIR}" 
"--swigExecutable=${SWIG_EXECUTABLE}"
   COMMENT "Python script building LLDB Python wrapper")
 set_source_files_properties(${CMAKE_CURRENT_BINARY_DIR}/LLDBWrapPython.cpp 
PROPERTIES GENERATED 1)
+set_source_files_properties(${CMAKE_CURRENT_BINARY_DIR}/lldb.py PROPERTIES 
GENERATED 1)
 
 add_custom_target(swig_wrapper ALL
   DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/LLDBWrapPython.cpp


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

Re: [Lldb-commits] [PATCH] D14633: [LLDB][MIPS] Clear bug 25194 - LLDB-Server Assertion raised when single stepping on MIPS

[Greg Clayton via lldb-commits]

clayborg added a comment.

I would prefix the first fix:

> Add a new function to llvm::APInt what returns the pointer to the actual data 
> in case of both endian (possibly the best option)


Using llvm::APInt gets us unlimited integer size abilities (support 128 bit 
ints and higher) along with any math that is required on those integers.


Repository:
  rL LLVM

http://reviews.llvm.org/D14633



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

Re: [Lldb-commits] [lldb] r253478 - Switched cmake build from using buildSwigWrapperClases.py to the cleaned up version.

[Zachary Turner via lldb-commits]

Just to be sure, did you catch the change I made to the old scripts in the
past few days to embed the swig version in the generated lldb.py?  Maybe
you did, I just want to make sure that change is in your new version.

On Wed, Nov 18, 2015 at 9:38 AM Todd Fiala via lldb-commits <
lldb-commits@lists.llvm.org> wrote:

> Author: tfiala
> Date: Wed Nov 18 11:36:15 2015
> New Revision: 253478
>
> URL: http://llvm.org/viewvc/llvm-project?rev=253478&view=rev
> Log:
> Switched cmake build from using buildSwigWrapperClases.py to the cleaned
> up version.
>
> This change does not introduce static bindings.  It is simply using
> the pylinted cleaned up code in prepare_bindings.py.
>
> If this breaks anyting, I'll revert immediately and figure out what
> needs to be addressed.  I'm looking to wrap up
> the cleanup aspect of the code change (pylinted, removal of code that
> implements existing python stdlib code, fixes for Xcode adoption, etc.).
>
> Modified:
> lldb/trunk/CMakeLists.txt
> lldb/trunk/scripts/CMakeLists.txt
>
> Modified: lldb/trunk/CMakeLists.txt
> URL:
> http://llvm.org/viewvc/llvm-project/lldb/trunk/CMakeLists.txt?rev=253478&r1=253477&r2=253478&view=diff
>
> ==
> --- lldb/trunk/CMakeLists.txt (original)
> +++ lldb/trunk/CMakeLists.txt Wed Nov 18 11:36:15 2015
> @@ -33,6 +33,7 @@ if (NOT LLDB_DISABLE_PYTHON)
>  add_custom_target( finish_swig ALL
>  COMMAND ${PYTHON_EXECUTABLE}
> ${CMAKE_CURRENT_SOURCE_DIR}/scripts/finishSwigWrapperClasses.py
> "--srcRoot=${LLDB_SOURCE_DIR}"
> "--targetDir=${CMAKE_CURRENT_BINARY_DIR}/scripts"
> "--cfgBldDir=${CMAKE_CURRENT_BINARY_DIR}/scripts"
> "--prefix=${CMAKE_BINARY_DIR}"
> "--cmakeBuildConfiguration=${CMAKE_CFG_INTDIR}" -m
>  DEPENDS
> ${CMAKE_CURRENT_SOURCE_DIR}/scripts/finishSwigWrapperClasses.py
> +DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/lldb.py
>  COMMENT "Python script sym-linking LLDB Python API")
>  # We depend on liblldb being built before we can do this step.
>  add_dependencies(finish_swig liblldb lldb-argdumper)
>
> Modified: lldb/trunk/scripts/CMakeLists.txt
> URL:
> http://llvm.org/viewvc/llvm-project/lldb/trunk/scripts/CMakeLists.txt?rev=253478&r1=253477&r2=253478&view=diff
>
> ==
> --- lldb/trunk/scripts/CMakeLists.txt (original)
> +++ lldb/trunk/scripts/CMakeLists.txt Wed Nov 18 11:36:15 2015
> @@ -18,9 +18,10 @@ add_custom_command(
>DEPENDS ${SWIG_HEADERS}
>DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/Python/buildSwigPython.py
>DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/Python/modify-python-lldb.py
> -  COMMAND ${PYTHON_EXECUTABLE}
> ${CMAKE_CURRENT_SOURCE_DIR}/buildSwigWrapperClasses.py
> "--srcRoot=${LLDB_SOURCE_DIR}" "--targetDir=${CMAKE_CURRENT_BINARY_DIR}"
> "--cfgBldDir=${CMAKE_CURRENT_BINARY_DIR}" "--prefix=${CMAKE_BINARY_DIR}"
> "--swigExecutable=${SWIG_EXECUTABLE}" -m
> +  COMMAND ${PYTHON_EXECUTABLE}
> ${CMAKE_CURRENT_SOURCE_DIR}/prepare_bindings.py
> "--srcRoot=${LLDB_SOURCE_DIR}" "--targetDir=${CMAKE_CURRENT_BINARY_DIR}"
> "--cfgBldDir=${CMAKE_CURRENT_BINARY_DIR}" "--prefix=${CMAKE_BINARY_DIR}"
> "--swigExecutable=${SWIG_EXECUTABLE}"
>COMMENT "Python script building LLDB Python wrapper")
>  set_source_files_properties(${CMAKE_CURRENT_BINARY_DIR}/LLDBWrapPython.cpp
> PROPERTIES GENERATED 1)
> +set_source_files_properties(${CMAKE_CURRENT_BINARY_DIR}/lldb.py
> PROPERTIES GENERATED 1)
>
>  add_custom_target(swig_wrapper ALL
>DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/LLDBWrapPython.cpp
>
>
> ___
> lldb-commits mailing list
> lldb-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [lldb-dev] [lldb] r253317 - Add Pythonic language binding wrapper generation script.

[Todd Fiala via lldb-commits]

Checking in the static bindings is no different than projects checking in
autoconf config baked scripts so that the vast majority of people don't
need to run autoconf just to get a setup that rarely changes.  There is
precedent for this going back a long way on open source projects.

I'm backing off having anyone else use them if they don't want, and we
(Apple) will keep those up to date.  Nobody else will use them.  Totally
fine.

On the swig-as-a-service front, I think the idea is interesting but there
are several practical holes with that:

* What does one do when the server is unavailable?  Needs to be a
local-only backup.  So whatever service that provides isn't a guaranteed
working solution (think on an airplane, network outage, other server
outage, etc.)

* Security: building code that has other code injected in it by another
server. Safe? Attack vector?  I could argue so is a git/svn repo
susceptible to this, so maybe this isn't a huge deal, but it's big enough
and smells enough like "introduce random unvetted code that can't be
reviewed as easily as a VCS tag" that I doubt we would ever use this in
practice.

* Security 2: what is the service really running?  Not obvious on the build
machine accessing the service.

> In all of these cases (except the proposed), the matrix choices are
justifiable because they are there to support a hard requirement of
someone's environment, and I do not think we should grow for anything that
is not also a hard requirement of someone's environment.

I'm going to call that overreaching.  We are not in the business of
dictating that one of the developers of the code "should not do something
unless there is a hard requirement."  Apple wants to eliminate the need for
people to *require* swig.  The goal there is reducing the build
requirements for the average person building lldb, not growing it.

Saying that "you hit a server for bindings as part of the build" is way
different and more onerous than saying "hey we don't want you to *require*
to have swig to build lldb."  Those are miles apart.

> And my question is, who doesn't have swig?  Maybe there is a legitimate
use case, I just want to understand what that is before we add more
different ways of building.

Swig is not a component that comes pre-installed on most public systems.
Almost nobody has it unless something they do says "you need to have this."
 So for a casual developer who is not a hardcore lldb developer, on a new
system/VM, they are not going to just have swig.  On OS X, it is a pain to
get unless you install homebrew/macports/fink.  On Linux, you'll need to do
an apt-get or yum install.

So I would flip that question around and say "who has swig unless something
requires it?"  And I'm creating a way to not require it.  That sounds a lot
more like a reduction in requirements for most build scenarios and most
people who would download and build lldb.

So for the more common, casual lldb build environment where the developer
is not touching SB API, help me understand how reducing the need for swig
(without introducing the need for hitting another server) is increasing the
requirement load?  (Especially if we --- our local dev group sitting by me
--- maintains those static bindings)?

On Wed, Nov 18, 2015 at 1:24 AM, Pavel Labath  wrote:

> On 18 November 2015 at 09:02, Zachary Turner via lldb-dev
>  wrote:
> > On Tue, Nov 17, 2015 at 8:03 PM Todd Fiala  wrote:
> >>
> >> Nothing concrete at the moment; however, it could be interesting to look
> >> at the clang community and see what could be done for llvm-based
> language
> >> implementations.  The angle that I think would be interesting would be
> if we
> >> can generate bindings more effectively based on the in-depth
> understanding
> >> of the language that is afforded by languages built on top of LLVM.
> This is
> >> probably less interesting for Python (particularly since we have a
> >> functioning solution) and more interesting for languages built on LLVM
> or
> >> clang.
> >>
> >> Honestly, though, I haven't spent much time on that.
> >>
> >> For the time being, I am going to not change the path for everyone on
> >> swig, and only use a static binding if swig cannot be found.  This will
> be
> >> minimal impact for everyone and doesn't interfere with anyone using a
> >> specific version of swig.  We can revisit larger questions about
> >> who/what/when on static bindings after we gain some experience with
> enabling
> >> them for those who don't have swig.  We can review and adjust based on
> our
> >> collective experience.  The two files this seems like it will be are the
> >> LLDBWrapPython.cpp and the lldb.py file that comes out of python.  I
> hope to
> >> have this working in the next day or so.
> >
> > To try this another way, I really would like to voice my opinion very
> very
> > strongly for moving away from having different ways of doing things for
> > different platforms / build configurations / etc unless it is *required*
> to
> > suppor

Re: [Lldb-commits] [lldb-dev] [lldb] r253317 - Add Pythonic language binding wrapper generation script.

[Todd Fiala via lldb-commits]

> On OS X, it is a pain to get unless you install homebrew/macports/fink.
On Linux, you'll need to do an apt-get or yum install.

And I should add that installing home-brew (the most common way of picking
up extra goodies, as I know I do it on home machines) is also one of the
most common ways to prevent lldb from building correctly and usably on OS
X.  (Particularly with the way its introduction of an alternative python
and its placement on the lookup path will totally bork a system or
hand-built lldb).

On Wed, Nov 18, 2015 at 10:00 AM, Todd Fiala  wrote:

> Checking in the static bindings is no different than projects checking in
> autoconf config baked scripts so that the vast majority of people don't
> need to run autoconf just to get a setup that rarely changes.  There is
> precedent for this going back a long way on open source projects.
>
> I'm backing off having anyone else use them if they don't want, and we
> (Apple) will keep those up to date.  Nobody else will use them.  Totally
> fine.
>
> On the swig-as-a-service front, I think the idea is interesting but there
> are several practical holes with that:
>
> * What does one do when the server is unavailable?  Needs to be a
> local-only backup.  So whatever service that provides isn't a guaranteed
> working solution (think on an airplane, network outage, other server
> outage, etc.)
>
> * Security: building code that has other code injected in it by another
> server. Safe? Attack vector?  I could argue so is a git/svn repo
> susceptible to this, so maybe this isn't a huge deal, but it's big enough
> and smells enough like "introduce random unvetted code that can't be
> reviewed as easily as a VCS tag" that I doubt we would ever use this in
> practice.
>
> * Security 2: what is the service really running?  Not obvious on the
> build machine accessing the service.
>
> > In all of these cases (except the proposed), the matrix choices are
> justifiable because they are there to support a hard requirement of
> someone's environment, and I do not think we should grow for anything that
> is not also a hard requirement of someone's environment.
>
> I'm going to call that overreaching.  We are not in the business of
> dictating that one of the developers of the code "should not do something
> unless there is a hard requirement."  Apple wants to eliminate the need for
> people to *require* swig.  The goal there is reducing the build
> requirements for the average person building lldb, not growing it.
>
> Saying that "you hit a server for bindings as part of the build" is way
> different and more onerous than saying "hey we don't want you to *require*
> to have swig to build lldb."  Those are miles apart.
>
> > And my question is, who doesn't have swig?  Maybe there is a legitimate
> use case, I just want to understand what that is before we add more
> different ways of building.
>
> Swig is not a component that comes pre-installed on most public systems.
> Almost nobody has it unless something they do says "you need to have this."
>  So for a casual developer who is not a hardcore lldb developer, on a new
> system/VM, they are not going to just have swig.  On OS X, it is a pain to
> get unless you install homebrew/macports/fink.  On Linux, you'll need to do
> an apt-get or yum install.
>
> So I would flip that question around and say "who has swig unless
> something requires it?"  And I'm creating a way to not require it.  That
> sounds a lot more like a reduction in requirements for most build scenarios
> and most people who would download and build lldb.
>
> So for the more common, casual lldb build environment where the developer
> is not touching SB API, help me understand how reducing the need for swig
> (without introducing the need for hitting another server) is increasing the
> requirement load?  (Especially if we --- our local dev group sitting by me
> --- maintains those static bindings)?
>
> On Wed, Nov 18, 2015 at 1:24 AM, Pavel Labath  wrote:
>
>> On 18 November 2015 at 09:02, Zachary Turner via lldb-dev
>>  wrote:
>> > On Tue, Nov 17, 2015 at 8:03 PM Todd Fiala 
>> wrote:
>> >>
>> >> Nothing concrete at the moment; however, it could be interesting to
>> look
>> >> at the clang community and see what could be done for llvm-based
>> language
>> >> implementations.  The angle that I think would be interesting would be
>> if we
>> >> can generate bindings more effectively based on the in-depth
>> understanding
>> >> of the language that is afforded by languages built on top of LLVM.
>> This is
>> >> probably less interesting for Python (particularly since we have a
>> >> functioning solution) and more interesting for languages built on LLVM
>> or
>> >> clang.
>> >>
>> >> Honestly, though, I haven't spent much time on that.
>> >>
>> >> For the time being, I am going to not change the path for everyone on
>> >> swig, and only use a static binding if swig cannot be found.  This
>> will be
>> >> minimal impact for everyone and doesn't interfere with

Re: [Lldb-commits] [lldb] r253478 - Switched cmake build from using buildSwigWrapperClases.py to the cleaned up version.

[Todd Fiala via lldb-commits]

Double checking now, if it happens in that lldb-modify script, we're
covered.  Otherwise I need to adjust...  (the bulk of the rewrite happened
on Friday/Sunday).

On Wed, Nov 18, 2015 at 9:47 AM, Zachary Turner  wrote:

> Just to be sure, did you catch the change I made to the old scripts in the
> past few days to embed the swig version in the generated lldb.py?  Maybe
> you did, I just want to make sure that change is in your new version.
>
> On Wed, Nov 18, 2015 at 9:38 AM Todd Fiala via lldb-commits <
> lldb-commits@lists.llvm.org> wrote:
>
>> Author: tfiala
>> Date: Wed Nov 18 11:36:15 2015
>> New Revision: 253478
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=253478&view=rev
>> Log:
>> Switched cmake build from using buildSwigWrapperClases.py to the cleaned
>> up version.
>>
>> This change does not introduce static bindings.  It is simply using
>> the pylinted cleaned up code in prepare_bindings.py.
>>
>> If this breaks anyting, I'll revert immediately and figure out what
>> needs to be addressed.  I'm looking to wrap up
>> the cleanup aspect of the code change (pylinted, removal of code that
>> implements existing python stdlib code, fixes for Xcode adoption, etc.).
>>
>> Modified:
>> lldb/trunk/CMakeLists.txt
>> lldb/trunk/scripts/CMakeLists.txt
>>
>> Modified: lldb/trunk/CMakeLists.txt
>> URL:
>> http://llvm.org/viewvc/llvm-project/lldb/trunk/CMakeLists.txt?rev=253478&r1=253477&r2=253478&view=diff
>>
>> ==
>> --- lldb/trunk/CMakeLists.txt (original)
>> +++ lldb/trunk/CMakeLists.txt Wed Nov 18 11:36:15 2015
>> @@ -33,6 +33,7 @@ if (NOT LLDB_DISABLE_PYTHON)
>>  add_custom_target( finish_swig ALL
>>  COMMAND ${PYTHON_EXECUTABLE}
>> ${CMAKE_CURRENT_SOURCE_DIR}/scripts/finishSwigWrapperClasses.py
>> "--srcRoot=${LLDB_SOURCE_DIR}"
>> "--targetDir=${CMAKE_CURRENT_BINARY_DIR}/scripts"
>> "--cfgBldDir=${CMAKE_CURRENT_BINARY_DIR}/scripts"
>> "--prefix=${CMAKE_BINARY_DIR}"
>> "--cmakeBuildConfiguration=${CMAKE_CFG_INTDIR}" -m
>>  DEPENDS
>> ${CMAKE_CURRENT_SOURCE_DIR}/scripts/finishSwigWrapperClasses.py
>> +DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/lldb.py
>>  COMMENT "Python script sym-linking LLDB Python API")
>>  # We depend on liblldb being built before we can do this step.
>>  add_dependencies(finish_swig liblldb lldb-argdumper)
>>
>> Modified: lldb/trunk/scripts/CMakeLists.txt
>> URL:
>> http://llvm.org/viewvc/llvm-project/lldb/trunk/scripts/CMakeLists.txt?rev=253478&r1=253477&r2=253478&view=diff
>>
>> ==
>> --- lldb/trunk/scripts/CMakeLists.txt (original)
>> +++ lldb/trunk/scripts/CMakeLists.txt Wed Nov 18 11:36:15 2015
>> @@ -18,9 +18,10 @@ add_custom_command(
>>DEPENDS ${SWIG_HEADERS}
>>DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/Python/buildSwigPython.py
>>DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/Python/modify-python-lldb.py
>> -  COMMAND ${PYTHON_EXECUTABLE}
>> ${CMAKE_CURRENT_SOURCE_DIR}/buildSwigWrapperClasses.py
>> "--srcRoot=${LLDB_SOURCE_DIR}" "--targetDir=${CMAKE_CURRENT_BINARY_DIR}"
>> "--cfgBldDir=${CMAKE_CURRENT_BINARY_DIR}" "--prefix=${CMAKE_BINARY_DIR}"
>> "--swigExecutable=${SWIG_EXECUTABLE}" -m
>> +  COMMAND ${PYTHON_EXECUTABLE}
>> ${CMAKE_CURRENT_SOURCE_DIR}/prepare_bindings.py
>> "--srcRoot=${LLDB_SOURCE_DIR}" "--targetDir=${CMAKE_CURRENT_BINARY_DIR}"
>> "--cfgBldDir=${CMAKE_CURRENT_BINARY_DIR}" "--prefix=${CMAKE_BINARY_DIR}"
>> "--swigExecutable=${SWIG_EXECUTABLE}"
>>COMMENT "Python script building LLDB Python wrapper")
>>  set_source_files_properties(${CMAKE_CURRENT_BINARY_DIR}/LLDBWrapPython.cpp
>> PROPERTIES GENERATED 1)
>> +set_source_files_properties(${CMAKE_CURRENT_BINARY_DIR}/lldb.py
>> PROPERTIES GENERATED 1)
>>
>>  add_custom_target(swig_wrapper ALL
>>DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/LLDBWrapPython.cpp
>>
>>
>> ___
>> lldb-commits mailing list
>> lldb-commits@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
>>
>


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

Re: [Lldb-commits] [lldb] r253478 - Switched cmake build from using buildSwigWrapperClases.py to the cleaned up version.

[Todd Fiala via lldb-commits]

You're talking about this change, right?  (I'm looking at it now...)

commit cc353bbc992ab324aef395c54a2a46fcaaa3855b
Author: Zachary Turner 
Date:   Mon Nov 16 22:40:20 2015 +

Insert the SWIG version into LLDB's __init__.py

The goal here is to allow us to add skip / xfail decorators
based on SWIG version.

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@253262
91177308-0d34-0410-b5e6-96231b3b80d8


On Wed, Nov 18, 2015 at 10:07 AM, Todd Fiala  wrote:

> Double checking now, if it happens in that lldb-modify script, we're
> covered.  Otherwise I need to adjust...  (the bulk of the rewrite happened
> on Friday/Sunday).
>
> On Wed, Nov 18, 2015 at 9:47 AM, Zachary Turner 
> wrote:
>
>> Just to be sure, did you catch the change I made to the old scripts in
>> the past few days to embed the swig version in the generated lldb.py?
>> Maybe you did, I just want to make sure that change is in your new version.
>>
>> On Wed, Nov 18, 2015 at 9:38 AM Todd Fiala via lldb-commits <
>> lldb-commits@lists.llvm.org> wrote:
>>
>>> Author: tfiala
>>> Date: Wed Nov 18 11:36:15 2015
>>> New Revision: 253478
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=253478&view=rev
>>> Log:
>>> Switched cmake build from using buildSwigWrapperClases.py to the cleaned
>>> up version.
>>>
>>> This change does not introduce static bindings.  It is simply using
>>> the pylinted cleaned up code in prepare_bindings.py.
>>>
>>> If this breaks anyting, I'll revert immediately and figure out what
>>> needs to be addressed.  I'm looking to wrap up
>>> the cleanup aspect of the code change (pylinted, removal of code that
>>> implements existing python stdlib code, fixes for Xcode adoption, etc.).
>>>
>>> Modified:
>>> lldb/trunk/CMakeLists.txt
>>> lldb/trunk/scripts/CMakeLists.txt
>>>
>>> Modified: lldb/trunk/CMakeLists.txt
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/lldb/trunk/CMakeLists.txt?rev=253478&r1=253477&r2=253478&view=diff
>>>
>>> ==
>>> --- lldb/trunk/CMakeLists.txt (original)
>>> +++ lldb/trunk/CMakeLists.txt Wed Nov 18 11:36:15 2015
>>> @@ -33,6 +33,7 @@ if (NOT LLDB_DISABLE_PYTHON)
>>>  add_custom_target( finish_swig ALL
>>>  COMMAND ${PYTHON_EXECUTABLE}
>>> ${CMAKE_CURRENT_SOURCE_DIR}/scripts/finishSwigWrapperClasses.py
>>> "--srcRoot=${LLDB_SOURCE_DIR}"
>>> "--targetDir=${CMAKE_CURRENT_BINARY_DIR}/scripts"
>>> "--cfgBldDir=${CMAKE_CURRENT_BINARY_DIR}/scripts"
>>> "--prefix=${CMAKE_BINARY_DIR}"
>>> "--cmakeBuildConfiguration=${CMAKE_CFG_INTDIR}" -m
>>>  DEPENDS
>>> ${CMAKE_CURRENT_SOURCE_DIR}/scripts/finishSwigWrapperClasses.py
>>> +DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/lldb.py
>>>  COMMENT "Python script sym-linking LLDB Python API")
>>>  # We depend on liblldb being built before we can do this step.
>>>  add_dependencies(finish_swig liblldb lldb-argdumper)
>>>
>>> Modified: lldb/trunk/scripts/CMakeLists.txt
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/lldb/trunk/scripts/CMakeLists.txt?rev=253478&r1=253477&r2=253478&view=diff
>>>
>>> ==
>>> --- lldb/trunk/scripts/CMakeLists.txt (original)
>>> +++ lldb/trunk/scripts/CMakeLists.txt Wed Nov 18 11:36:15 2015
>>> @@ -18,9 +18,10 @@ add_custom_command(
>>>DEPENDS ${SWIG_HEADERS}
>>>DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/Python/buildSwigPython.py
>>>DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/Python/modify-python-lldb.py
>>> -  COMMAND ${PYTHON_EXECUTABLE}
>>> ${CMAKE_CURRENT_SOURCE_DIR}/buildSwigWrapperClasses.py
>>> "--srcRoot=${LLDB_SOURCE_DIR}" "--targetDir=${CMAKE_CURRENT_BINARY_DIR}"
>>> "--cfgBldDir=${CMAKE_CURRENT_BINARY_DIR}" "--prefix=${CMAKE_BINARY_DIR}"
>>> "--swigExecutable=${SWIG_EXECUTABLE}" -m
>>> +  COMMAND ${PYTHON_EXECUTABLE}
>>> ${CMAKE_CURRENT_SOURCE_DIR}/prepare_bindings.py
>>> "--srcRoot=${LLDB_SOURCE_DIR}" "--targetDir=${CMAKE_CURRENT_BINARY_DIR}"
>>> "--cfgBldDir=${CMAKE_CURRENT_BINARY_DIR}" "--prefix=${CMAKE_BINARY_DIR}"
>>> "--swigExecutable=${SWIG_EXECUTABLE}"
>>>COMMENT "Python script building LLDB Python wrapper")
>>>  set_source_files_properties(${CMAKE_CURRENT_BINARY_DIR}/LLDBWrapPython.cpp
>>> PROPERTIES GENERATED 1)
>>> +set_source_files_properties(${CMAKE_CURRENT_BINARY_DIR}/lldb.py
>>> PROPERTIES GENERATED 1)
>>>
>>>  add_custom_target(swig_wrapper ALL
>>>DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/LLDBWrapPython.cpp
>>>
>>>
>>> ___
>>> lldb-commits mailing list
>>> lldb-commits@lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
>>>
>>
>
>
> --
> -Todd
>



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

Re: [Lldb-commits] [lldb] r253478 - Switched cmake build from using buildSwigWrapperClases.py to the cleaned up version.

[Todd Fiala via lldb-commits]

If I have that right, we're fine.  The prepare_bindings.py still calls
modify-python-lldb.py.

scripts/prepare_bindings.py is meant to be the same as
createSwigBindings.py, and scripts/python/prepare_binding_Python.py is
meant to be the same as buildSwigPython.py.

Once I make sure that I haven't broken anything for anybody with it, I'll
get rid of the other scripts.

On Wed, Nov 18, 2015 at 10:09 AM, Todd Fiala  wrote:

> You're talking about this change, right?  (I'm looking at it now...)
>
> commit cc353bbc992ab324aef395c54a2a46fcaaa3855b
> Author: Zachary Turner 
> Date:   Mon Nov 16 22:40:20 2015 +
>
> Insert the SWIG version into LLDB's __init__.py
>
> The goal here is to allow us to add skip / xfail decorators
> based on SWIG version.
>
> git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@253262
> 91177308-0d34-0410-b5e6-96231b3b80d8
>
>
> On Wed, Nov 18, 2015 at 10:07 AM, Todd Fiala  wrote:
>
>> Double checking now, if it happens in that lldb-modify script, we're
>> covered.  Otherwise I need to adjust...  (the bulk of the rewrite happened
>> on Friday/Sunday).
>>
>> On Wed, Nov 18, 2015 at 9:47 AM, Zachary Turner 
>> wrote:
>>
>>> Just to be sure, did you catch the change I made to the old scripts in
>>> the past few days to embed the swig version in the generated lldb.py?
>>> Maybe you did, I just want to make sure that change is in your new version.
>>>
>>> On Wed, Nov 18, 2015 at 9:38 AM Todd Fiala via lldb-commits <
>>> lldb-commits@lists.llvm.org> wrote:
>>>
 Author: tfiala
 Date: Wed Nov 18 11:36:15 2015
 New Revision: 253478

 URL: http://llvm.org/viewvc/llvm-project?rev=253478&view=rev
 Log:
 Switched cmake build from using buildSwigWrapperClases.py to the
 cleaned up version.

 This change does not introduce static bindings.  It is simply using
 the pylinted cleaned up code in prepare_bindings.py.

 If this breaks anyting, I'll revert immediately and figure out what
 needs to be addressed.  I'm looking to wrap up
 the cleanup aspect of the code change (pylinted, removal of code that
 implements existing python stdlib code, fixes for Xcode adoption, etc.).

 Modified:
 lldb/trunk/CMakeLists.txt
 lldb/trunk/scripts/CMakeLists.txt

 Modified: lldb/trunk/CMakeLists.txt
 URL:
 http://llvm.org/viewvc/llvm-project/lldb/trunk/CMakeLists.txt?rev=253478&r1=253477&r2=253478&view=diff

 ==
 --- lldb/trunk/CMakeLists.txt (original)
 +++ lldb/trunk/CMakeLists.txt Wed Nov 18 11:36:15 2015
 @@ -33,6 +33,7 @@ if (NOT LLDB_DISABLE_PYTHON)
  add_custom_target( finish_swig ALL
  COMMAND ${PYTHON_EXECUTABLE}
 ${CMAKE_CURRENT_SOURCE_DIR}/scripts/finishSwigWrapperClasses.py
 "--srcRoot=${LLDB_SOURCE_DIR}"
 "--targetDir=${CMAKE_CURRENT_BINARY_DIR}/scripts"
 "--cfgBldDir=${CMAKE_CURRENT_BINARY_DIR}/scripts"
 "--prefix=${CMAKE_BINARY_DIR}"
 "--cmakeBuildConfiguration=${CMAKE_CFG_INTDIR}" -m
  DEPENDS
 ${CMAKE_CURRENT_SOURCE_DIR}/scripts/finishSwigWrapperClasses.py
 +DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/lldb.py
  COMMENT "Python script sym-linking LLDB Python API")
  # We depend on liblldb being built before we can do this step.
  add_dependencies(finish_swig liblldb lldb-argdumper)

 Modified: lldb/trunk/scripts/CMakeLists.txt
 URL:
 http://llvm.org/viewvc/llvm-project/lldb/trunk/scripts/CMakeLists.txt?rev=253478&r1=253477&r2=253478&view=diff

 ==
 --- lldb/trunk/scripts/CMakeLists.txt (original)
 +++ lldb/trunk/scripts/CMakeLists.txt Wed Nov 18 11:36:15 2015
 @@ -18,9 +18,10 @@ add_custom_command(
DEPENDS ${SWIG_HEADERS}
DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/Python/buildSwigPython.py
DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/Python/modify-python-lldb.py
 -  COMMAND ${PYTHON_EXECUTABLE}
 ${CMAKE_CURRENT_SOURCE_DIR}/buildSwigWrapperClasses.py
 "--srcRoot=${LLDB_SOURCE_DIR}" "--targetDir=${CMAKE_CURRENT_BINARY_DIR}"
 "--cfgBldDir=${CMAKE_CURRENT_BINARY_DIR}" "--prefix=${CMAKE_BINARY_DIR}"
 "--swigExecutable=${SWIG_EXECUTABLE}" -m
 +  COMMAND ${PYTHON_EXECUTABLE}
 ${CMAKE_CURRENT_SOURCE_DIR}/prepare_bindings.py
 "--srcRoot=${LLDB_SOURCE_DIR}" "--targetDir=${CMAKE_CURRENT_BINARY_DIR}"
 "--cfgBldDir=${CMAKE_CURRENT_BINARY_DIR}" "--prefix=${CMAKE_BINARY_DIR}"
 "--swigExecutable=${SWIG_EXECUTABLE}"
COMMENT "Python script building LLDB Python wrapper")
  set_source_files_properties(${CMAKE_CURRENT_BINARY_DIR}/LLDBWrapPython.cpp
 PROPERTIES GENERATED 1)
 +set_source_files_properties(${CMAKE_CURRENT_BINARY_DIR}/lldb.py
 PROPERTIES GENERATED 1)

  add_custom_target(swig_wrapper ALL
DEPENDS ${CMAKE_CURR

Re: [Lldb-commits] [PATCH] D14765: Support unix-abstract-connect scheme as platform url in lldb testsuite

[Oleksiy Vyalov via lldb-commits]

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

LGTM



Comment at: packages/Python/lldbsuite/test/lldbtest.py:464
@@ -463,3 +463,3 @@
 parsed_url = urlparse.urlparse(lldb.platform_url)
-if parsed_url.scheme == "adb":
+if parsed_url.netloc.split(":")[0] != 'localhost':
 device_id = parsed_url.netloc.split(":")[0]

Nit - you may save parsed_url.netloc.split(":")[0] as local variable like 
host_name


http://reviews.llvm.org/D14765



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

Re: [Lldb-commits] [lldb-dev] [lldb] r253317 - Add Pythonic language binding wrapper generation script.

[Zachary Turner via lldb-commits]

On Wed, Nov 18, 2015 at 10:00 AM Todd Fiala  wrote:

> Checking in the static bindings is no different than projects checking in
> autoconf config baked scripts so that the vast majority of people don't
> need to run autoconf just to get a setup that rarely changes.  There is
> precedent for this going back a long way on open source projects.
>
> I'm backing off having anyone else use them if they don't want, and we
> (Apple) will keep those up to date.  Nobody else will use them.  Totally
> fine.
>
> On the swig-as-a-service front, I think the idea is interesting but there
> are several practical holes with that:
>
> * What does one do when the server is unavailable?  Needs to be a
> local-only backup.  So whatever service that provides isn't a guaranteed
> working solution (think on an airplane, network outage, other server
> outage, etc.)
>

> * Security: building code that has other code injected in it by another
> server. Safe? Attack vector?  I could argue so is a git/svn repo
> susceptible to this, so maybe this isn't a huge deal, but it's big enough
> and smells enough like "introduce random unvetted code that can't be
> reviewed as easily as a VCS tag" that I doubt we would ever use this in
> practice.
>
> * Security 2: what is the service really running?  Not obvious on the
> build machine accessing the service.
>
The end result of the service is a copy of LLDBWrapPython.cpp and lldb.py
that you check into the repo.  You still have a chance to diff this source
code against the repository's copy before committing, same as you would if
you had swig locally.  Vast majority of changes to SB interfaces are going
to be the addition of a couple methods, or maybe a class, and the diff
should be very easy to look at and understand.


>
> > In all of these cases (except the proposed), the matrix choices are
> justifiable because they are there to support a hard requirement of
> someone's environment, and I do not think we should grow for anything that
> is not also a hard requirement of someone's environment.
>
> I'm going to call that overreaching.  We are not in the business of
> dictating that one of the developers of the code "should not do something
> unless there is a hard requirement."
>
I'm not saying you shouldn't do *anything* if there's not a hard
requirement.  I agree that's overreaching.  I'm saying we should not
increase the number of ways of doing *the same thing* unless there is a
hard requirement.  Especially if one of the ways of doing the same thing
exists solely to save someone from running one command to install the
package (sorry if I'm not doing justice to how difficult it is on OSX, the
last time I did something on OSX it seemed fairly easy to install macports,
and I thought it's a wildly common thing for people to already have
installed).  For example, wouldn't people need to already have macports in
order to install CMake -- a necessary component of building LLVM?


>  Apple wants to eliminate the need for people to *require* swig.  The goal
> there is reducing the build requirements for the average person building
> lldb, not growing it.
>
I agree, which is why it is so important to keep the number of different
ways of building to a minimum.  It's the same reason that the autoconf
build is being removed wholesale from LLVM and people have decided that
CMake is the one true way.  Because even if it isn't perfect for everyone,
it works for everyone.  And there is inherent simplicity in having fewer
ways to do things, as well as reducing maintenance cost.


>
> So for the more common, casual lldb build environment where the developer
> is not touching SB API, help me understand how reducing the need for swig
> (without introducing the need for hitting another server) is increasing the
> requirement load?  (Especially if we --- our local dev group sitting by me
> --- maintains those static bindings)?
>

Well, we would need to disable static bindings on the OSX buildbots for
starters, otherwise when someone not using static bindings makes a change,
the buildbots break, and we cannot leave buildbots in a broken state.  So I
assume that will still be possible.  So now you don't have a buildbot
testing the static binding configuration.

Secondly, LLDB already has a problem (IMHO) of having too many things that
only work for a few people, instead of having things that work for
everyone.  It's gotten better, and even your work right now to port the
Xcode build over to these new python scripts is helping to make that
better.  So regardless of the outcome here, the end result will still be an
improvement over before when Xcode build was using the shells cripts and
CMake build was using python scripts.

But I still think it's important to take a hardline against introducing new
build configurations.  Static vs on-the-fly bindings are going to need
different logic for getting the resulting code into the place where it can
be compiled / imported, different logic for creating the symlinks, etc.

Re: [Lldb-commits] [lldb] r253478 - Switched cmake build from using buildSwigWrapperClases.py to the cleaned up version.

[Zachary Turner via lldb-commits]

Yea, this is the right one.  Thanks!  I haven't tested this yet, but I will
later.  (Our buildbot currently builds with LLDB_DISABLE_PYTHON=1, so if
there is a problem with this, the Windows buildbot wouldn't pick it up,
although the others probably would)

On Wed, Nov 18, 2015 at 10:14 AM Todd Fiala  wrote:

> If I have that right, we're fine.  The prepare_bindings.py still calls
> modify-python-lldb.py.
>
> scripts/prepare_bindings.py is meant to be the same as
> createSwigBindings.py, and scripts/python/prepare_binding_Python.py is
> meant to be the same as buildSwigPython.py.
>
> Once I make sure that I haven't broken anything for anybody with it, I'll
> get rid of the other scripts.
>
> On Wed, Nov 18, 2015 at 10:09 AM, Todd Fiala  wrote:
>
>> You're talking about this change, right?  (I'm looking at it now...)
>>
>> commit cc353bbc992ab324aef395c54a2a46fcaaa3855b
>> Author: Zachary Turner 
>> Date:   Mon Nov 16 22:40:20 2015 +
>>
>> Insert the SWIG version into LLDB's __init__.py
>>
>> The goal here is to allow us to add skip / xfail decorators
>> based on SWIG version.
>>
>> git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@253262
>> 91177308-0d34-0410-b5e6-96231b3b80d8
>>
>>
>> On Wed, Nov 18, 2015 at 10:07 AM, Todd Fiala 
>> wrote:
>>
>>> Double checking now, if it happens in that lldb-modify script, we're
>>> covered.  Otherwise I need to adjust...  (the bulk of the rewrite happened
>>> on Friday/Sunday).
>>>
>>> On Wed, Nov 18, 2015 at 9:47 AM, Zachary Turner 
>>> wrote:
>>>
 Just to be sure, did you catch the change I made to the old scripts in
 the past few days to embed the swig version in the generated lldb.py?
 Maybe you did, I just want to make sure that change is in your new version.

 On Wed, Nov 18, 2015 at 9:38 AM Todd Fiala via lldb-commits <
 lldb-commits@lists.llvm.org> wrote:

> Author: tfiala
> Date: Wed Nov 18 11:36:15 2015
> New Revision: 253478
>
> URL: http://llvm.org/viewvc/llvm-project?rev=253478&view=rev
> Log:
> Switched cmake build from using buildSwigWrapperClases.py to the
> cleaned up version.
>
> This change does not introduce static bindings.  It is simply using
> the pylinted cleaned up code in prepare_bindings.py.
>
> If this breaks anyting, I'll revert immediately and figure out what
> needs to be addressed.  I'm looking to wrap up
> the cleanup aspect of the code change (pylinted, removal of code that
> implements existing python stdlib code, fixes for Xcode adoption,
> etc.).
>
> Modified:
> lldb/trunk/CMakeLists.txt
> lldb/trunk/scripts/CMakeLists.txt
>
> Modified: lldb/trunk/CMakeLists.txt
> URL:
> http://llvm.org/viewvc/llvm-project/lldb/trunk/CMakeLists.txt?rev=253478&r1=253477&r2=253478&view=diff
>
> ==
> --- lldb/trunk/CMakeLists.txt (original)
> +++ lldb/trunk/CMakeLists.txt Wed Nov 18 11:36:15 2015
> @@ -33,6 +33,7 @@ if (NOT LLDB_DISABLE_PYTHON)
>  add_custom_target( finish_swig ALL
>  COMMAND ${PYTHON_EXECUTABLE}
> ${CMAKE_CURRENT_SOURCE_DIR}/scripts/finishSwigWrapperClasses.py
> "--srcRoot=${LLDB_SOURCE_DIR}"
> "--targetDir=${CMAKE_CURRENT_BINARY_DIR}/scripts"
> "--cfgBldDir=${CMAKE_CURRENT_BINARY_DIR}/scripts"
> "--prefix=${CMAKE_BINARY_DIR}"
> "--cmakeBuildConfiguration=${CMAKE_CFG_INTDIR}" -m
>  DEPENDS
> ${CMAKE_CURRENT_SOURCE_DIR}/scripts/finishSwigWrapperClasses.py
> +DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/lldb.py
>  COMMENT "Python script sym-linking LLDB Python API")
>  # We depend on liblldb being built before we can do this step.
>  add_dependencies(finish_swig liblldb lldb-argdumper)
>
> Modified: lldb/trunk/scripts/CMakeLists.txt
> URL:
> http://llvm.org/viewvc/llvm-project/lldb/trunk/scripts/CMakeLists.txt?rev=253478&r1=253477&r2=253478&view=diff
>
> ==
> --- lldb/trunk/scripts/CMakeLists.txt (original)
> +++ lldb/trunk/scripts/CMakeLists.txt Wed Nov 18 11:36:15 2015
> @@ -18,9 +18,10 @@ add_custom_command(
>DEPENDS ${SWIG_HEADERS}
>DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/Python/buildSwigPython.py
>DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/Python/modify-python-lldb.py
> -  COMMAND ${PYTHON_EXECUTABLE}
> ${CMAKE_CURRENT_SOURCE_DIR}/buildSwigWrapperClasses.py
> "--srcRoot=${LLDB_SOURCE_DIR}" "--targetDir=${CMAKE_CURRENT_BINARY_DIR}"
> "--cfgBldDir=${CMAKE_CURRENT_BINARY_DIR}" "--prefix=${CMAKE_BINARY_DIR}"
> "--swigExecutable=${SWIG_EXECUTABLE}" -m
> +  COMMAND ${PYTHON_EXECUTABLE}
> ${CMAKE_CURRENT_SOURCE_DIR}/prepare_bindings.py
> "--srcRoot=${LLDB_SOURCE_DIR}" "--targetDir=${CMAKE_CURRENT_BINARY_DIR}"
> "--cfgBldDir=${CMAKE_CURRE

[Lldb-commits] Some buildbot statistics for the last week

[Galina Kistanova via lldb-commits]

Hello everyone,

Here are some buildbot statistics you may found interesting. I will be
adding more statistics.
My goal is to publish metrics to help with keeping the buildbot
infrastructure healthy and improving it.

All the numbers are for the week of 11/8/2015 - 11/14/2015.

Thanks

Galina



Number of commits by project:

 project  |   commits
 -
 llvm |   286
 cfe  |   109
 lldb |76
 compiler-rt  |71
 polly|42
 lld  |38
 libcxx   |10
 openmp   | 9
 clang-tools-extra| 7
 clang-tests-external | 2
 libunwind| 1
 -
  651


Number of completed builds, failed builds and average build time for
successful builds per active builder:

 buildername   | completed  |
failed | time
-
 clang-aarch64-lnt | 57
|  3 | 02:30:12
 clang-atom-d525-fedora| 18
|| 08:28:15
 clang-atom-d525-fedora-rel| 83
|  5 | 01:29:55
 clang-bpf-build   |310
| 31 | 00:02:53
 clang-cmake-aarch64-42vma |278
| 49 | 00:16:47
 clang-cmake-aarch64-quick |209
| 29 | 00:23:46
 clang-cmake-armv7-a15 |189
|  8 | 00:25:27
 clang-cmake-armv7-a15-full|154
| 38 | 00:45:32
 clang-cmake-armv7-a15-selfhost| 58
| 24 | 03:00:19
 clang-cmake-armv7-a15-selfhost-neon   | 45
| 22 | 04:26:31
 clang-cmake-mips  |186
| 38 | 00:28:52
 clang-cmake-thumbv7-a15   |178
|  7 | 00:28:30
 clang-cmake-thumbv7-a15-full-sh   | 32
| 23 | 06:03:05
 clang-hexagon-elf |169
| 23 | 00:24:42
 clang-native-aarch64-full | 24
|  8 | 05:53:35
 clang-native-arm-lnt  | 90
|  3 | 01:06:01
 clang-native-arm-lnt-perf | 14
|| 08:57:04
 clang-ppc64-elf-linux |120
|  6 | 01:01:02
 clang-ppc64-elf-linux2| 89
| 24 | 01:29:49
 clang-sphinx-docs |113
|| 00:00:20
 clang-x64-ninja-win7  |285
| 58 | 00:09:49
 clang-x86-win2008-selfhost|268
| 46 | 00:12:10
 clang-x86_64-darwin13-cross-arm   |232
|  1 | 00:19:45
 clang-x86_64-darwin13-cross-mingw32   |217
| 12 | 00:23:20
 clang-x86_64-debian-fast  |147
| 12 | 00:11:37
 clang-x86_64-linux-abi-test   |314
|  1 | 00:18:39
 clang-x86_64-linux-selfhost-modules   |261
| 25 | 00:15:02
 clang-x86_64-ubuntu-gdb-75|124
| 62 | 00:53:12
 libcxx-libcxxabi-arm-linux|  8
|| 01:05:10
 libcxx-libcxxabi-singlethreaded-x86_64-linux-debian   | 11
|  2 | 00:08:50
 libcxx-libcxxabi-x86_64-linux-debian  | 11
|  4 | 00:09:43
 libcxx-libcxxabi-x86_64-linux-debian-noexceptions |  5
|  2 | 00:09:24
 libcxx-libcxxabi-x86_64-linux-ubuntu-asan | 10
|  2 | 00:08:22
 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx03| 10
|| 00:05:12
 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx11| 10
|| 00:06:19
 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx14|  9
|| 00:06:56
 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx1z| 10
|  2 | 00:06:06
 libcxx-libcxxabi-x86_64-linux-ubuntu-msan | 10
|  2 | 00:17:00
 libcxx-libcxxabi-x86_64-linux-ubuntu-tsan | 10
|  1 | 

[Lldb-commits] [lldb] r253487 - Fix some issues with swig & string conversion.

[Zachary Turner via lldb-commits]

Author: zturner
Date: Wed Nov 18 12:40:16 2015
New Revision: 253487

URL: http://llvm.org/viewvc/llvm-project?rev=253487&view=rev
Log:
Fix some issues with swig & string conversion.

This patch fixes two issues:

1) Popen needs to be used with universal_newlines=True by default.
   This elicits automatic decoding from bytes -> string in Py3,
   and has no negative effects in other Py versions.
2) The swig typemaps for converting between string and (char*, int)
   did not work correctly when the length of the string was 0,
   indicating an error.  In this case we would try to construct a
   string from uninitialized data.
3) Ironically, the bug mentioned in #2 led to a test passing on
   Windows that was actually broken, because the test was written
   such that the assertion was never even getting checked, so it
   passed by default.  So we additionally fix this test to also
   fail if the method errors.  By fixing this test it's now broken
   on Windows, so we also xfail it.

Modified:

lldb/trunk/packages/Python/lldbsuite/test/functionalities/process_launch/TestProcessLaunch.py
lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/virtual/TestVirtual.py
lldb/trunk/packages/Python/lldbsuite/test/lldbtest.py
lldb/trunk/scripts/Python/python-typemaps.swig

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/process_launch/TestProcessLaunch.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/process_launch/TestProcessLaunch.py?rev=253487&r1=253486&r2=253487&view=diff
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/process_launch/TestProcessLaunch.py
 (original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/process_launch/TestProcessLaunch.py
 Wed Nov 18 12:40:16 2015
@@ -192,10 +192,16 @@ class ProcessLaunchTestCase(TestBase):
 process = target.LaunchSimple(None, ['EVIL=' + evil_var], 
self.get_process_working_directory())
 self.assertEqual(process.GetState(), lldb.eStateExited, PROCESS_EXITED)
 
-out = process.GetSTDOUT(len(evil_var))[:len(evil_var)]
+out = process.GetSTDOUT(len(evil_var))
+self.assertIsNotNone(out, "Encountered an error reading the process's 
output")
+
+out = out[:len(evil_var)]
 if out != evil_var:
 self.fail('The environment variable was mis-coded: %s\n' % 
repr(out))
 
-newline = process.GetSTDOUT(1)[0]
+newline = process.GetSTDOUT(1)
+self.assertIsNotNone(newline, "Encountered an error reading the 
process's output")
+
+newline = newline[0]
 if newline != '\r' and newline != '\n':
 self.fail('Garbage at end of environment variable')

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/virtual/TestVirtual.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/virtual/TestVirtual.py?rev=253487&r1=253486&r2=253487&view=diff
==
--- lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/virtual/TestVirtual.py 
(original)
+++ lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/virtual/TestVirtual.py 
Wed Nov 18 12:40:16 2015
@@ -32,6 +32,7 @@ class CppVirtualMadness(TestBase):
 self.line = line_number(self.source, '// Set first breakpoint here.')
 
 @expectedFailureIcc('llvm.org/pr16808') # lldb does not call the correct 
virtual function with icc
+@expectedFailureAll(oslist=['windows'])
 def test_virtual_madness(self):
 """Test that expression works correctly with virtual inheritance as 
well as virtual function."""
 self.build()
@@ -60,6 +61,8 @@ class CppVirtualMadness(TestBase):
 # series of printf statements.
 stdout = process.GetSTDOUT(1024)
 
+self.assertIsNotNone(stdout, "Encountered an error reading the 
process's output")
+
 # This golden list contains a list of "my_expr = 'value' pairs 
extracted
 # from the golden output.
 gl = []

Modified: lldb/trunk/packages/Python/lldbsuite/test/lldbtest.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/lldbtest.py?rev=253487&r1=253486&r2=253487&view=diff
==
--- lldb/trunk/packages/Python/lldbsuite/test/lldbtest.py (original)
+++ lldb/trunk/packages/Python/lldbsuite/test/lldbtest.py Wed Nov 18 12:40:16 
2015
@@ -388,7 +388,7 @@ def system(commands, **kwargs):
 raise ValueError('stdout argument not allowed, it will be 
overridden.')
 if 'shell' in kwargs and kwargs['shell']==False:
 raise ValueError('shell=False not allowed')
-process = Popen(shellCommand, stdout=PIPE, stderr=PIPE, shell=True, 
**kwargs)
+process = Popen(shellCommand, stdout=PIPE, stderr=PIPE, shell=Tr

Re: [Lldb-commits] [lldb] r253478 - Switched cmake build from using buildSwigWrapperClases.py to the cleaned up version.

[Todd Fiala via lldb-commits]

Ah okay.

Hey is the "use the python 3.5 from python.org" path on Windows (including
tests) try-able at this time?

-Todd

On Wed, Nov 18, 2015 at 10:37 AM, Zachary Turner  wrote:

> Yea, this is the right one.  Thanks!  I haven't tested this yet, but I
> will later.  (Our buildbot currently builds with LLDB_DISABLE_PYTHON=1, so
> if there is a problem with this, the Windows buildbot wouldn't pick it up,
> although the others probably would)
>
> On Wed, Nov 18, 2015 at 10:14 AM Todd Fiala  wrote:
>
>> If I have that right, we're fine.  The prepare_bindings.py still calls
>> modify-python-lldb.py.
>>
>> scripts/prepare_bindings.py is meant to be the same as
>> createSwigBindings.py, and scripts/python/prepare_binding_Python.py is
>> meant to be the same as buildSwigPython.py.
>>
>> Once I make sure that I haven't broken anything for anybody with it, I'll
>> get rid of the other scripts.
>>
>> On Wed, Nov 18, 2015 at 10:09 AM, Todd Fiala 
>> wrote:
>>
>>> You're talking about this change, right?  (I'm looking at it now...)
>>>
>>> commit cc353bbc992ab324aef395c54a2a46fcaaa3855b
>>> Author: Zachary Turner 
>>> Date:   Mon Nov 16 22:40:20 2015 +
>>>
>>> Insert the SWIG version into LLDB's __init__.py
>>>
>>> The goal here is to allow us to add skip / xfail decorators
>>> based on SWIG version.
>>>
>>> git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@253262
>>> 91177308-0d34-0410-b5e6-96231b3b80d8
>>>
>>>
>>> On Wed, Nov 18, 2015 at 10:07 AM, Todd Fiala 
>>> wrote:
>>>
 Double checking now, if it happens in that lldb-modify script, we're
 covered.  Otherwise I need to adjust...  (the bulk of the rewrite happened
 on Friday/Sunday).

 On Wed, Nov 18, 2015 at 9:47 AM, Zachary Turner 
 wrote:

> Just to be sure, did you catch the change I made to the old scripts in
> the past few days to embed the swig version in the generated lldb.py?
> Maybe you did, I just want to make sure that change is in your new 
> version.
>
> On Wed, Nov 18, 2015 at 9:38 AM Todd Fiala via lldb-commits <
> lldb-commits@lists.llvm.org> wrote:
>
>> Author: tfiala
>> Date: Wed Nov 18 11:36:15 2015
>> New Revision: 253478
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=253478&view=rev
>> Log:
>> Switched cmake build from using buildSwigWrapperClases.py to the
>> cleaned up version.
>>
>> This change does not introduce static bindings.  It is simply using
>> the pylinted cleaned up code in prepare_bindings.py.
>>
>> If this breaks anyting, I'll revert immediately and figure out what
>> needs to be addressed.  I'm looking to wrap up
>> the cleanup aspect of the code change (pylinted, removal of code that
>> implements existing python stdlib code, fixes for Xcode adoption,
>> etc.).
>>
>> Modified:
>> lldb/trunk/CMakeLists.txt
>> lldb/trunk/scripts/CMakeLists.txt
>>
>> Modified: lldb/trunk/CMakeLists.txt
>> URL:
>> http://llvm.org/viewvc/llvm-project/lldb/trunk/CMakeLists.txt?rev=253478&r1=253477&r2=253478&view=diff
>>
>> ==
>> --- lldb/trunk/CMakeLists.txt (original)
>> +++ lldb/trunk/CMakeLists.txt Wed Nov 18 11:36:15 2015
>> @@ -33,6 +33,7 @@ if (NOT LLDB_DISABLE_PYTHON)
>>  add_custom_target( finish_swig ALL
>>  COMMAND ${PYTHON_EXECUTABLE}
>> ${CMAKE_CURRENT_SOURCE_DIR}/scripts/finishSwigWrapperClasses.py
>> "--srcRoot=${LLDB_SOURCE_DIR}"
>> "--targetDir=${CMAKE_CURRENT_BINARY_DIR}/scripts"
>> "--cfgBldDir=${CMAKE_CURRENT_BINARY_DIR}/scripts"
>> "--prefix=${CMAKE_BINARY_DIR}"
>> "--cmakeBuildConfiguration=${CMAKE_CFG_INTDIR}" -m
>>  DEPENDS
>> ${CMAKE_CURRENT_SOURCE_DIR}/scripts/finishSwigWrapperClasses.py
>> +DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/lldb.py
>>  COMMENT "Python script sym-linking LLDB Python API")
>>  # We depend on liblldb being built before we can do this step.
>>  add_dependencies(finish_swig liblldb lldb-argdumper)
>>
>> Modified: lldb/trunk/scripts/CMakeLists.txt
>> URL:
>> http://llvm.org/viewvc/llvm-project/lldb/trunk/scripts/CMakeLists.txt?rev=253478&r1=253477&r2=253478&view=diff
>>
>> ==
>> --- lldb/trunk/scripts/CMakeLists.txt (original)
>> +++ lldb/trunk/scripts/CMakeLists.txt Wed Nov 18 11:36:15 2015
>> @@ -18,9 +18,10 @@ add_custom_command(
>>DEPENDS ${SWIG_HEADERS}
>>DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/Python/buildSwigPython.py
>>DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/Python/modify-python-lldb.py
>> -  COMMAND ${PYTHON_EXECUTABLE}
>> ${CMAKE_CURRENT_SOURCE_DIR}/buildSwigWrapperClasses.py
>> "--srcRoot=${LLDB_SOURCE_DIR}" "--targetDir=${CMAKE_CURRENT_BINARY_DIR}"
>> "--cfgBldDir=${C

Re: [Lldb-commits] [lldb] r253478 - Switched cmake build from using buildSwigWrapperClases.py to the cleaned up version.

[Todd Fiala via lldb-commits]

On Wed, Nov 18, 2015 at 10:58 AM, Todd Fiala  wrote:

> Ah okay.
>

(I thought that was too easy ;-) )


>
> Hey is the "use the python 3.5 from python.org" path on Windows
> (including tests) try-able at this time?
>
> -Todd
>
> On Wed, Nov 18, 2015 at 10:37 AM, Zachary Turner 
> wrote:
>
>> Yea, this is the right one.  Thanks!  I haven't tested this yet, but I
>> will later.  (Our buildbot currently builds with LLDB_DISABLE_PYTHON=1, so
>> if there is a problem with this, the Windows buildbot wouldn't pick it up,
>> although the others probably would)
>>
>> On Wed, Nov 18, 2015 at 10:14 AM Todd Fiala  wrote:
>>
>>> If I have that right, we're fine.  The prepare_bindings.py still calls
>>> modify-python-lldb.py.
>>>
>>> scripts/prepare_bindings.py is meant to be the same as
>>> createSwigBindings.py, and scripts/python/prepare_binding_Python.py is
>>> meant to be the same as buildSwigPython.py.
>>>
>>> Once I make sure that I haven't broken anything for anybody with it,
>>> I'll get rid of the other scripts.
>>>
>>> On Wed, Nov 18, 2015 at 10:09 AM, Todd Fiala 
>>> wrote:
>>>
 You're talking about this change, right?  (I'm looking at it now...)

 commit cc353bbc992ab324aef395c54a2a46fcaaa3855b
 Author: Zachary Turner 
 Date:   Mon Nov 16 22:40:20 2015 +

 Insert the SWIG version into LLDB's __init__.py

 The goal here is to allow us to add skip / xfail decorators
 based on SWIG version.

 git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@253262
 91177308-0d34-0410-b5e6-96231b3b80d8


 On Wed, Nov 18, 2015 at 10:07 AM, Todd Fiala 
 wrote:

> Double checking now, if it happens in that lldb-modify script, we're
> covered.  Otherwise I need to adjust...  (the bulk of the rewrite happened
> on Friday/Sunday).
>
> On Wed, Nov 18, 2015 at 9:47 AM, Zachary Turner 
> wrote:
>
>> Just to be sure, did you catch the change I made to the old scripts
>> in the past few days to embed the swig version in the generated lldb.py?
>> Maybe you did, I just want to make sure that change is in your new 
>> version.
>>
>> On Wed, Nov 18, 2015 at 9:38 AM Todd Fiala via lldb-commits <
>> lldb-commits@lists.llvm.org> wrote:
>>
>>> Author: tfiala
>>> Date: Wed Nov 18 11:36:15 2015
>>> New Revision: 253478
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=253478&view=rev
>>> Log:
>>> Switched cmake build from using buildSwigWrapperClases.py to the
>>> cleaned up version.
>>>
>>> This change does not introduce static bindings.  It is simply using
>>> the pylinted cleaned up code in prepare_bindings.py.
>>>
>>> If this breaks anyting, I'll revert immediately and figure out what
>>> needs to be addressed.  I'm looking to wrap up
>>> the cleanup aspect of the code change (pylinted, removal of code that
>>> implements existing python stdlib code, fixes for Xcode adoption,
>>> etc.).
>>>
>>> Modified:
>>> lldb/trunk/CMakeLists.txt
>>> lldb/trunk/scripts/CMakeLists.txt
>>>
>>> Modified: lldb/trunk/CMakeLists.txt
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/lldb/trunk/CMakeLists.txt?rev=253478&r1=253477&r2=253478&view=diff
>>>
>>> ==
>>> --- lldb/trunk/CMakeLists.txt (original)
>>> +++ lldb/trunk/CMakeLists.txt Wed Nov 18 11:36:15 2015
>>> @@ -33,6 +33,7 @@ if (NOT LLDB_DISABLE_PYTHON)
>>>  add_custom_target( finish_swig ALL
>>>  COMMAND ${PYTHON_EXECUTABLE}
>>> ${CMAKE_CURRENT_SOURCE_DIR}/scripts/finishSwigWrapperClasses.py
>>> "--srcRoot=${LLDB_SOURCE_DIR}"
>>> "--targetDir=${CMAKE_CURRENT_BINARY_DIR}/scripts"
>>> "--cfgBldDir=${CMAKE_CURRENT_BINARY_DIR}/scripts"
>>> "--prefix=${CMAKE_BINARY_DIR}"
>>> "--cmakeBuildConfiguration=${CMAKE_CFG_INTDIR}" -m
>>>  DEPENDS
>>> ${CMAKE_CURRENT_SOURCE_DIR}/scripts/finishSwigWrapperClasses.py
>>> +DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/lldb.py
>>>  COMMENT "Python script sym-linking LLDB Python API")
>>>  # We depend on liblldb being built before we can do this step.
>>>  add_dependencies(finish_swig liblldb lldb-argdumper)
>>>
>>> Modified: lldb/trunk/scripts/CMakeLists.txt
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/lldb/trunk/scripts/CMakeLists.txt?rev=253478&r1=253477&r2=253478&view=diff
>>>
>>> ==
>>> --- lldb/trunk/scripts/CMakeLists.txt (original)
>>> +++ lldb/trunk/scripts/CMakeLists.txt Wed Nov 18 11:36:15 2015
>>> @@ -18,9 +18,10 @@ add_custom_command(
>>>DEPENDS ${SWIG_HEADERS}
>>>DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/Python/buildSwigPython.py
>>>DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/Python/modify-

Re: [Lldb-commits] [PATCH] D14765: Support unix-abstract-connect scheme as platform url in lldb testsuite

[Ying Chen via lldb-commits]

chying marked an inline comment as done.
chying added a comment.

http://reviews.llvm.org/D14765



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

[Lldb-commits] [lldb] r253488 - Support unix-abstract-connect scheme as platform url in lldb testsuite

[Ying Chen via lldb-commits]

Author: chying
Date: Wed Nov 18 13:03:20 2015
New Revision: 253488

URL: http://llvm.org/viewvc/llvm-project?rev=253488&view=rev
Log:
Support unix-abstract-connect scheme as platform url in lldb testsuite

Reviewers: ovyalov

Subscribers: lldb-commits

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

Modified:
lldb/trunk/packages/Python/lldbsuite/test/lldbtest.py

lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/gdbremote_testcase.py

Modified: lldb/trunk/packages/Python/lldbsuite/test/lldbtest.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/lldbtest.py?rev=253488&r1=253487&r2=253488&view=diff
==
--- lldb/trunk/packages/Python/lldbsuite/test/lldbtest.py (original)
+++ lldb/trunk/packages/Python/lldbsuite/test/lldbtest.py Wed Nov 18 13:03:20 
2015
@@ -461,8 +461,11 @@ def android_device_api():
 assert lldb.platform_url is not None
 device_id = None
 parsed_url = urlparse.urlparse(lldb.platform_url)
-if parsed_url.scheme == "adb":
-device_id = parsed_url.netloc.split(":")[0]
+host_name = parsed_url.netloc.split(":")[0]
+if host_name != 'localhost':
+device_id = host_name
+if device_id.startswith('[') and device_id.endswith(']'):
+device_id = device_id[1:-1]
 retcode, stdout, stderr = run_adb_command(
 ["shell", "getprop", "ro.build.version.sdk"], device_id)
 if retcode == 0:

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/gdbremote_testcase.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/gdbremote_testcase.py?rev=253488&r1=253487&r2=253488&view=diff
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/gdbremote_testcase.py
 (original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/gdbremote_testcase.py
 Wed Nov 18 13:03:20 2015
@@ -61,8 +61,12 @@ class GdbRemoteTestCaseBase(TestBase):
 self.named_pipe_fd = None
 self.stub_sends_two_stop_notifications_on_kill = False
 if lldb.platform_url:
-scheme, host = re.match('(.+)://(.+):\d+', 
lldb.platform_url).groups()
-if scheme == 'adb':
+if lldb.platform_url.startswith('unix-'):
+url_pattern = '(.+)://\[?(.+?)\]?/.*'
+else:
+url_pattern = '(.+)://(.+):\d+'
+scheme, host = re.match(url_pattern, lldb.platform_url).groups()
+if lldb.remote_platform_name == 'remote-android' and host != 
'localhost':
 self.stub_device = host
 self.stub_hostname = 'localhost'
 else:


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

Re: [Lldb-commits] [PATCH] D14765: Support unix-abstract-connect scheme as platform url in lldb testsuite

[Ying Chen via lldb-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL253488: Support unix-abstract-connect scheme as platform url 
in lldb testsuite (authored by chying).

Changed prior to commit:
  http://reviews.llvm.org/D14765?vs=40469&id=40535#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D14765

Files:
  lldb/trunk/packages/Python/lldbsuite/test/lldbtest.py
  
lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/gdbremote_testcase.py

Index: lldb/trunk/packages/Python/lldbsuite/test/lldbtest.py
===
--- lldb/trunk/packages/Python/lldbsuite/test/lldbtest.py
+++ lldb/trunk/packages/Python/lldbsuite/test/lldbtest.py
@@ -461,8 +461,11 @@
 assert lldb.platform_url is not None
 device_id = None
 parsed_url = urlparse.urlparse(lldb.platform_url)
-if parsed_url.scheme == "adb":
-device_id = parsed_url.netloc.split(":")[0]
+host_name = parsed_url.netloc.split(":")[0]
+if host_name != 'localhost':
+device_id = host_name
+if device_id.startswith('[') and device_id.endswith(']'):
+device_id = device_id[1:-1]
 retcode, stdout, stderr = run_adb_command(
 ["shell", "getprop", "ro.build.version.sdk"], device_id)
 if retcode == 0:
Index: 
lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/gdbremote_testcase.py
===
--- 
lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/gdbremote_testcase.py
+++ 
lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/gdbremote_testcase.py
@@ -61,8 +61,12 @@
 self.named_pipe_fd = None
 self.stub_sends_two_stop_notifications_on_kill = False
 if lldb.platform_url:
-scheme, host = re.match('(.+)://(.+):\d+', 
lldb.platform_url).groups()
-if scheme == 'adb':
+if lldb.platform_url.startswith('unix-'):
+url_pattern = '(.+)://\[?(.+?)\]?/.*'
+else:
+url_pattern = '(.+)://(.+):\d+'
+scheme, host = re.match(url_pattern, lldb.platform_url).groups()
+if lldb.remote_platform_name == 'remote-android' and host != 
'localhost':
 self.stub_device = host
 self.stub_hostname = 'localhost'
 else:


Index: lldb/trunk/packages/Python/lldbsuite/test/lldbtest.py
===
--- lldb/trunk/packages/Python/lldbsuite/test/lldbtest.py
+++ lldb/trunk/packages/Python/lldbsuite/test/lldbtest.py
@@ -461,8 +461,11 @@
 assert lldb.platform_url is not None
 device_id = None
 parsed_url = urlparse.urlparse(lldb.platform_url)
-if parsed_url.scheme == "adb":
-device_id = parsed_url.netloc.split(":")[0]
+host_name = parsed_url.netloc.split(":")[0]
+if host_name != 'localhost':
+device_id = host_name
+if device_id.startswith('[') and device_id.endswith(']'):
+device_id = device_id[1:-1]
 retcode, stdout, stderr = run_adb_command(
 ["shell", "getprop", "ro.build.version.sdk"], device_id)
 if retcode == 0:
Index: lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/gdbremote_testcase.py
===
--- lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/gdbremote_testcase.py
+++ lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/gdbremote_testcase.py
@@ -61,8 +61,12 @@
 self.named_pipe_fd = None
 self.stub_sends_two_stop_notifications_on_kill = False
 if lldb.platform_url:
-scheme, host = re.match('(.+)://(.+):\d+', lldb.platform_url).groups()
-if scheme == 'adb':
+if lldb.platform_url.startswith('unix-'):
+url_pattern = '(.+)://\[?(.+?)\]?/.*'
+else:
+url_pattern = '(.+)://(.+):\d+'
+scheme, host = re.match(url_pattern, lldb.platform_url).groups()
+if lldb.remote_platform_name == 'remote-android' and host != 'localhost':
 self.stub_device = host
 self.stub_hostname = 'localhost'
 else:
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [lldb-dev] [lldb] r253317 - Add Pythonic language binding wrapper generation script.

[Enrico Granata via lldb-commits]

> On Nov 18, 2015, at 10:34 AM, Zachary Turner via lldb-dev 
>  wrote:
> 
> 
> 
> On Wed, Nov 18, 2015 at 10:00 AM Todd Fiala  > wrote:
> Checking in the static bindings is no different than projects checking in 
> autoconf config baked scripts so that the vast majority of people don't need 
> to run autoconf just to get a setup that rarely changes.  There is precedent 
> for this going back a long way on open source projects.
> 
> I'm backing off having anyone else use them if they don't want, and we 
> (Apple) will keep those up to date.  Nobody else will use them.  Totally fine.
> 
> On the swig-as-a-service front, I think the idea is interesting but there are 
> several practical holes with that:
> 
> * What does one do when the server is unavailable?  Needs to be a local-only 
> backup.  So whatever service that provides isn't a guaranteed working 
> solution (think on an airplane, network outage, other server outage, etc.)
> 
> * Security: building code that has other code injected in it by another 
> server. Safe? Attack vector?  I could argue so is a git/svn repo susceptible 
> to this, so maybe this isn't a huge deal, but it's big enough and smells 
> enough like "introduce random unvetted code that can't be reviewed as easily 
> as a VCS tag" that I doubt we would ever use this in practice.
> 
> * Security 2: what is the service really running?  Not obvious on the build 
> machine accessing the service.
> The end result of the service is a copy of LLDBWrapPython.cpp and lldb.py 
> that you check into the repo.  You still have a chance to diff this source 
> code against the repository's copy before committing, same as you would if 
> you had swig locally.  Vast majority of changes to SB interfaces are going to 
> be the addition of a couple methods, or maybe a class, and the diff should be 
> very easy to look at and understand.
>  
> 
> > In all of these cases (except the proposed), the matrix choices are 
> > justifiable because they are there to support a hard requirement of 
> > someone's environment, and I do not think we should grow for anything that 
> > is not also a hard requirement of someone's environment.  
> 
> I'm going to call that overreaching.  We are not in the business of dictating 
> that one of the developers of the code "should not do something unless there 
> is a hard requirement."
> I'm not saying you shouldn't do *anything* if there's not a hard requirement. 
>  I agree that's overreaching.  I'm saying we should not increase the number 
> of ways of doing *the same thing* unless there is a hard requirement.  
> Especially if one of the ways of doing the same thing exists solely to save 
> someone from running one command to install the package (sorry if I'm not 
> doing justice to how difficult it is on OSX, the last time I did something on 
> OSX it seemed fairly easy to install macports, and I thought it's a wildly 
> common thing for people to already have installed).  For example, wouldn't 
> people need to already have macports in order to install CMake -- a necessary 
> component of building LLVM?

CMake vends binary packages on OS X, along with installation instructions, so 
actually, you don’t need hombrew to get CMake on OS X. On my work machines, I 
actually don’t have it installed at all.

>  
>  Apple wants to eliminate the need for people to *require* swig.  The goal 
> there is reducing the build requirements for the average person building 
> lldb, not growing it.
> I agree, which is why it is so important to keep the number of different ways 
> of building to a minimum.  It's the same reason that the autoconf build is 
> being removed wholesale from LLVM and people have decided that CMake is the 
> one true way.  Because even if it isn't perfect for everyone, it works for 
> everyone.  And there is inherent simplicity in having fewer ways to do 
> things, as well as reducing maintenance cost.
>  
> 
> So for the more common, casual lldb build environment where the developer is 
> not touching SB API, help me understand how reducing the need for swig 
> (without introducing the need for hitting another server) is increasing the 
> requirement load?  (Especially if we --- our local dev group sitting by me 
> --- maintains those static bindings)?
> 
> Well, we would need to disable static bindings on the OSX buildbots for 
> starters, otherwise when someone not using static bindings makes a change, 
> the buildbots break, and we cannot leave buildbots in a broken state.  So I 
> assume that will still be possible.  So now you don't have a buildbot testing 
> the static binding configuration.  
> 
> Secondly, LLDB already has a problem (IMHO) of having too many things that 
> only work for a few people, instead of having things that work for everyone.  
> It's gotten better, and even your work right now to port the Xcode build over 
> to these new python scripts is helping to make that better.  So regardless of 
> the outcome her

Re: [Lldb-commits] [lldb-dev] [lldb] r253317 - Add Pythonic language binding wrapper generation script.

[Todd Fiala via lldb-commits]

On Wed, Nov 18, 2015 at 10:34 AM, Zachary Turner  wrote:

>
>
> On Wed, Nov 18, 2015 at 10:00 AM Todd Fiala  wrote:
>
>> Checking in the static bindings is no different than projects checking in
>> autoconf config baked scripts so that the vast majority of people don't
>> need to run autoconf just to get a setup that rarely changes.  There is
>> precedent for this going back a long way on open source projects.
>>
>> I'm backing off having anyone else use them if they don't want, and we
>> (Apple) will keep those up to date.  Nobody else will use them.  Totally
>> fine.
>>
>> On the swig-as-a-service front, I think the idea is interesting but there
>> are several practical holes with that:
>>
>> * What does one do when the server is unavailable?  Needs to be a
>> local-only backup.  So whatever service that provides isn't a guaranteed
>> working solution (think on an airplane, network outage, other server
>> outage, etc.)
>>
>
>> * Security: building code that has other code injected in it by another
>> server. Safe? Attack vector?  I could argue so is a git/svn repo
>> susceptible to this, so maybe this isn't a huge deal, but it's big enough
>> and smells enough like "introduce random unvetted code that can't be
>> reviewed as easily as a VCS tag" that I doubt we would ever use this in
>> practice.
>>
>> * Security 2: what is the service really running?  Not obvious on the
>> build machine accessing the service.
>>
> The end result of the service is a copy of LLDBWrapPython.cpp and lldb.py
> that you check into the repo.
>

Ah, I see.  That definitely sounds like an improvement from my
interpretation :-)


> You still have a chance to diff this source code against the repository's
> copy before committing, same as you would if you had swig locally.
>

Yeah, non-issue at that point.


> Vast majority of changes to SB interfaces are going to be the addition of
> a couple methods, or maybe a class, and the diff should be very easy to
> look at and understand.
>

Yes.


>
>
>>
>> > In all of these cases (except the proposed), the matrix choices are
>> justifiable because they are there to support a hard requirement of
>> someone's environment, and I do not think we should grow for anything that
>> is not also a hard requirement of someone's environment.
>>
>> I'm going to call that overreaching.  We are not in the business of
>> dictating that one of the developers of the code "should not do something
>> unless there is a hard requirement."
>>
> I'm not saying you shouldn't do *anything* if there's not a hard
> requirement.  I agree that's overreaching.  I'm saying we should not
> increase the number of ways of doing *the same thing* unless there is a
> hard requirement.  Especially if one of the ways of doing the same thing
> exists solely to save someone from running one command to install the
> package (sorry if I'm not doing justice to how difficult it is on OSX, the
> last time I did something on OSX it seemed fairly easy to install macports,
> and I thought it's a wildly common thing for people to already have
> installed).  For example, wouldn't people need to already have macports in
> order to install CMake -- a necessary component of building LLVM?
>

In the case of cmake, no. The cmake website provides a simple-to-add binary
that doesn't depend on anything else.  (Okay, I'm long winded here so
Enrico just beat me to the punch).

For swig, the solution is homebrew/macports.  The challenge with systems
like homebrew and macports is that they will install other packages that
are dependencies (sometimes build-time, sometimes runtime), typically get
them added to various paths, and (during the process), unintentionally hide
system libraries.  It is not uncommon for us to see crash reports on OS X
where Xcode or lldb is picking up the wrong python or other component that
was built by one of these package managers.  They're often good about
saying "this might cause trouble" in some obvious cases, but less so in
less obvious cases (like, a swig installing python bindings, which installs
a new shiny python, which hides the system one, which breaks the lldb
bindings).  It really is messier there.


>
>
>>  Apple wants to eliminate the need for people to *require* swig.  The
>> goal there is reducing the build requirements for the average person
>> building lldb, not growing it.
>>
> I agree, which is why it is so important to keep the number of different
> ways of building to a minimum.
>

Glad to hear the intent here.


>   It's the same reason that the autoconf build is being removed wholesale
> from LLVM and people have decided that CMake is the one true way.
>

(Coincidentally - I am in the process of trying to eliminate the old
make-swig-bindings.sh, which is still used by the Makefile/autoconf build
of lldb, and I saw the nice banner from llvm saying autoconf support is
going out for 3.9 while testing the replacement).


>   Because even if it isn't perfect for everyone, it works for everyone.
>

Unless

Re: [Lldb-commits] [lldb] r253478 - Switched cmake build from using buildSwigWrapperClases.py to the cleaned up version.

[Zachary Turner via lldb-commits]

yea.  Pass -DPYTHON_HOME=C:\Python35 to CMake and you're good to go.

I've still got about 20-30 tests failing and/or timing out, but I'm getting
close.

On Wed, Nov 18, 2015 at 10:58 AM Todd Fiala  wrote:

> Ah okay.
>
> Hey is the "use the python 3.5 from python.org" path on Windows
> (including tests) try-able at this time?
>
> -Todd
>
> On Wed, Nov 18, 2015 at 10:37 AM, Zachary Turner 
> wrote:
>
>> Yea, this is the right one.  Thanks!  I haven't tested this yet, but I
>> will later.  (Our buildbot currently builds with LLDB_DISABLE_PYTHON=1, so
>> if there is a problem with this, the Windows buildbot wouldn't pick it up,
>> although the others probably would)
>>
>> On Wed, Nov 18, 2015 at 10:14 AM Todd Fiala  wrote:
>>
>>> If I have that right, we're fine.  The prepare_bindings.py still calls
>>> modify-python-lldb.py.
>>>
>>> scripts/prepare_bindings.py is meant to be the same as
>>> createSwigBindings.py, and scripts/python/prepare_binding_Python.py is
>>> meant to be the same as buildSwigPython.py.
>>>
>>> Once I make sure that I haven't broken anything for anybody with it,
>>> I'll get rid of the other scripts.
>>>
>>> On Wed, Nov 18, 2015 at 10:09 AM, Todd Fiala 
>>> wrote:
>>>
 You're talking about this change, right?  (I'm looking at it now...)

 commit cc353bbc992ab324aef395c54a2a46fcaaa3855b
 Author: Zachary Turner 
 Date:   Mon Nov 16 22:40:20 2015 +

 Insert the SWIG version into LLDB's __init__.py

 The goal here is to allow us to add skip / xfail decorators
 based on SWIG version.

 git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@253262
 91177308-0d34-0410-b5e6-96231b3b80d8


 On Wed, Nov 18, 2015 at 10:07 AM, Todd Fiala 
 wrote:

> Double checking now, if it happens in that lldb-modify script, we're
> covered.  Otherwise I need to adjust...  (the bulk of the rewrite happened
> on Friday/Sunday).
>
> On Wed, Nov 18, 2015 at 9:47 AM, Zachary Turner 
> wrote:
>
>> Just to be sure, did you catch the change I made to the old scripts
>> in the past few days to embed the swig version in the generated lldb.py?
>> Maybe you did, I just want to make sure that change is in your new 
>> version.
>>
>> On Wed, Nov 18, 2015 at 9:38 AM Todd Fiala via lldb-commits <
>> lldb-commits@lists.llvm.org> wrote:
>>
>>> Author: tfiala
>>> Date: Wed Nov 18 11:36:15 2015
>>> New Revision: 253478
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=253478&view=rev
>>> Log:
>>> Switched cmake build from using buildSwigWrapperClases.py to the
>>> cleaned up version.
>>>
>>> This change does not introduce static bindings.  It is simply using
>>> the pylinted cleaned up code in prepare_bindings.py.
>>>
>>> If this breaks anyting, I'll revert immediately and figure out what
>>> needs to be addressed.  I'm looking to wrap up
>>> the cleanup aspect of the code change (pylinted, removal of code that
>>> implements existing python stdlib code, fixes for Xcode adoption,
>>> etc.).
>>>
>>> Modified:
>>> lldb/trunk/CMakeLists.txt
>>> lldb/trunk/scripts/CMakeLists.txt
>>>
>>> Modified: lldb/trunk/CMakeLists.txt
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/lldb/trunk/CMakeLists.txt?rev=253478&r1=253477&r2=253478&view=diff
>>>
>>> ==
>>> --- lldb/trunk/CMakeLists.txt (original)
>>> +++ lldb/trunk/CMakeLists.txt Wed Nov 18 11:36:15 2015
>>> @@ -33,6 +33,7 @@ if (NOT LLDB_DISABLE_PYTHON)
>>>  add_custom_target( finish_swig ALL
>>>  COMMAND ${PYTHON_EXECUTABLE}
>>> ${CMAKE_CURRENT_SOURCE_DIR}/scripts/finishSwigWrapperClasses.py
>>> "--srcRoot=${LLDB_SOURCE_DIR}"
>>> "--targetDir=${CMAKE_CURRENT_BINARY_DIR}/scripts"
>>> "--cfgBldDir=${CMAKE_CURRENT_BINARY_DIR}/scripts"
>>> "--prefix=${CMAKE_BINARY_DIR}"
>>> "--cmakeBuildConfiguration=${CMAKE_CFG_INTDIR}" -m
>>>  DEPENDS
>>> ${CMAKE_CURRENT_SOURCE_DIR}/scripts/finishSwigWrapperClasses.py
>>> +DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/lldb.py
>>>  COMMENT "Python script sym-linking LLDB Python API")
>>>  # We depend on liblldb being built before we can do this step.
>>>  add_dependencies(finish_swig liblldb lldb-argdumper)
>>>
>>> Modified: lldb/trunk/scripts/CMakeLists.txt
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/lldb/trunk/scripts/CMakeLists.txt?rev=253478&r1=253477&r2=253478&view=diff
>>>
>>> ==
>>> --- lldb/trunk/scripts/CMakeLists.txt (original)
>>> +++ lldb/trunk/scripts/CMakeLists.txt Wed Nov 18 11:36:15 2015
>>> @@ -18,9 +18,10 @@ add_custom_command(
>>>DEPENDS ${SWIG_HEADERS}
>>>DEPENDS ${

[Lldb-commits] [lldb] r253490 - remove defunct scripts/build-swig-wrapper-classes.sh; switch autoconf build to prepare_bindings.py.

[Todd Fiala via lldb-commits]

Author: tfiala
Date: Wed Nov 18 13:34:03 2015
New Revision: 253490

URL: http://llvm.org/viewvc/llvm-project?rev=253490&view=rev
Log:
remove defunct scripts/build-swig-wrapper-classes.sh; switch autoconf build to 
prepare_bindings.py.

Xcode moved off of build-swig-wrapper-classes.sh earlier this week.

Removed:
lldb/trunk/scripts/build-swig-wrapper-classes.sh
Modified:
lldb/trunk/source/Interpreter/Makefile

Removed: lldb/trunk/scripts/build-swig-wrapper-classes.sh
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/scripts/build-swig-wrapper-classes.sh?rev=253489&view=auto
==
--- lldb/trunk/scripts/build-swig-wrapper-classes.sh (original)
+++ lldb/trunk/scripts/build-swig-wrapper-classes.sh (removed)
@@ -1,151 +0,0 @@
-#!/bin/sh
-
-# build-swig-wrapper-classes.sh
-#
-# For each scripting language liblldb supports, we need to create the
-# appropriate Script Bridge wrapper classes for that language so that 
-# users can call Script Bridge functions from within the script interpreter.
-# 
-# We use SWIG to help create the appropriate wrapper classes/functions for
-# the scripting language.  In some cases the file generated by SWIG may
-# need some tweaking before it is completely ready to use.
-
-# Below are the arguments/parameters that this script takes (and passes along
-# to all the language-specific build scripts that it calls):
-#
-# SRC_ROOT is the root of the lldb source tree.
-# TARGET_DIR is where the lldb framework/shared library gets put.
-# CONFIG_BUILD_DIR is where the build-swig-Python-LLDB.sh  shell script 
-#   put the lldb.py file it was generated from running SWIG.
-# PREFIX is where non-Darwin systems want to put the .py and .so
-#   files so that Python can find them automatically.
-# debug_flag (optional) determines whether or not this script outputs 
-#   additional information when running.
-
-SRC_ROOT=$1
-TARGET_DIR=$2
-CONFIG_BUILD_DIR=$3
-PREFIX=$4
-
-shift 4
-
-#
-# Check to see if we are in debug-mode or not.
-#
-
-if [ -n "$1" -a "$1" = "-debug" ]
-then
-debug_flag="$1"
-Debug=1
-shift
-else
-debug_flag=""
-Debug=0
-fi
-
-#
-# Check to see if we were called from the Makefile system. If we were, check
-# if the caller wants swig to generate a dependency file.
-#
-
-if [ -n "$1" -a "$1" = "-m" ]
-then
-makefile_flag="$1"
-shift
-if [ -n "$1" -a "$1" = "-M" ]
-then
-dependency_flag="$1"
-shift
-else
-dependency_flag=""
-fi
-else
-makefile_flag=""
-dependency_flag=""
-fi
-
-#
-# Verify that 'lldb.swig' exists.
-#
-
-if [ ! -f ${SRC_ROOT}/scripts/lldb.swig ]
-then
-echo Error: unable to find file 'lldb.swig' >&2
-exit 1
-fi
-
-if [ $Debug -eq 1 ]
-then
-echo "Found lldb.swig file"
-fi
-
-#
-# Next look for swig
-#
-
-SWIG=`which swig`
-if [ ! -x "$SWIG" -a -f /usr/bin/swig ]
-then
-SWIG=/usr/bin/swig
-else
-if [ -f /usr/local/bin/swig ]
-then
-SWIG=/usr/local/bin/swig
-fi
-fi
-
-if [ ${SWIG}a = a ]
-then
-echo Error: could not find the swig binary
-exit 1
-fi
-
-#
-# For each scripting language, make sure the build script for that language
-# exists, and if so, call it.
-#
-# For now the only language we support is Python, but we expect this to
-# change.
-
-languages="Python"
-cwd=${SRC_ROOT}/scripts
-
-for curlang in $languages
-do
-if [ $Debug -eq 1 ]
-then
-echo "Current language is $curlang"
-fi
-
-if [ ! -d "$cwd/$curlang" ]
-then
-echo "Error:  unable to find $curlang script sub-dirctory" >&2
-continue
-else
-
-if [ $Debug -eq 1 ]
-then
-echo "Found $curlang sub-directory"
-fi
-
-cd $cwd/$curlang
-
-filename="./build-swig-${curlang}.sh"
-
-if [ ! -f $filename ]
-then
-echo "Error: unable to find swig build script for $curlang: 
$filename" >&2
-continue
-else
-
-if [ $Debug -eq 1 ]
-then
-echo "Found $curlang build script."
-echo "Executing $curlang build script..."
-fi
-
-./build-swig-${curlang}.sh  "$SRC_ROOT" "$TARGET_DIR" 
"$CONFIG_BUILD_DIR" "${PREFIX}" "${debug_flag}" "${SWIG}" "${makefile_flag}" 
"${dependency_flag}" || exit $?
-fi
-fi
-done
-

Modified: lldb/trunk/source/Interpreter/Makefile
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Interpreter/Makefile?rev=253490&r1=253489&r2=253490&view=diff
==
--- lldb/trunk/source/Interpreter/Makefile (original)
+++ lldb/trunk/source/Interpreter/Makefile Wed Nov 18 13:34:03 2015
@@ -39,12 +39,12 @@ LLDBWrapPython.cpp lldb.py: $(PROJ_SRC_D
 $(wildcard 
$(PROJ_SRC_DIR)/$(LLDB_LEVEL)/scripts/interface/*.i) \
 ${SWIG_SOURCES}
 

[Lldb-commits] [lldb] r253491 - Remove the scripts/Python/build-swig-Python.sh script.

[Todd Fiala via lldb-commits]

Author: tfiala
Date: Wed Nov 18 13:37:51 2015
New Revision: 253491

URL: http://llvm.org/viewvc/llvm-project?rev=253491&view=rev
Log:
Remove the scripts/Python/build-swig-Python.sh script.

This logically goes with my previous commit.

Removed:
lldb/trunk/scripts/Python/build-swig-Python.sh

Removed: lldb/trunk/scripts/Python/build-swig-Python.sh
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/scripts/Python/build-swig-Python.sh?rev=253490&view=auto
==
--- lldb/trunk/scripts/Python/build-swig-Python.sh (original)
+++ lldb/trunk/scripts/Python/build-swig-Python.sh (removed)
@@ -1,378 +0,0 @@
-#!/bin/sh
-
-# build-swig-Python.sh
-
-# SRC_ROOT is the root of the lldb source tree.
-# TARGET_DIR is where the lldb framework/shared library gets put.
-# CONFIG_BUILD_DIR is where the build-swig-Python-LLDB.sh  shell script
-#   put the lldb.py file it was generated from running SWIG.
-# PREFIX is the root directory used to determine where third-party modules
-# for scripting languages should be installed.
-# debug_flag (optional) determines whether or not this script outputs
-#   additional information when running.
-
-SRC_ROOT=$1
-TARGET_DIR=$2
-CONFIG_BUILD_DIR=$3
-PYTHON_INSTALL_DIR=$4
-debug_flag=$5
-SWIG=$6
-makefile_flag=$7
-dependency_flag=$8
-
-PYTHON=${PYTHON_EXECUTABLE:-/usr/bin/env python}
-
-if [ -n "$makefile_flag" -a "$makefile_flag" = "-m" ]
-then
-MakefileCalled=1
-if [ -n "$dependency_flag" -a "$dependency_flag" = "-M" ]
-then
-GenerateDependencies=1
-swig_depend_file="${TARGET_DIR}/LLDBWrapPython.cpp.d"
-SWIG_DEPEND_OPTIONS="-MMD -MF \"${swig_depend_file}.tmp\""
-else
-GenerateDependencies=0
-fi
-else
-MakefileCalled=0
-GenerateDependencies=0
-fi
-
-swig_output_file=${TARGET_DIR}/LLDBWrapPython.cpp
-swig_input_file=${SRC_ROOT}/scripts/lldb.swig
-swig_python_extensions=${SRC_ROOT}/scripts/Python/python-extensions.swig
-swig_python_wrapper=${SRC_ROOT}/scripts/Python/python-wrapper.swig
-swig_python_typemaps=${SRC_ROOT}/scripts/Python/python-typemaps.swig
-swig_python_swigsafecast=${SRC_ROOT}/scripts/Python/python-swigsafecast.swig
-
-if [ "$LLDB_DISABLE_PYTHON" = "1" ] ; then
-# We don't want Python for this build, but touch the output file so we 
don't have to
-# conditionalize the build on this as well.
-# Note, at present iOS doesn't have Python, so if you're building for iOS 
be sure to
-# set LLDB_DISABLE_PYTHON to 1.
-rm -rf ${swig_output_file}
-touch ${swig_output_file}
-
-else
-
-if [ -n "$debug_flag" -a "$debug_flag" = "-debug" ]
-then
-Debug=1
-else
-Debug=0
-fi
-
-# If this project is being built with LLDB_DISABLE_PYTHON defined,
-# don't bother generating Python swig bindings -- we don't have
-# Python available.
-
-if echo $GCC_PREPROCESSOR_DEFINITIONS | grep LLDB_DISABLE_PYTHON
-then
-  echo "" > "${swig_output_file}"
-  exit 0
-fi
-
-HEADER_FILES="${SRC_ROOT}/include/lldb/lldb.h"\
-" ${SRC_ROOT}/include/lldb/lldb-defines.h"\
-" ${SRC_ROOT}/include/lldb/lldb-enumerations.h"\
-" ${SRC_ROOT}/include/lldb/lldb-forward.h"\
-" ${SRC_ROOT}/include/lldb/lldb-forward-rtti.h"\
-" ${SRC_ROOT}/include/lldb/lldb-types.h"\
-" ${SRC_ROOT}/include/lldb/API/SBAddress.h"\
-" ${SRC_ROOT}/include/lldb/API/SBAttachInfo.h"\
-" ${SRC_ROOT}/include/lldb/API/SBBlock.h"\
-" ${SRC_ROOT}/include/lldb/API/SBBreakpoint.h"\
-" ${SRC_ROOT}/include/lldb/API/SBBreakpointLocation.h"\
-" ${SRC_ROOT}/include/lldb/API/SBBroadcaster.h"\
-" ${SRC_ROOT}/include/lldb/API/SBCommandInterpreter.h"\
-" ${SRC_ROOT}/include/lldb/API/SBCommandReturnObject.h"\
-" ${SRC_ROOT}/include/lldb/API/SBCommunication.h"\
-" ${SRC_ROOT}/include/lldb/API/SBCompileUnit.h"\
-" ${SRC_ROOT}/include/lldb/API/SBData.h"\
-" ${SRC_ROOT}/include/lldb/API/SBDebugger.h"\
-" ${SRC_ROOT}/include/lldb/API/SBError.h"\
-" ${SRC_ROOT}/include/lldb/API/SBEvent.h"\
-" ${SRC_ROOT}/include/lldb/API/SBExecutionContext.h"\
-" ${SRC_ROOT}/include/lldb/API/SBExpressionOptions.h"\
-" ${SRC_ROOT}/include/lldb/API/SBFileSpec.h"\
-" ${SRC_ROOT}/include/lldb/API/SBFrame.h"\
-" ${SRC_ROOT}/include/lldb/API/SBFunction.h"\
-" ${SRC_ROOT}/include/lldb/API/SBHostOS.h"\
-" ${SRC_ROOT}/include/lldb/API/SBInstruction.h"\
-" ${SRC_ROOT}/include/lldb/API/SBInstructionList.h"\
-" ${SRC_ROOT}/include/lldb/API/SBLanguageRuntime.h"\
-" ${SRC_ROOT}/include/lldb/API/SBLaunchInfo.h"\
-" ${SRC_ROOT}/include/lldb/API/SBLineEntry.h"\
-" ${SRC_ROOT}/include/lldb/API/SBListener.h"\
-" ${SRC_ROOT}/include/lldb/API/SBModule.h"\
-" ${SRC_ROOT}/include/lldb/API/SBModuleSpec.h"\
-" ${SRC_ROOT}/include/lldb/API/SBProcess.h"\
-" ${SRC_ROOT}/include/lldb/API/SBQueue.h"\
-" ${SRC_ROOT}/include/lldb/API/SBQueueItem.h"\
-" ${SRC_ROOT}/include/lldb/API/SBSourceManager.h"\
-" ${SRC_ROOT}/include/lldb/API/SBStream.h"\
-" ${SRC_ROOT}/include/lldb/API/SBStringList.h"\
-" ${SRC_ROOT}/include/lldb/API/SBSymbol.h"\
-"

Re: [Lldb-commits] [lldb] r253478 - Switched cmake build from using buildSwigWrapperClases.py to the cleaned up version.

[Todd Fiala via lldb-commits]

That's great, Zachary!

Cool.  Makes it easier to make sure I'm not breaking stuff.

On Wed, Nov 18, 2015 at 11:07 AM, Zachary Turner  wrote:

> yea.  Pass -DPYTHON_HOME=C:\Python35 to CMake and you're good to go.
>
> I've still got about 20-30 tests failing and/or timing out, but I'm
> getting close.
>
>
> On Wed, Nov 18, 2015 at 10:58 AM Todd Fiala  wrote:
>
>> Ah okay.
>>
>> Hey is the "use the python 3.5 from python.org" path on Windows
>> (including tests) try-able at this time?
>>
>> -Todd
>>
>> On Wed, Nov 18, 2015 at 10:37 AM, Zachary Turner 
>> wrote:
>>
>>> Yea, this is the right one.  Thanks!  I haven't tested this yet, but I
>>> will later.  (Our buildbot currently builds with LLDB_DISABLE_PYTHON=1, so
>>> if there is a problem with this, the Windows buildbot wouldn't pick it up,
>>> although the others probably would)
>>>
>>> On Wed, Nov 18, 2015 at 10:14 AM Todd Fiala 
>>> wrote:
>>>
 If I have that right, we're fine.  The prepare_bindings.py still calls
 modify-python-lldb.py.

 scripts/prepare_bindings.py is meant to be the same as
 createSwigBindings.py, and scripts/python/prepare_binding_Python.py is
 meant to be the same as buildSwigPython.py.

 Once I make sure that I haven't broken anything for anybody with it,
 I'll get rid of the other scripts.

 On Wed, Nov 18, 2015 at 10:09 AM, Todd Fiala 
 wrote:

> You're talking about this change, right?  (I'm looking at it now...)
>
> commit cc353bbc992ab324aef395c54a2a46fcaaa3855b
> Author: Zachary Turner 
> Date:   Mon Nov 16 22:40:20 2015 +
>
> Insert the SWIG version into LLDB's __init__.py
>
> The goal here is to allow us to add skip / xfail decorators
> based on SWIG version.
>
> git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@253262
> 91177308-0d34-0410-b5e6-96231b3b80d8
>
>
> On Wed, Nov 18, 2015 at 10:07 AM, Todd Fiala 
> wrote:
>
>> Double checking now, if it happens in that lldb-modify script, we're
>> covered.  Otherwise I need to adjust...  (the bulk of the rewrite 
>> happened
>> on Friday/Sunday).
>>
>> On Wed, Nov 18, 2015 at 9:47 AM, Zachary Turner 
>> wrote:
>>
>>> Just to be sure, did you catch the change I made to the old scripts
>>> in the past few days to embed the swig version in the generated lldb.py?
>>> Maybe you did, I just want to make sure that change is in your new 
>>> version.
>>>
>>> On Wed, Nov 18, 2015 at 9:38 AM Todd Fiala via lldb-commits <
>>> lldb-commits@lists.llvm.org> wrote:
>>>
 Author: tfiala
 Date: Wed Nov 18 11:36:15 2015
 New Revision: 253478

 URL: http://llvm.org/viewvc/llvm-project?rev=253478&view=rev
 Log:
 Switched cmake build from using buildSwigWrapperClases.py to the
 cleaned up version.

 This change does not introduce static bindings.  It is simply using
 the pylinted cleaned up code in prepare_bindings.py.

 If this breaks anyting, I'll revert immediately and figure out what
 needs to be addressed.  I'm looking to wrap up
 the cleanup aspect of the code change (pylinted, removal of code
 that
 implements existing python stdlib code, fixes for Xcode adoption,
 etc.).

 Modified:
 lldb/trunk/CMakeLists.txt
 lldb/trunk/scripts/CMakeLists.txt

 Modified: lldb/trunk/CMakeLists.txt
 URL:
 http://llvm.org/viewvc/llvm-project/lldb/trunk/CMakeLists.txt?rev=253478&r1=253477&r2=253478&view=diff

 ==
 --- lldb/trunk/CMakeLists.txt (original)
 +++ lldb/trunk/CMakeLists.txt Wed Nov 18 11:36:15 2015
 @@ -33,6 +33,7 @@ if (NOT LLDB_DISABLE_PYTHON)
  add_custom_target( finish_swig ALL
  COMMAND ${PYTHON_EXECUTABLE}
 ${CMAKE_CURRENT_SOURCE_DIR}/scripts/finishSwigWrapperClasses.py
 "--srcRoot=${LLDB_SOURCE_DIR}"
 "--targetDir=${CMAKE_CURRENT_BINARY_DIR}/scripts"
 "--cfgBldDir=${CMAKE_CURRENT_BINARY_DIR}/scripts"
 "--prefix=${CMAKE_BINARY_DIR}"
 "--cmakeBuildConfiguration=${CMAKE_CFG_INTDIR}" -m
  DEPENDS
 ${CMAKE_CURRENT_SOURCE_DIR}/scripts/finishSwigWrapperClasses.py
 +DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/lldb.py
  COMMENT "Python script sym-linking LLDB Python API")
  # We depend on liblldb being built before we can do this step.
  add_dependencies(finish_swig liblldb lldb-argdumper)

 Modified: lldb/trunk/scripts/CMakeLists.txt
 URL:
 http://llvm.org/viewvc/llvm-project/lldb/trunk/scripts/CMakeLists.txt?rev=253478&r1=253477&r2=253478&view=diff

 

Re: [Lldb-commits] [lldb] r253478 - Switched cmake build from using buildSwigWrapperClases.py to the cleaned up version.

[Todd Fiala via lldb-commits]

And that works with VS 2015, and VS 2015 only, right?

On Wed, Nov 18, 2015 at 11:41 AM, Todd Fiala  wrote:

> That's great, Zachary!
>
> Cool.  Makes it easier to make sure I'm not breaking stuff.
>
> On Wed, Nov 18, 2015 at 11:07 AM, Zachary Turner 
> wrote:
>
>> yea.  Pass -DPYTHON_HOME=C:\Python35 to CMake and you're good to go.
>>
>> I've still got about 20-30 tests failing and/or timing out, but I'm
>> getting close.
>>
>>
>> On Wed, Nov 18, 2015 at 10:58 AM Todd Fiala  wrote:
>>
>>> Ah okay.
>>>
>>> Hey is the "use the python 3.5 from python.org" path on Windows
>>> (including tests) try-able at this time?
>>>
>>> -Todd
>>>
>>> On Wed, Nov 18, 2015 at 10:37 AM, Zachary Turner 
>>> wrote:
>>>
 Yea, this is the right one.  Thanks!  I haven't tested this yet, but I
 will later.  (Our buildbot currently builds with LLDB_DISABLE_PYTHON=1, so
 if there is a problem with this, the Windows buildbot wouldn't pick it up,
 although the others probably would)

 On Wed, Nov 18, 2015 at 10:14 AM Todd Fiala 
 wrote:

> If I have that right, we're fine.  The prepare_bindings.py still calls
> modify-python-lldb.py.
>
> scripts/prepare_bindings.py is meant to be the same as
> createSwigBindings.py, and scripts/python/prepare_binding_Python.py is
> meant to be the same as buildSwigPython.py.
>
> Once I make sure that I haven't broken anything for anybody with it,
> I'll get rid of the other scripts.
>
> On Wed, Nov 18, 2015 at 10:09 AM, Todd Fiala 
> wrote:
>
>> You're talking about this change, right?  (I'm looking at it now...)
>>
>> commit cc353bbc992ab324aef395c54a2a46fcaaa3855b
>> Author: Zachary Turner 
>> Date:   Mon Nov 16 22:40:20 2015 +
>>
>> Insert the SWIG version into LLDB's __init__.py
>>
>> The goal here is to allow us to add skip / xfail decorators
>> based on SWIG version.
>>
>> git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@253262
>> 91177308-0d34-0410-b5e6-96231b3b80d8
>>
>>
>> On Wed, Nov 18, 2015 at 10:07 AM, Todd Fiala 
>> wrote:
>>
>>> Double checking now, if it happens in that lldb-modify script, we're
>>> covered.  Otherwise I need to adjust...  (the bulk of the rewrite 
>>> happened
>>> on Friday/Sunday).
>>>
>>> On Wed, Nov 18, 2015 at 9:47 AM, Zachary Turner 
>>> wrote:
>>>
 Just to be sure, did you catch the change I made to the old scripts
 in the past few days to embed the swig version in the generated 
 lldb.py?
 Maybe you did, I just want to make sure that change is in your new 
 version.

 On Wed, Nov 18, 2015 at 9:38 AM Todd Fiala via lldb-commits <
 lldb-commits@lists.llvm.org> wrote:

> Author: tfiala
> Date: Wed Nov 18 11:36:15 2015
> New Revision: 253478
>
> URL: http://llvm.org/viewvc/llvm-project?rev=253478&view=rev
> Log:
> Switched cmake build from using buildSwigWrapperClases.py to the
> cleaned up version.
>
> This change does not introduce static bindings.  It is simply using
> the pylinted cleaned up code in prepare_bindings.py.
>
> If this breaks anyting, I'll revert immediately and figure out what
> needs to be addressed.  I'm looking to wrap up
> the cleanup aspect of the code change (pylinted, removal of code
> that
> implements existing python stdlib code, fixes for Xcode adoption,
> etc.).
>
> Modified:
> lldb/trunk/CMakeLists.txt
> lldb/trunk/scripts/CMakeLists.txt
>
> Modified: lldb/trunk/CMakeLists.txt
> URL:
> http://llvm.org/viewvc/llvm-project/lldb/trunk/CMakeLists.txt?rev=253478&r1=253477&r2=253478&view=diff
>
> ==
> --- lldb/trunk/CMakeLists.txt (original)
> +++ lldb/trunk/CMakeLists.txt Wed Nov 18 11:36:15 2015
> @@ -33,6 +33,7 @@ if (NOT LLDB_DISABLE_PYTHON)
>  add_custom_target( finish_swig ALL
>  COMMAND ${PYTHON_EXECUTABLE}
> ${CMAKE_CURRENT_SOURCE_DIR}/scripts/finishSwigWrapperClasses.py
> "--srcRoot=${LLDB_SOURCE_DIR}"
> "--targetDir=${CMAKE_CURRENT_BINARY_DIR}/scripts"
> "--cfgBldDir=${CMAKE_CURRENT_BINARY_DIR}/scripts"
> "--prefix=${CMAKE_BINARY_DIR}"
> "--cmakeBuildConfiguration=${CMAKE_CFG_INTDIR}" -m
>  DEPENDS
> ${CMAKE_CURRENT_SOURCE_DIR}/scripts/finishSwigWrapperClasses.py
> +DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/lldb.py
>  COMMENT "Python script sym-linking LLDB Python API")
>  # We depend on liblldb being built before we can do this step.
>  add_dependencies(finish_swig liblldb ll

[Lldb-commits] [lldb] r253493 - Reapply r253423 and r253424 (which cleanup the data formatters iteration model, as well as the type X list commands), along with a change by Zachary Turner to bypass a

[Enrico Granata via lldb-commits]

Author: enrico
Date: Wed Nov 18 13:42:44 2015
New Revision: 253493

URL: http://llvm.org/viewvc/llvm-project?rev=253493&view=rev
Log:
Reapply r253423 and r253424 (which cleanup the data formatters iteration model, 
as well as the type X list commands), along with a change by Zachary Turner to 
bypass a MSVC bug with SFINAE


Modified:
lldb/trunk/include/lldb/DataFormatters/DataVisualization.h
lldb/trunk/include/lldb/DataFormatters/FormatManager.h
lldb/trunk/include/lldb/DataFormatters/FormattersContainer.h
lldb/trunk/include/lldb/DataFormatters/TypeCategory.h
lldb/trunk/include/lldb/DataFormatters/TypeCategoryMap.h
lldb/trunk/include/lldb/DataFormatters/TypeFormat.h
lldb/trunk/include/lldb/DataFormatters/TypeSummary.h
lldb/trunk/include/lldb/DataFormatters/TypeSynthetic.h
lldb/trunk/include/lldb/DataFormatters/TypeValidator.h
lldb/trunk/source/API/SBTypeCategory.cpp
lldb/trunk/source/Commands/CommandObjectType.cpp
lldb/trunk/source/DataFormatters/DataVisualization.cpp
lldb/trunk/source/DataFormatters/FormatManager.cpp
lldb/trunk/source/DataFormatters/TypeCategoryMap.cpp

Modified: lldb/trunk/include/lldb/DataFormatters/DataVisualization.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/DataFormatters/DataVisualization.h?rev=253493&r1=253492&r2=253493&view=diff
==
--- lldb/trunk/include/lldb/DataFormatters/DataVisualization.h (original)
+++ lldb/trunk/include/lldb/DataFormatters/DataVisualization.h Wed Nov 18 
13:42:44 2015
@@ -101,7 +101,7 @@ public:
 Clear ();
 
 static void
-LoopThrough (TypeSummaryImpl::SummaryCallback callback, void* 
callback_baton);
+ForEach (std::function callback);
 
 static uint32_t
 GetCount ();
@@ -158,9 +158,6 @@ public:
 DisableStar ();
 
 static void
-LoopThrough (FormatManager::CategoryCallback callback, void* 
callback_baton);
-
-static void
 ForEach (TypeCategoryMap::ForEachCallback callback);
 
 static uint32_t

Modified: lldb/trunk/include/lldb/DataFormatters/FormatManager.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/DataFormatters/FormatManager.h?rev=253493&r1=253492&r2=253493&view=diff
==
--- lldb/trunk/include/lldb/DataFormatters/FormatManager.h (original)
+++ lldb/trunk/include/lldb/DataFormatters/FormatManager.h Wed Nov 18 13:42:44 
2015
@@ -43,8 +43,6 @@ class FormatManager : public IFormatChan
 public:
 typedef std::map 
LanguageCategories;
 
-typedef TypeCategoryMap::CallbackType CategoryCallback;
-
 FormatManager();
 
 ~FormatManager() override = default;
@@ -140,9 +138,6 @@ public:
 }
 
 void
-LoopThroughCategories (CategoryCallback callback, void* param);
-
-void
 ForEachCategory (TypeCategoryMap::ForEachCallback callback);
 
 lldb::TypeCategoryImplSP

Modified: lldb/trunk/include/lldb/DataFormatters/FormattersContainer.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/DataFormatters/FormattersContainer.h?rev=253493&r1=253492&r2=253493&view=diff
==
--- lldb/trunk/include/lldb/DataFormatters/FormattersContainer.h (original)
+++ lldb/trunk/include/lldb/DataFormatters/FormattersContainer.h Wed Nov 18 
13:42:44 2015
@@ -80,8 +80,6 @@ public:
 typedef typename ValueType::SharedPointer ValueSP;
 typedef std::map MapType;
 typedef typename MapType::iterator MapIterator;
-typedef std::function CallbackType;
-
 typedef std::function ForEachCallback;
 
 FormatMap(IFormatChangeListener* lst) :
@@ -141,22 +139,6 @@ public:
 }
 
 void
-LoopThrough (CallbackType callback, void* param)
-{
-if (callback)
-{
-Mutex::Locker locker(m_map_mutex);
-MapIterator pos, end = m_map.end();
-for (pos = m_map.begin(); pos != end; pos++)
-{
-KeyType type = pos->first;
-if (!callback(param, type, pos->second))
-break;
-}
-}
-}
-
-void
 ForEach (ForEachCallback callback)
 {
 if (callback)
@@ -242,7 +224,6 @@ public:
 typedef typename MapType::iterator MapIterator;
 typedef typename MapType::key_type MapKeyType;
 typedef typename MapType::mapped_type MapValueType;
-typedef typename BackEndType::CallbackType CallbackType;
 typedef typename BackEndType::ForEachCallback ForEachCallback;
 typedef typename std::shared_ptr > 
SharedPointer;
 
@@ -316,12 +297,6 @@ public:
 }
 
 void
-LoopThrough (CallbackType callback, void* param)
-{
-m_format_map.LoopThrough(callback,param);
-}
-
-void

Re: [Lldb-commits] [lldb-dev] [lldb] r253317 - Add Pythonic language binding wrapper generation script.

[Zachary Turner via lldb-commits]

On Wed, Nov 18, 2015 at 11:15 AM Todd Fiala  wrote:

>
> My intent here is to only provide the --allow-static-binding option on
> cmake if it is explicitly turned on.  And it will be off by default.
>
I know, but I don't really like adding options that nobody is going to use,
because it makes maintaining the build files more difficult, and when
people ask questions on the list about how to use various options, chances
are nobody is going to know because there's nobody maintaining that
codepath.  So I lean on the side of not even having the option.  There's
already a bunch of paths in the CMake build that don't even work because
they're not maintained and nobody uses them.  I'd actually like to go
through and remove that complexity from the CMake build at some point.


>
>
> Tell me more about the service idea.  How would you envision it working?
>
Well, pretty much like I described earlier.  I write a python script,
called swig-bot.py.  You run it like this (I've fabricated an example of
what the output of the tool might look like):

~/lldb$ scripts/swig-bot.py --lang Python --outdir scripts/Python/bindings
scripts/lldb.swig
swig-bot packaging up input files
scripts/lldb.swig
scripts/SBAddress.i
scripts/SBAttachInfo.i
scripts/SBBlock.i
scripts/SBBreakpoint.i
scripts/SBBreakpointLocation.i
scripts/SBBroadcaster.i
scripts/SBCommandInterpreter.i
scripts/SBCommandReturnObject.i
scripts/SBCommunication.i
scripts/SBCompileUnit.i
scripts/SBData.i
scripts/SBDebugger.i
...
transmitting input files...
awaiting response...
Generation
Output: scripts/Python/bindings/LLDBWrapPython.cpp
Output: scripts/Python/bindings/lldb.py

Now you add the 2 output files to your CL, diff them to verify sanity, and
submit.
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [lldb] r253478 - Switched cmake build from using buildSwigWrapperClases.py to the cleaned up version.

[Zachary Turner via lldb-commits]

Yea, VS 2015 only.

On Wed, Nov 18, 2015 at 11:42 AM Todd Fiala  wrote:

> And that works with VS 2015, and VS 2015 only, right?
>
> On Wed, Nov 18, 2015 at 11:41 AM, Todd Fiala  wrote:
>
>> That's great, Zachary!
>>
>> Cool.  Makes it easier to make sure I'm not breaking stuff.
>>
>> On Wed, Nov 18, 2015 at 11:07 AM, Zachary Turner 
>> wrote:
>>
>>> yea.  Pass -DPYTHON_HOME=C:\Python35 to CMake and you're good to go.
>>>
>>> I've still got about 20-30 tests failing and/or timing out, but I'm
>>> getting close.
>>>
>>>
>>> On Wed, Nov 18, 2015 at 10:58 AM Todd Fiala 
>>> wrote:
>>>
 Ah okay.

 Hey is the "use the python 3.5 from python.org" path on Windows
 (including tests) try-able at this time?

 -Todd

 On Wed, Nov 18, 2015 at 10:37 AM, Zachary Turner 
 wrote:

> Yea, this is the right one.  Thanks!  I haven't tested this yet, but I
> will later.  (Our buildbot currently builds with LLDB_DISABLE_PYTHON=1, so
> if there is a problem with this, the Windows buildbot wouldn't pick it up,
> although the others probably would)
>
> On Wed, Nov 18, 2015 at 10:14 AM Todd Fiala 
> wrote:
>
>> If I have that right, we're fine.  The prepare_bindings.py still
>> calls modify-python-lldb.py.
>>
>> scripts/prepare_bindings.py is meant to be the same as
>> createSwigBindings.py, and scripts/python/prepare_binding_Python.py is
>> meant to be the same as buildSwigPython.py.
>>
>> Once I make sure that I haven't broken anything for anybody with it,
>> I'll get rid of the other scripts.
>>
>> On Wed, Nov 18, 2015 at 10:09 AM, Todd Fiala 
>> wrote:
>>
>>> You're talking about this change, right?  (I'm looking at it now...)
>>>
>>> commit cc353bbc992ab324aef395c54a2a46fcaaa3855b
>>> Author: Zachary Turner 
>>> Date:   Mon Nov 16 22:40:20 2015 +
>>>
>>> Insert the SWIG version into LLDB's __init__.py
>>>
>>> The goal here is to allow us to add skip / xfail decorators
>>> based on SWIG version.
>>>
>>> git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@253262
>>> 91177308-0d34-0410-b5e6-96231b3b80d8
>>>
>>>
>>> On Wed, Nov 18, 2015 at 10:07 AM, Todd Fiala 
>>> wrote:
>>>
 Double checking now, if it happens in that lldb-modify script,
 we're covered.  Otherwise I need to adjust...  (the bulk of the rewrite
 happened on Friday/Sunday).

 On Wed, Nov 18, 2015 at 9:47 AM, Zachary Turner >>> > wrote:

> Just to be sure, did you catch the change I made to the old
> scripts in the past few days to embed the swig version in the 
> generated
> lldb.py?  Maybe you did, I just want to make sure that change is in 
> your
> new version.
>
> On Wed, Nov 18, 2015 at 9:38 AM Todd Fiala via lldb-commits <
> lldb-commits@lists.llvm.org> wrote:
>
>> Author: tfiala
>> Date: Wed Nov 18 11:36:15 2015
>> New Revision: 253478
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=253478&view=rev
>> Log:
>> Switched cmake build from using buildSwigWrapperClases.py to the
>> cleaned up version.
>>
>> This change does not introduce static bindings.  It is simply
>> using
>> the pylinted cleaned up code in prepare_bindings.py.
>>
>> If this breaks anyting, I'll revert immediately and figure out
>> what
>> needs to be addressed.  I'm looking to wrap up
>> the cleanup aspect of the code change (pylinted, removal of code
>> that
>> implements existing python stdlib code, fixes for Xcode adoption,
>> etc.).
>>
>> Modified:
>> lldb/trunk/CMakeLists.txt
>> lldb/trunk/scripts/CMakeLists.txt
>>
>> Modified: lldb/trunk/CMakeLists.txt
>> URL:
>> http://llvm.org/viewvc/llvm-project/lldb/trunk/CMakeLists.txt?rev=253478&r1=253477&r2=253478&view=diff
>>
>> ==
>> --- lldb/trunk/CMakeLists.txt (original)
>> +++ lldb/trunk/CMakeLists.txt Wed Nov 18 11:36:15 2015
>> @@ -33,6 +33,7 @@ if (NOT LLDB_DISABLE_PYTHON)
>>  add_custom_target( finish_swig ALL
>>  COMMAND ${PYTHON_EXECUTABLE}
>> ${CMAKE_CURRENT_SOURCE_DIR}/scripts/finishSwigWrapperClasses.py
>> "--srcRoot=${LLDB_SOURCE_DIR}"
>> "--targetDir=${CMAKE_CURRENT_BINARY_DIR}/scripts"
>> "--cfgBldDir=${CMAKE_CURRENT_BINARY_DIR}/scripts"
>> "--prefix=${CMAKE_BINARY_DIR}"
>> "--cmakeBuildConfiguration=${CMAKE_CFG_INTDIR}" -m
>>  DEPENDS
>> ${CMAKE_CURRENT_SOURCE_DIR}/scripts/finishSwigWrapperClasses.py
>> +DEPENDS ${CMAKE_CUR

[Lldb-commits] [PATCH] D14783: Remove superseded buildSwigWrapperClasses.py and buildSwigPython.py classes

[Todd Fiala via lldb-commits]

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

These classes have been cleaned up in scripts/prepare_bindings.py and 
scripts/Python/prepare_binding_Python.py.

Both Xcode and cmake builds have been converted over.

Waiting to make sure this works for Windows, which has a few places where it 
does something different than the POSIX bits.

http://reviews.llvm.org/D14783

Files:
  scripts/Python/buildSwigPython.py
  scripts/buildSwigWrapperClasses.py

Index: scripts/buildSwigWrapperClasses.py
===
--- scripts/buildSwigWrapperClasses.py
+++ /dev/null
@@ -1,451 +0,0 @@
-""" SWIG creates Python C++ Script Bridge wrapper code Windows/LINUX/OSX platform
-
---
-File:   buildSwigWrapperClasses.py
-
-Overview:   Python script(s) to build the SWIG Python C++ Script
-Bridge wrapper code on the Windows/LINUX/OSX platform.
-The Python scripts are equivalent to the shell script (.sh)
-files.
-For each scripting language lib lldb supports, we need to
-create the appropriate Script Bridge wrapper classes for
-that language so that users can call Script Bridge
-functions from within the script interpreter.
-We use SWIG to help create the appropriate wrapper
-classes/functions for the scripting language.  In some
-cases the file generated by SWIG may need some tweaking
-before it is completely ready to use.
-
-Gotchas:For Windows OS it is assumed the SWIG executable can be
-found in the %PATH% environmental variable.
-
-Copyright:  None.
---
-
-"""
-
-# Python modules:
-import sys  # Provide argument parsing
-import os   # Provide directory and file handling
-
-# Third party modules:
-
-# In-house modules:
-import utilsArgsParse   # Parse and validate this script's input arguments
-import utilsOsType  # Determine the OS type this script is running on
-import utilsDebug   # Debug Python scripts
-
-# Instantiations:
-gbDbgVerbose = False   # True = Turn on script function tracing, False = off.
-gbDbgFlag = False  # Global debug mode flag, set by input parameter
-# --dbgFlag. True = operate in debug mode.
-gbMakeFileFlag = False # True = yes called from makefile system, False = not.
-gbSwigGenDepFileFlag = False   # True = SWIG generate a dependency file.
-
-# User facing text:
-strMsgErrorNoMain = "Program called by another Python script not allowed"
-strExitMsgSuccess = "Program successful"
-strExitMsgError = "Program error: "
-strParameter = "Parameter: "
-strMsgErrorOsTypeUnknown = "Unable to determine OS type"
-strSwigFileFound = "Found the \'lldb.swig\' file\n"
-strSwigFileFoundNotFound = "Unable to locate the file \'%s\'"
-strSwigExeFileNotFound = "Unable to locate the SWIG executable file \'swig\'"
-strSwigScriptDirNotFound = "Unable to locate the SWIG script directory \'/script\'"
-strSwigScriptNotFound = "Unable to locate the SWIG script file \'%s\' in \'%s\'. Is it a script directory?"
-strSwigScriptLangFound = "Found \'%s\' build script."
-strSwigScriptLangsFound = "Found the following script languages:"
-strSwigExecuteMsg = "Executing \'%s\' build script..."
-strSwigExecuteError = "Executing \'%s\' build script failed: "
-strHelpInfo = "\
-Python script(s) to build the SWIG Python C++ Script \n\
-Bridge wrapper code on various platforms.  The Python \n\
-scripts are equivalent to the shell script (.sh) files \n\
-run on others platforms.\n\
-Args:   -h  (optional) Print help information on this program.\n\
--d  (optional) Determines whether or not this script\n\
-outputs additional information when running.\n\
--m  (optional) Specify called from Makefile system.\n\
--M  (optional) Specify want SWIG to generate a dependency \n\
-file.\n\
---srcRoot=  The root of the lldb source tree.\n\
---targetDir=Where the lldb framework/shared library gets put.\n\
---cfgBldDir=(optional) Where the build-swig-Python-LLDB.py program \n\
-will put the lldb.py file it generated from running\n\
-SWIG.\n\
---prefix=   (optional) Is the root directory used to determine where\n\
-third-party modules for scripting languages should\n\
-be installed. Where non-Darwin systems want to put\n\
-the .py and .so files so that Python can find them\n\
-automatically. Python install directory.\n\
---argsFile= The args are read from a file instead of the\n\
-command line

Re: [Lldb-commits] [lldb] r253478 - Switched cmake build from using buildSwigWrapperClases.py to the cleaned up version.

[Zachary Turner via lldb-commits]

By the way, it would be great if we could kill this modify-lldb-python.py.
It seems like a total hackjob, and there's nothing it does that can't be
done better by wrapping the lldb module instead of modifying it.

For example, it goes through and injects a bunch of methods to classes in
the lldb module.  But if, instead of renaming lldb.py to __init__.py, we
renamed it to lldb_internal.py, and then we can actually check in an
__init__.py that does this:

from lldb_internal import *

# Loop over each class in lldb_internal, injecting methods
# and modifying the types / classes as necessary

Then this would be much better, as it eliminates a post processing step and
allows easier maintenance of this code.

On Wed, Nov 18, 2015 at 10:37 AM Zachary Turner  wrote:

> Yea, this is the right one.  Thanks!  I haven't tested this yet, but I
> will later.  (Our buildbot currently builds with LLDB_DISABLE_PYTHON=1, so
> if there is a problem with this, the Windows buildbot wouldn't pick it up,
> although the others probably would)
>
> On Wed, Nov 18, 2015 at 10:14 AM Todd Fiala  wrote:
>
>> If I have that right, we're fine.  The prepare_bindings.py still calls
>> modify-python-lldb.py.
>>
>> scripts/prepare_bindings.py is meant to be the same as
>> createSwigBindings.py, and scripts/python/prepare_binding_Python.py is
>> meant to be the same as buildSwigPython.py.
>>
>> Once I make sure that I haven't broken anything for anybody with it, I'll
>> get rid of the other scripts.
>>
>> On Wed, Nov 18, 2015 at 10:09 AM, Todd Fiala 
>> wrote:
>>
>>> You're talking about this change, right?  (I'm looking at it now...)
>>>
>>> commit cc353bbc992ab324aef395c54a2a46fcaaa3855b
>>> Author: Zachary Turner 
>>> Date:   Mon Nov 16 22:40:20 2015 +
>>>
>>> Insert the SWIG version into LLDB's __init__.py
>>>
>>> The goal here is to allow us to add skip / xfail decorators
>>> based on SWIG version.
>>>
>>> git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@253262
>>> 91177308-0d34-0410-b5e6-96231b3b80d8
>>>
>>>
>>> On Wed, Nov 18, 2015 at 10:07 AM, Todd Fiala 
>>> wrote:
>>>
 Double checking now, if it happens in that lldb-modify script, we're
 covered.  Otherwise I need to adjust...  (the bulk of the rewrite happened
 on Friday/Sunday).

 On Wed, Nov 18, 2015 at 9:47 AM, Zachary Turner 
 wrote:

> Just to be sure, did you catch the change I made to the old scripts in
> the past few days to embed the swig version in the generated lldb.py?
> Maybe you did, I just want to make sure that change is in your new 
> version.
>
> On Wed, Nov 18, 2015 at 9:38 AM Todd Fiala via lldb-commits <
> lldb-commits@lists.llvm.org> wrote:
>
>> Author: tfiala
>> Date: Wed Nov 18 11:36:15 2015
>> New Revision: 253478
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=253478&view=rev
>> Log:
>> Switched cmake build from using buildSwigWrapperClases.py to the
>> cleaned up version.
>>
>> This change does not introduce static bindings.  It is simply using
>> the pylinted cleaned up code in prepare_bindings.py.
>>
>> If this breaks anyting, I'll revert immediately and figure out what
>> needs to be addressed.  I'm looking to wrap up
>> the cleanup aspect of the code change (pylinted, removal of code that
>> implements existing python stdlib code, fixes for Xcode adoption,
>> etc.).
>>
>> Modified:
>> lldb/trunk/CMakeLists.txt
>> lldb/trunk/scripts/CMakeLists.txt
>>
>> Modified: lldb/trunk/CMakeLists.txt
>> URL:
>> http://llvm.org/viewvc/llvm-project/lldb/trunk/CMakeLists.txt?rev=253478&r1=253477&r2=253478&view=diff
>>
>> ==
>> --- lldb/trunk/CMakeLists.txt (original)
>> +++ lldb/trunk/CMakeLists.txt Wed Nov 18 11:36:15 2015
>> @@ -33,6 +33,7 @@ if (NOT LLDB_DISABLE_PYTHON)
>>  add_custom_target( finish_swig ALL
>>  COMMAND ${PYTHON_EXECUTABLE}
>> ${CMAKE_CURRENT_SOURCE_DIR}/scripts/finishSwigWrapperClasses.py
>> "--srcRoot=${LLDB_SOURCE_DIR}"
>> "--targetDir=${CMAKE_CURRENT_BINARY_DIR}/scripts"
>> "--cfgBldDir=${CMAKE_CURRENT_BINARY_DIR}/scripts"
>> "--prefix=${CMAKE_BINARY_DIR}"
>> "--cmakeBuildConfiguration=${CMAKE_CFG_INTDIR}" -m
>>  DEPENDS
>> ${CMAKE_CURRENT_SOURCE_DIR}/scripts/finishSwigWrapperClasses.py
>> +DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/lldb.py
>>  COMMENT "Python script sym-linking LLDB Python API")
>>  # We depend on liblldb being built before we can do this step.
>>  add_dependencies(finish_swig liblldb lldb-argdumper)
>>
>> Modified: lldb/trunk/scripts/CMakeLists.txt
>> URL:
>> http://llvm.org/viewvc/llvm-project/lldb/trunk/scripts/CMakeLists.txt?rev=253478&r1=253477&r2=253478&view=diff
>>
>> ==

[Lldb-commits] [PATCH] D14784: [TestExitDuringStep] Adjust after a recent type map change.

[Siva Chandra via lldb-commits]

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

http://reviews.llvm.org/D14784

Files:
  
packages/Python/lldbsuite/test/functionalities/thread/exit_during_step/TestExitDuringStep.py

Index: 
packages/Python/lldbsuite/test/functionalities/thread/exit_during_step/TestExitDuringStep.py
===
--- 
packages/Python/lldbsuite/test/functionalities/thread/exit_during_step/TestExitDuringStep.py
+++ 
packages/Python/lldbsuite/test/functionalities/thread/exit_during_step/TestExitDuringStep.py
@@ -98,7 +98,8 @@
 stepping_thread = None
 for thread in process:
 expected_bp_desc = "breakpoint %s." % self.bp_num
-if expected_bp_desc in thread.GetStopDescription(100):
+stop_desc = thread.GetStopDescription(100)
+if stop_desc and (expected_bp_desc in stop_desc):
 stepping_thread = thread
 break
 self.assertTrue(stepping_thread != None, "unable to find thread 
stopped at %s" % expected_bp_desc)


Index: packages/Python/lldbsuite/test/functionalities/thread/exit_during_step/TestExitDuringStep.py
===
--- packages/Python/lldbsuite/test/functionalities/thread/exit_during_step/TestExitDuringStep.py
+++ packages/Python/lldbsuite/test/functionalities/thread/exit_during_step/TestExitDuringStep.py
@@ -98,7 +98,8 @@
 stepping_thread = None
 for thread in process:
 expected_bp_desc = "breakpoint %s." % self.bp_num
-if expected_bp_desc in thread.GetStopDescription(100):
+stop_desc = thread.GetStopDescription(100)
+if stop_desc and (expected_bp_desc in stop_desc):
 stepping_thread = thread
 break
 self.assertTrue(stepping_thread != None, "unable to find thread stopped at %s" % expected_bp_desc)
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [lldb-dev] [lldb] r253317 - Add Pythonic language binding wrapper generation script.

[Zachary Turner via lldb-commits]

On Wed, Nov 18, 2015 at 11:15 AM Todd Fiala  wrote:

> On Wed, Nov 18, 2015 at 10:34 AM, Zachary Turner 
> wrote:
>
>>   Because even if it isn't perfect for everyone, it works for everyone.
>>
>
> Unless you can't get swig on your system in a way that doesn't break other
> items.  And then it doesn't work (as things stand now).
>
Is that a real issue that people on OSX are facing now?  Because I thought
having SWIG installed on your system has been a requirement for the past N
years.  Did something change  recently that now makes it impossible to
install swig in a way that doesn't break something?


>
>
>> And there is inherent simplicity in having fewer ways to do things, as
>> well as reducing maintenance cost.
>>
>>
>>>
>>> So for the more common, casual lldb build environment where the
>>> developer is not touching SB API, help me understand how reducing the need
>>> for swig (without introducing the need for hitting another server) is
>>> increasing the requirement load?  (Especially if we --- our local dev group
>>> sitting by me --- maintains those static bindings)?
>>>
>>
>> Well, we would need to disable static bindings on the OSX buildbots for
>> starters, otherwise when someone not using static bindings makes a change,
>> the buildbots break, and we cannot leave buildbots in a broken state.  So I
>> assume that will still be possible.  So now you don't have a buildbot
>> testing the static binding configuration.
>>
>
> I was actually going to add a verifier stage to the public OS X buildbot.
>
I'm not sure I follow this point.  What would your verifier stage do?  I'm
imagining the following scenario:

I check in some changes to SWIG interface files at like 10PM.  Ignoring the
fact that you and Jason are usually up firing commits away until the wee
hours of the morning, let's pretend nobody sees this until the morning.  So
the build bot has been broken all night.  Is this something that is going
to happen under this scenario?

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

Re: [Lldb-commits] [lldb] r253478 - Switched cmake build from using buildSwigWrapperClases.py to the cleaned up version.

[Todd Fiala via lldb-commits]

On Wed, Nov 18, 2015 at 11:55 AM, Zachary Turner  wrote:

> By the way, it would be great if we could kill this modify-lldb-python.py.
>

I'm totally up for that.


>   It seems like a total hackjob, and there's nothing it does that can't be
> done better by wrapping the lldb module instead of modifying it.
>
> For example, it goes through and injects a bunch of methods to classes in
> the lldb module.  But if, instead of renaming lldb.py to __init__.py, we
> renamed it to lldb_internal.py, and then we can actually check in an
> __init__.py that does this:
>
> from lldb_internal import *
>
> # Loop over each class in lldb_internal, injecting methods
> # and modifying the types / classes as necessary
>
> Then this would be much better, as it eliminates a post processing step
> and allows easier maintenance of this code.
>
>
Sounds like a great idea.  I'd love to get rid of some post-processing
steps.


>
> On Wed, Nov 18, 2015 at 10:37 AM Zachary Turner 
> wrote:
>
>> Yea, this is the right one.  Thanks!  I haven't tested this yet, but I
>> will later.  (Our buildbot currently builds with LLDB_DISABLE_PYTHON=1, so
>> if there is a problem with this, the Windows buildbot wouldn't pick it up,
>> although the others probably would)
>>
>> On Wed, Nov 18, 2015 at 10:14 AM Todd Fiala  wrote:
>>
>>> If I have that right, we're fine.  The prepare_bindings.py still calls
>>> modify-python-lldb.py.
>>>
>>> scripts/prepare_bindings.py is meant to be the same as
>>> createSwigBindings.py, and scripts/python/prepare_binding_Python.py is
>>> meant to be the same as buildSwigPython.py.
>>>
>>> Once I make sure that I haven't broken anything for anybody with it,
>>> I'll get rid of the other scripts.
>>>
>>> On Wed, Nov 18, 2015 at 10:09 AM, Todd Fiala 
>>> wrote:
>>>
 You're talking about this change, right?  (I'm looking at it now...)

 commit cc353bbc992ab324aef395c54a2a46fcaaa3855b
 Author: Zachary Turner 
 Date:   Mon Nov 16 22:40:20 2015 +

 Insert the SWIG version into LLDB's __init__.py

 The goal here is to allow us to add skip / xfail decorators
 based on SWIG version.

 git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@253262
 91177308-0d34-0410-b5e6-96231b3b80d8


 On Wed, Nov 18, 2015 at 10:07 AM, Todd Fiala 
 wrote:

> Double checking now, if it happens in that lldb-modify script, we're
> covered.  Otherwise I need to adjust...  (the bulk of the rewrite happened
> on Friday/Sunday).
>
> On Wed, Nov 18, 2015 at 9:47 AM, Zachary Turner 
> wrote:
>
>> Just to be sure, did you catch the change I made to the old scripts
>> in the past few days to embed the swig version in the generated lldb.py?
>> Maybe you did, I just want to make sure that change is in your new 
>> version.
>>
>> On Wed, Nov 18, 2015 at 9:38 AM Todd Fiala via lldb-commits <
>> lldb-commits@lists.llvm.org> wrote:
>>
>>> Author: tfiala
>>> Date: Wed Nov 18 11:36:15 2015
>>> New Revision: 253478
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=253478&view=rev
>>> Log:
>>> Switched cmake build from using buildSwigWrapperClases.py to the
>>> cleaned up version.
>>>
>>> This change does not introduce static bindings.  It is simply using
>>> the pylinted cleaned up code in prepare_bindings.py.
>>>
>>> If this breaks anyting, I'll revert immediately and figure out what
>>> needs to be addressed.  I'm looking to wrap up
>>> the cleanup aspect of the code change (pylinted, removal of code that
>>> implements existing python stdlib code, fixes for Xcode adoption,
>>> etc.).
>>>
>>> Modified:
>>> lldb/trunk/CMakeLists.txt
>>> lldb/trunk/scripts/CMakeLists.txt
>>>
>>> Modified: lldb/trunk/CMakeLists.txt
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/lldb/trunk/CMakeLists.txt?rev=253478&r1=253477&r2=253478&view=diff
>>>
>>> ==
>>> --- lldb/trunk/CMakeLists.txt (original)
>>> +++ lldb/trunk/CMakeLists.txt Wed Nov 18 11:36:15 2015
>>> @@ -33,6 +33,7 @@ if (NOT LLDB_DISABLE_PYTHON)
>>>  add_custom_target( finish_swig ALL
>>>  COMMAND ${PYTHON_EXECUTABLE}
>>> ${CMAKE_CURRENT_SOURCE_DIR}/scripts/finishSwigWrapperClasses.py
>>> "--srcRoot=${LLDB_SOURCE_DIR}"
>>> "--targetDir=${CMAKE_CURRENT_BINARY_DIR}/scripts"
>>> "--cfgBldDir=${CMAKE_CURRENT_BINARY_DIR}/scripts"
>>> "--prefix=${CMAKE_BINARY_DIR}"
>>> "--cmakeBuildConfiguration=${CMAKE_CFG_INTDIR}" -m
>>>  DEPENDS
>>> ${CMAKE_CURRENT_SOURCE_DIR}/scripts/finishSwigWrapperClasses.py
>>> +DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/lldb.py
>>>  COMMENT "Python script sym-linking LLDB Python API")
>>>  # We depend on liblldb being built before we can do this step.
>>>  

Re: [Lldb-commits] [lldb] r253478 - Switched cmake build from using buildSwigWrapperClases.py to the cleaned up version.

[Todd Fiala via lldb-commits]

BTW if you cook up something on the swig-as-a-service end that ends up
working to eliminate the need for swig, I'll be happy to remove the static
binding support at that point.

-Todd

On Wed, Nov 18, 2015 at 12:45 PM, Todd Fiala  wrote:

>
> On Wed, Nov 18, 2015 at 11:55 AM, Zachary Turner 
> wrote:
>
>> By the way, it would be great if we could kill this modify-lldb-python.py.
>>
>
> I'm totally up for that.
>
>
>>   It seems like a total hackjob, and there's nothing it does that can't
>> be done better by wrapping the lldb module instead of modifying it.
>>
>> For example, it goes through and injects a bunch of methods to classes in
>> the lldb module.  But if, instead of renaming lldb.py to __init__.py, we
>> renamed it to lldb_internal.py, and then we can actually check in an
>> __init__.py that does this:
>>
>> from lldb_internal import *
>>
>> # Loop over each class in lldb_internal, injecting methods
>> # and modifying the types / classes as necessary
>>
>> Then this would be much better, as it eliminates a post processing step
>> and allows easier maintenance of this code.
>>
>>
> Sounds like a great idea.  I'd love to get rid of some post-processing
> steps.
>
>
>>
>> On Wed, Nov 18, 2015 at 10:37 AM Zachary Turner 
>> wrote:
>>
>>> Yea, this is the right one.  Thanks!  I haven't tested this yet, but I
>>> will later.  (Our buildbot currently builds with LLDB_DISABLE_PYTHON=1, so
>>> if there is a problem with this, the Windows buildbot wouldn't pick it up,
>>> although the others probably would)
>>>
>>> On Wed, Nov 18, 2015 at 10:14 AM Todd Fiala 
>>> wrote:
>>>
 If I have that right, we're fine.  The prepare_bindings.py still calls
 modify-python-lldb.py.

 scripts/prepare_bindings.py is meant to be the same as
 createSwigBindings.py, and scripts/python/prepare_binding_Python.py is
 meant to be the same as buildSwigPython.py.

 Once I make sure that I haven't broken anything for anybody with it,
 I'll get rid of the other scripts.

 On Wed, Nov 18, 2015 at 10:09 AM, Todd Fiala 
 wrote:

> You're talking about this change, right?  (I'm looking at it now...)
>
> commit cc353bbc992ab324aef395c54a2a46fcaaa3855b
> Author: Zachary Turner 
> Date:   Mon Nov 16 22:40:20 2015 +
>
> Insert the SWIG version into LLDB's __init__.py
>
> The goal here is to allow us to add skip / xfail decorators
> based on SWIG version.
>
> git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@253262
> 91177308-0d34-0410-b5e6-96231b3b80d8
>
>
> On Wed, Nov 18, 2015 at 10:07 AM, Todd Fiala 
> wrote:
>
>> Double checking now, if it happens in that lldb-modify script, we're
>> covered.  Otherwise I need to adjust...  (the bulk of the rewrite 
>> happened
>> on Friday/Sunday).
>>
>> On Wed, Nov 18, 2015 at 9:47 AM, Zachary Turner 
>> wrote:
>>
>>> Just to be sure, did you catch the change I made to the old scripts
>>> in the past few days to embed the swig version in the generated lldb.py?
>>> Maybe you did, I just want to make sure that change is in your new 
>>> version.
>>>
>>> On Wed, Nov 18, 2015 at 9:38 AM Todd Fiala via lldb-commits <
>>> lldb-commits@lists.llvm.org> wrote:
>>>
 Author: tfiala
 Date: Wed Nov 18 11:36:15 2015
 New Revision: 253478

 URL: http://llvm.org/viewvc/llvm-project?rev=253478&view=rev
 Log:
 Switched cmake build from using buildSwigWrapperClases.py to the
 cleaned up version.

 This change does not introduce static bindings.  It is simply using
 the pylinted cleaned up code in prepare_bindings.py.

 If this breaks anyting, I'll revert immediately and figure out what
 needs to be addressed.  I'm looking to wrap up
 the cleanup aspect of the code change (pylinted, removal of code
 that
 implements existing python stdlib code, fixes for Xcode adoption,
 etc.).

 Modified:
 lldb/trunk/CMakeLists.txt
 lldb/trunk/scripts/CMakeLists.txt

 Modified: lldb/trunk/CMakeLists.txt
 URL:
 http://llvm.org/viewvc/llvm-project/lldb/trunk/CMakeLists.txt?rev=253478&r1=253477&r2=253478&view=diff

 ==
 --- lldb/trunk/CMakeLists.txt (original)
 +++ lldb/trunk/CMakeLists.txt Wed Nov 18 11:36:15 2015
 @@ -33,6 +33,7 @@ if (NOT LLDB_DISABLE_PYTHON)
  add_custom_target( finish_swig ALL
  COMMAND ${PYTHON_EXECUTABLE}
 ${CMAKE_CURRENT_SOURCE_DIR}/scripts/finishSwigWrapperClasses.py
 "--srcRoot=${LLDB_SOURCE_DIR}"
 "--targetDir=${CMAKE_CURRENT_BINARY_DIR}/scripts"
 "--cfgBldDir=${CMAKE_CURRENT_BINARY_DIR}/scripts"
 "--prefix=${

Re: [Lldb-commits] [lldb-dev] [lldb] r253317 - Add Pythonic language binding wrapper generation script.

[Zachary Turner via lldb-commits]

(This is originally from a thread on lldb-commits, but it seems more
appropriate here, so I'm responding here.

On Wed, Nov 18, 2015 at 12:47 PM Todd Fiala  wrote:

> BTW if you cook up something on the swig-as-a-service end that ends up
> working to eliminate the need for swig, I'll be happy to remove the static
> binding support at that point.
>
> -Todd
>


Err, rewind.  If we have the swig as a service, then I think the static
binding does have value.  Because I don't want to hit the network every
single time I build, so it mostly solves the issue you mentioned about
network connectivity, because building LLDB doesn't require a network
connection unless you touch a swig interface file.

The thing I would like some guidance on from the Apple side is this: If I
make the swig service, can you (and will you) use code generated by swig
3.x?  If not, there's no value in the swig service.
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [lldb-dev] [lldb] r253317 - Add Pythonic language binding wrapper generation script.

[Todd Fiala via lldb-commits]

On Wed, Nov 18, 2015 at 12:45 PM, Zachary Turner  wrote:

>
>
> On Wed, Nov 18, 2015 at 11:15 AM Todd Fiala  wrote:
>
>> On Wed, Nov 18, 2015 at 10:34 AM, Zachary Turner 
>> wrote:
>>
>>>   Because even if it isn't perfect for everyone, it works for everyone.
>>>
>>
>> Unless you can't get swig on your system in a way that doesn't break
>> other items.  And then it doesn't work (as things stand now).
>>
> Is that a real issue that people on OSX are facing now?  Because I thought
> having SWIG installed on your system has been a requirement for the past N
> years.  Did something change  recently that now makes it impossible to
> install swig in a way that doesn't break something?
>
>

This is changing for a large class of people.


>
>>
>>> And there is inherent simplicity in having fewer ways to do things, as
>>> well as reducing maintenance cost.
>>>
>>>

 So for the more common, casual lldb build environment where the
 developer is not touching SB API, help me understand how reducing the need
 for swig (without introducing the need for hitting another server) is
 increasing the requirement load?  (Especially if we --- our local dev group
 sitting by me --- maintains those static bindings)?

>>>
>>> Well, we would need to disable static bindings on the OSX buildbots for
>>> starters, otherwise when someone not using static bindings makes a change,
>>> the buildbots break, and we cannot leave buildbots in a broken state.  So I
>>> assume that will still be possible.  So now you don't have a buildbot
>>> testing the static binding configuration.
>>>
>>
>> I was actually going to add a verifier stage to the public OS X buildbot.
>>
> I'm not sure I follow this point.  What would your verifier stage do?  I'm
> imagining the following scenario:
>
> I check in some changes to SWIG interface files at like 10PM.  Ignoring
> the fact that you and Jason are usually up firing commits away until the
> wee hours of the morning, let's pretend nobody sees this until the
> morning.  So the build bot has been broken all night.  Is this something
> that is going to happen under this scenario?
>
>>
You can more or less ignore that point.

The intent is to alert those who update the static bindings (i.e. Apple
LLDB team) that the bindings generated and post processed from swig are not
matching the static ones.  This would just get sent to an internal group
over here since I'm not hearing definite resistance to moving to a
static-by-default model.  (If we had gone static-by-default, and made it
clean and explicit when modifying the SB API surface area by requiring an
update-the-binding step, there would have been no way to test the bindings
without having done the "update the bindings" step.  Since we won't be
doing that, then I need some way to ensure I know bindings are stale).

That's really a detail you won't need to worry about, though, since you
will not be using static bindings ever, and won't have to address any time
they go stale.  The fact that it happens on a public builder is not very
interesting either.  I worded it in a way that made it sound like others
externally would see the staleness alert, but that's not what I meant.

(I may automate that later, but not until I make sure it works manually up
front).
-- 
-Todd
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [lldb-dev] [lldb] r253317 - Add Pythonic language binding wrapper generation script.

[Todd Fiala via lldb-commits]

On Wed, Nov 18, 2015 at 12:53 PM, Todd Fiala  wrote:

>
>
> On Wed, Nov 18, 2015 at 12:45 PM, Zachary Turner 
> wrote:
>
>>
>>
>> On Wed, Nov 18, 2015 at 11:15 AM Todd Fiala  wrote:
>>
>>> On Wed, Nov 18, 2015 at 10:34 AM, Zachary Turner 
>>> wrote:
>>>
   Because even if it isn't perfect for everyone, it works for everyone.

>>>
>>> Unless you can't get swig on your system in a way that doesn't break
>>> other items.  And then it doesn't work (as things stand now).
>>>
>> Is that a real issue that people on OSX are facing now?  Because I
>> thought having SWIG installed on your system has been a requirement for the
>> past N years.  Did something change  recently that now makes it impossible
>> to install swig in a way that doesn't break something?
>>
>>
>
> This is changing for a large class of people.
>

But more importantly, swig has never been easy to get on OS X except via
macports/fink.  Apple's internal toolchain has an ancient swig available
that we use, but we don't distribute that one.


>
>
>>
>>>
 And there is inherent simplicity in having fewer ways to do things, as
 well as reducing maintenance cost.


>
> So for the more common, casual lldb build environment where the
> developer is not touching SB API, help me understand how reducing the need
> for swig (without introducing the need for hitting another server) is
> increasing the requirement load?  (Especially if we --- our local dev 
> group
> sitting by me --- maintains those static bindings)?
>

 Well, we would need to disable static bindings on the OSX buildbots for
 starters, otherwise when someone not using static bindings makes a change,
 the buildbots break, and we cannot leave buildbots in a broken state.  So I
 assume that will still be possible.  So now you don't have a buildbot
 testing the static binding configuration.

>>>
>>> I was actually going to add a verifier stage to the public OS X buildbot.
>>>
>> I'm not sure I follow this point.  What would your verifier stage do?
>> I'm imagining the following scenario:
>>
>> I check in some changes to SWIG interface files at like 10PM.  Ignoring
>> the fact that you and Jason are usually up firing commits away until the
>> wee hours of the morning, let's pretend nobody sees this until the
>> morning.  So the build bot has been broken all night.  Is this something
>> that is going to happen under this scenario?
>>
>>>
> You can more or less ignore that point.
>
> The intent is to alert those who update the static bindings (i.e. Apple
> LLDB team) that the bindings generated and post processed from swig are not
> matching the static ones.  This would just get sent to an internal group
> over here since I'm not hearing definite resistance to moving to a
> static-by-default model.  (If we had gone static-by-default, and made it
> clean and explicit when modifying the SB API surface area by requiring an
> update-the-binding step, there would have been no way to test the bindings
> without having done the "update the bindings" step.  Since we won't be
> doing that, then I need some way to ensure I know bindings are stale).
>
> That's really a detail you won't need to worry about, though, since you
> will not be using static bindings ever, and won't have to address any time
> they go stale.  The fact that it happens on a public builder is not very
> interesting either.  I worded it in a way that made it sound like others
> externally would see the staleness alert, but that's not what I meant.
>
> (I may automate that later, but not until I make sure it works manually up
> front).
> --
> -Todd
>



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

Re: [Lldb-commits] [lldb-dev] [lldb] r253317 - Add Pythonic language binding wrapper generation script.

[Todd Fiala via lldb-commits]

On Wed, Nov 18, 2015 at 12:51 PM, Zachary Turner  wrote:

> (This is originally from a thread on lldb-commits, but it seems more
> appropriate here, so I'm responding here.
>
> On Wed, Nov 18, 2015 at 12:47 PM Todd Fiala  wrote:
>
>> BTW if you cook up something on the swig-as-a-service end that ends up
>> working to eliminate the need for swig, I'll be happy to remove the static
>> binding support at that point.
>>
>> -Todd
>>
>
>
> Err, rewind.  If we have the swig as a service, then I think the static
> binding does have value.
>

Yes, but in the context of what is useful for that workflow.  Not
necessarily the way I'm doing it.  (Or maybe so).


> Because I don't want to hit the network every single time I build, so it
> mostly solves the issue you mentioned about network connectivity, because
> building LLDB doesn't require a network connection unless you touch a swig
> interface file.
>
> The thing I would like some guidance on from the Apple side is this: If I
> make the swig service, can you (and will you) use code generated by swig
> 3.x?  If not, there's no value in the swig service.
>

We have no issue using code that has no additional licensing requirements
last time I verified.  And there are no additional licensing requirements
added by swig 3.x generation from what their website says (and my
non-official interpretation of it).  So I am pretty confident we can get
the answer here to be yes.



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

Re: [Lldb-commits] [PATCH] D14784: [TestExitDuringStep] Adjust after a recent type map change.

[Zachary Turner via lldb-commits]

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

lgtm, probably don't need to ask for review on this kind of patch :)


http://reviews.llvm.org/D14784



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

[Lldb-commits] [lldb] r253501 - Fix CMake dependency on lldb.py

[Zachary Turner via lldb-commits]

Author: zturner
Date: Wed Nov 18 15:09:55 2015
New Revision: 253501

URL: http://llvm.org/viewvc/llvm-project?rev=253501&view=rev
Log:
Fix CMake dependency on lldb.py

Modified:
lldb/trunk/CMakeLists.txt

Modified: lldb/trunk/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/CMakeLists.txt?rev=253501&r1=253500&r2=253501&view=diff
==
--- lldb/trunk/CMakeLists.txt (original)
+++ lldb/trunk/CMakeLists.txt Wed Nov 18 15:09:55 2015
@@ -33,7 +33,7 @@ if (NOT LLDB_DISABLE_PYTHON)
 add_custom_target( finish_swig ALL
 COMMAND ${PYTHON_EXECUTABLE} 
${CMAKE_CURRENT_SOURCE_DIR}/scripts/finishSwigWrapperClasses.py 
"--srcRoot=${LLDB_SOURCE_DIR}" 
"--targetDir=${CMAKE_CURRENT_BINARY_DIR}/scripts" 
"--cfgBldDir=${CMAKE_CURRENT_BINARY_DIR}/scripts" 
"--prefix=${CMAKE_BINARY_DIR}" "--cmakeBuildConfiguration=${CMAKE_CFG_INTDIR}" 
-m
 DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/scripts/finishSwigWrapperClasses.py
-DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/lldb.py
+DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/scripts/lldb.py
 COMMENT "Python script sym-linking LLDB Python API")
 # We depend on liblldb being built before we can do this step.
 add_dependencies(finish_swig liblldb lldb-argdumper)


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

Re: [Lldb-commits] [lldb] r253478 - Switched cmake build from using buildSwigWrapperClases.py to the cleaned up version.

[Zachary Turner via lldb-commits]

Tested this on Windows, seems to work fine.  r253501 has a minor fix that
was causing a CMake warning, but overall everything works great.  Happy to
see progress on this front.

On Wed, Nov 18, 2015 at 12:47 PM Todd Fiala  wrote:

> BTW if you cook up something on the swig-as-a-service end that ends up
> working to eliminate the need for swig, I'll be happy to remove the static
> binding support at that point.
>
> -Todd
>
> On Wed, Nov 18, 2015 at 12:45 PM, Todd Fiala  wrote:
>
>>
>> On Wed, Nov 18, 2015 at 11:55 AM, Zachary Turner 
>> wrote:
>>
>>> By the way, it would be great if we could kill this
>>> modify-lldb-python.py.
>>>
>>
>> I'm totally up for that.
>>
>>
>>>   It seems like a total hackjob, and there's nothing it does that can't
>>> be done better by wrapping the lldb module instead of modifying it.
>>>
>>> For example, it goes through and injects a bunch of methods to classes
>>> in the lldb module.  But if, instead of renaming lldb.py to __init__.py, we
>>> renamed it to lldb_internal.py, and then we can actually check in an
>>> __init__.py that does this:
>>>
>>> from lldb_internal import *
>>>
>>> # Loop over each class in lldb_internal, injecting methods
>>> # and modifying the types / classes as necessary
>>>
>>> Then this would be much better, as it eliminates a post processing step
>>> and allows easier maintenance of this code.
>>>
>>>
>> Sounds like a great idea.  I'd love to get rid of some post-processing
>> steps.
>>
>>
>>>
>>> On Wed, Nov 18, 2015 at 10:37 AM Zachary Turner 
>>> wrote:
>>>
 Yea, this is the right one.  Thanks!  I haven't tested this yet, but I
 will later.  (Our buildbot currently builds with LLDB_DISABLE_PYTHON=1, so
 if there is a problem with this, the Windows buildbot wouldn't pick it up,
 although the others probably would)

 On Wed, Nov 18, 2015 at 10:14 AM Todd Fiala 
 wrote:

> If I have that right, we're fine.  The prepare_bindings.py still calls
> modify-python-lldb.py.
>
> scripts/prepare_bindings.py is meant to be the same as
> createSwigBindings.py, and scripts/python/prepare_binding_Python.py is
> meant to be the same as buildSwigPython.py.
>
> Once I make sure that I haven't broken anything for anybody with it,
> I'll get rid of the other scripts.
>
> On Wed, Nov 18, 2015 at 10:09 AM, Todd Fiala 
> wrote:
>
>> You're talking about this change, right?  (I'm looking at it now...)
>>
>> commit cc353bbc992ab324aef395c54a2a46fcaaa3855b
>> Author: Zachary Turner 
>> Date:   Mon Nov 16 22:40:20 2015 +
>>
>> Insert the SWIG version into LLDB's __init__.py
>>
>> The goal here is to allow us to add skip / xfail decorators
>> based on SWIG version.
>>
>> git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@253262
>> 91177308-0d34-0410-b5e6-96231b3b80d8
>>
>>
>> On Wed, Nov 18, 2015 at 10:07 AM, Todd Fiala 
>> wrote:
>>
>>> Double checking now, if it happens in that lldb-modify script, we're
>>> covered.  Otherwise I need to adjust...  (the bulk of the rewrite 
>>> happened
>>> on Friday/Sunday).
>>>
>>> On Wed, Nov 18, 2015 at 9:47 AM, Zachary Turner 
>>> wrote:
>>>
 Just to be sure, did you catch the change I made to the old scripts
 in the past few days to embed the swig version in the generated 
 lldb.py?
 Maybe you did, I just want to make sure that change is in your new 
 version.

 On Wed, Nov 18, 2015 at 9:38 AM Todd Fiala via lldb-commits <
 lldb-commits@lists.llvm.org> wrote:

> Author: tfiala
> Date: Wed Nov 18 11:36:15 2015
> New Revision: 253478
>
> URL: http://llvm.org/viewvc/llvm-project?rev=253478&view=rev
> Log:
> Switched cmake build from using buildSwigWrapperClases.py to the
> cleaned up version.
>
> This change does not introduce static bindings.  It is simply using
> the pylinted cleaned up code in prepare_bindings.py.
>
> If this breaks anyting, I'll revert immediately and figure out what
> needs to be addressed.  I'm looking to wrap up
> the cleanup aspect of the code change (pylinted, removal of code
> that
> implements existing python stdlib code, fixes for Xcode adoption,
> etc.).
>
> Modified:
> lldb/trunk/CMakeLists.txt
> lldb/trunk/scripts/CMakeLists.txt
>
> Modified: lldb/trunk/CMakeLists.txt
> URL:
> http://llvm.org/viewvc/llvm-project/lldb/trunk/CMakeLists.txt?rev=253478&r1=253477&r2=253478&view=diff
>
> ==
> --- lldb/trunk/CMakeLists.txt (original)
> +++ lldb/trunk/CMakeLists.txt Wed Nov 18 11:36:15 2015
> @@ -33,6 +33,7 @

Re: [Lldb-commits] [lldb] r253501 - Fix CMake dependency on lldb.py

[Todd Fiala via lldb-commits]

I don't *think* that's right?  (At least, not for Linux).

It's not coming from the source dir.  It gets generated into the binary
directory.  Or - maybe the Windows ones write the output into the source
tree?  Do we need to conditionalize the location of lldb.py based on the
build?

-Todd

On Wed, Nov 18, 2015 at 1:09 PM, Zachary Turner via lldb-commits <
lldb-commits@lists.llvm.org> wrote:

> Author: zturner
> Date: Wed Nov 18 15:09:55 2015
> New Revision: 253501
>
> URL: http://llvm.org/viewvc/llvm-project?rev=253501&view=rev
> Log:
> Fix CMake dependency on lldb.py
>
> Modified:
> lldb/trunk/CMakeLists.txt
>
> Modified: lldb/trunk/CMakeLists.txt
> URL:
> http://llvm.org/viewvc/llvm-project/lldb/trunk/CMakeLists.txt?rev=253501&r1=253500&r2=253501&view=diff
>
> ==
> --- lldb/trunk/CMakeLists.txt (original)
> +++ lldb/trunk/CMakeLists.txt Wed Nov 18 15:09:55 2015
> @@ -33,7 +33,7 @@ if (NOT LLDB_DISABLE_PYTHON)
>  add_custom_target( finish_swig ALL
>  COMMAND ${PYTHON_EXECUTABLE}
> ${CMAKE_CURRENT_SOURCE_DIR}/scripts/finishSwigWrapperClasses.py
> "--srcRoot=${LLDB_SOURCE_DIR}"
> "--targetDir=${CMAKE_CURRENT_BINARY_DIR}/scripts"
> "--cfgBldDir=${CMAKE_CURRENT_BINARY_DIR}/scripts"
> "--prefix=${CMAKE_BINARY_DIR}"
> "--cmakeBuildConfiguration=${CMAKE_CFG_INTDIR}" -m
>  DEPENDS
> ${CMAKE_CURRENT_SOURCE_DIR}/scripts/finishSwigWrapperClasses.py
> -DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/lldb.py
> +DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/scripts/lldb.py
>  COMMENT "Python script sym-linking LLDB Python API")
>  # We depend on liblldb being built before we can do this step.
>  add_dependencies(finish_swig liblldb lldb-argdumper)
>
>
> ___
> lldb-commits mailing list
> lldb-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
>



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

Re: [Lldb-commits] [lldb] r253501 - Fix CMake dependency on lldb.py

[Todd Fiala via lldb-commits]

(good catch :-) )

On Wed, Nov 18, 2015 at 1:20 PM, Todd Fiala  wrote:

> Nope, I'm wrong.  Sorry!
>
> On Wed, Nov 18, 2015 at 1:15 PM, Todd Fiala  wrote:
>
>> I don't *think* that's right?  (At least, not for Linux).
>>
>> It's not coming from the source dir.  It gets generated into the binary
>> directory.  Or - maybe the Windows ones write the output into the source
>> tree?  Do we need to conditionalize the location of lldb.py based on the
>> build?
>>
>> -Todd
>>
>> On Wed, Nov 18, 2015 at 1:09 PM, Zachary Turner via lldb-commits <
>> lldb-commits@lists.llvm.org> wrote:
>>
>>> Author: zturner
>>> Date: Wed Nov 18 15:09:55 2015
>>> New Revision: 253501
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=253501&view=rev
>>> Log:
>>> Fix CMake dependency on lldb.py
>>>
>>> Modified:
>>> lldb/trunk/CMakeLists.txt
>>>
>>> Modified: lldb/trunk/CMakeLists.txt
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/lldb/trunk/CMakeLists.txt?rev=253501&r1=253500&r2=253501&view=diff
>>>
>>> ==
>>> --- lldb/trunk/CMakeLists.txt (original)
>>> +++ lldb/trunk/CMakeLists.txt Wed Nov 18 15:09:55 2015
>>> @@ -33,7 +33,7 @@ if (NOT LLDB_DISABLE_PYTHON)
>>>  add_custom_target( finish_swig ALL
>>>  COMMAND ${PYTHON_EXECUTABLE}
>>> ${CMAKE_CURRENT_SOURCE_DIR}/scripts/finishSwigWrapperClasses.py
>>> "--srcRoot=${LLDB_SOURCE_DIR}"
>>> "--targetDir=${CMAKE_CURRENT_BINARY_DIR}/scripts"
>>> "--cfgBldDir=${CMAKE_CURRENT_BINARY_DIR}/scripts"
>>> "--prefix=${CMAKE_BINARY_DIR}"
>>> "--cmakeBuildConfiguration=${CMAKE_CFG_INTDIR}" -m
>>>  DEPENDS
>>> ${CMAKE_CURRENT_SOURCE_DIR}/scripts/finishSwigWrapperClasses.py
>>> -DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/lldb.py
>>> +DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/scripts/lldb.py
>>>  COMMENT "Python script sym-linking LLDB Python API")
>>>  # We depend on liblldb being built before we can do this step.
>>>  add_dependencies(finish_swig liblldb lldb-argdumper)
>>>
>>>
>>> ___
>>> lldb-commits mailing list
>>> lldb-commits@lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
>>>
>>
>>
>>
>> --
>> -Todd
>>
>
>
>
> --
> -Todd
>



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

Re: [Lldb-commits] [lldb] r253501 - Fix CMake dependency on lldb.py

[Todd Fiala via lldb-commits]

Nope, I'm wrong.  Sorry!

On Wed, Nov 18, 2015 at 1:15 PM, Todd Fiala  wrote:

> I don't *think* that's right?  (At least, not for Linux).
>
> It's not coming from the source dir.  It gets generated into the binary
> directory.  Or - maybe the Windows ones write the output into the source
> tree?  Do we need to conditionalize the location of lldb.py based on the
> build?
>
> -Todd
>
> On Wed, Nov 18, 2015 at 1:09 PM, Zachary Turner via lldb-commits <
> lldb-commits@lists.llvm.org> wrote:
>
>> Author: zturner
>> Date: Wed Nov 18 15:09:55 2015
>> New Revision: 253501
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=253501&view=rev
>> Log:
>> Fix CMake dependency on lldb.py
>>
>> Modified:
>> lldb/trunk/CMakeLists.txt
>>
>> Modified: lldb/trunk/CMakeLists.txt
>> URL:
>> http://llvm.org/viewvc/llvm-project/lldb/trunk/CMakeLists.txt?rev=253501&r1=253500&r2=253501&view=diff
>>
>> ==
>> --- lldb/trunk/CMakeLists.txt (original)
>> +++ lldb/trunk/CMakeLists.txt Wed Nov 18 15:09:55 2015
>> @@ -33,7 +33,7 @@ if (NOT LLDB_DISABLE_PYTHON)
>>  add_custom_target( finish_swig ALL
>>  COMMAND ${PYTHON_EXECUTABLE}
>> ${CMAKE_CURRENT_SOURCE_DIR}/scripts/finishSwigWrapperClasses.py
>> "--srcRoot=${LLDB_SOURCE_DIR}"
>> "--targetDir=${CMAKE_CURRENT_BINARY_DIR}/scripts"
>> "--cfgBldDir=${CMAKE_CURRENT_BINARY_DIR}/scripts"
>> "--prefix=${CMAKE_BINARY_DIR}"
>> "--cmakeBuildConfiguration=${CMAKE_CFG_INTDIR}" -m
>>  DEPENDS
>> ${CMAKE_CURRENT_SOURCE_DIR}/scripts/finishSwigWrapperClasses.py
>> -DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/lldb.py
>> +DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/scripts/lldb.py
>>  COMMENT "Python script sym-linking LLDB Python API")
>>  # We depend on liblldb being built before we can do this step.
>>  add_dependencies(finish_swig liblldb lldb-argdumper)
>>
>>
>> ___
>> lldb-commits mailing list
>> lldb-commits@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
>>
>
>
>
> --
> -Todd
>



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

Re: [Lldb-commits] [lldb] r253478 - Switched cmake build from using buildSwigWrapperClases.py to the cleaned up version.

[Todd Fiala via lldb-commits]

Sure thing.

I'll get the finish-bindings script taken care of in another pass after
T-day week.

On Wed, Nov 18, 2015 at 1:13 PM, Zachary Turner  wrote:

> Tested this on Windows, seems to work fine.  r253501 has a minor fix that
> was causing a CMake warning, but overall everything works great.  Happy to
> see progress on this front.
>
> On Wed, Nov 18, 2015 at 12:47 PM Todd Fiala  wrote:
>
>> BTW if you cook up something on the swig-as-a-service end that ends up
>> working to eliminate the need for swig, I'll be happy to remove the static
>> binding support at that point.
>>
>> -Todd
>>
>> On Wed, Nov 18, 2015 at 12:45 PM, Todd Fiala 
>> wrote:
>>
>>>
>>> On Wed, Nov 18, 2015 at 11:55 AM, Zachary Turner 
>>> wrote:
>>>
 By the way, it would be great if we could kill this
 modify-lldb-python.py.

>>>
>>> I'm totally up for that.
>>>
>>>
   It seems like a total hackjob, and there's nothing it does that can't
 be done better by wrapping the lldb module instead of modifying it.

 For example, it goes through and injects a bunch of methods to classes
 in the lldb module.  But if, instead of renaming lldb.py to __init__.py, we
 renamed it to lldb_internal.py, and then we can actually check in an
 __init__.py that does this:

 from lldb_internal import *

 # Loop over each class in lldb_internal, injecting methods
 # and modifying the types / classes as necessary

 Then this would be much better, as it eliminates a post processing step
 and allows easier maintenance of this code.


>>> Sounds like a great idea.  I'd love to get rid of some post-processing
>>> steps.
>>>
>>>

 On Wed, Nov 18, 2015 at 10:37 AM Zachary Turner 
 wrote:

> Yea, this is the right one.  Thanks!  I haven't tested this yet, but I
> will later.  (Our buildbot currently builds with LLDB_DISABLE_PYTHON=1, so
> if there is a problem with this, the Windows buildbot wouldn't pick it up,
> although the others probably would)
>
> On Wed, Nov 18, 2015 at 10:14 AM Todd Fiala 
> wrote:
>
>> If I have that right, we're fine.  The prepare_bindings.py still
>> calls modify-python-lldb.py.
>>
>> scripts/prepare_bindings.py is meant to be the same as
>> createSwigBindings.py, and scripts/python/prepare_binding_Python.py is
>> meant to be the same as buildSwigPython.py.
>>
>> Once I make sure that I haven't broken anything for anybody with it,
>> I'll get rid of the other scripts.
>>
>> On Wed, Nov 18, 2015 at 10:09 AM, Todd Fiala 
>> wrote:
>>
>>> You're talking about this change, right?  (I'm looking at it now...)
>>>
>>> commit cc353bbc992ab324aef395c54a2a46fcaaa3855b
>>> Author: Zachary Turner 
>>> Date:   Mon Nov 16 22:40:20 2015 +
>>>
>>> Insert the SWIG version into LLDB's __init__.py
>>>
>>> The goal here is to allow us to add skip / xfail decorators
>>> based on SWIG version.
>>>
>>> git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@253262
>>> 91177308-0d34-0410-b5e6-96231b3b80d8
>>>
>>>
>>> On Wed, Nov 18, 2015 at 10:07 AM, Todd Fiala 
>>> wrote:
>>>
 Double checking now, if it happens in that lldb-modify script,
 we're covered.  Otherwise I need to adjust...  (the bulk of the rewrite
 happened on Friday/Sunday).

 On Wed, Nov 18, 2015 at 9:47 AM, Zachary Turner >>> > wrote:

> Just to be sure, did you catch the change I made to the old
> scripts in the past few days to embed the swig version in the 
> generated
> lldb.py?  Maybe you did, I just want to make sure that change is in 
> your
> new version.
>
> On Wed, Nov 18, 2015 at 9:38 AM Todd Fiala via lldb-commits <
> lldb-commits@lists.llvm.org> wrote:
>
>> Author: tfiala
>> Date: Wed Nov 18 11:36:15 2015
>> New Revision: 253478
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=253478&view=rev
>> Log:
>> Switched cmake build from using buildSwigWrapperClases.py to the
>> cleaned up version.
>>
>> This change does not introduce static bindings.  It is simply
>> using
>> the pylinted cleaned up code in prepare_bindings.py.
>>
>> If this breaks anyting, I'll revert immediately and figure out
>> what
>> needs to be addressed.  I'm looking to wrap up
>> the cleanup aspect of the code change (pylinted, removal of code
>> that
>> implements existing python stdlib code, fixes for Xcode adoption,
>> etc.).
>>
>> Modified:
>> lldb/trunk/CMakeLists.txt
>> lldb/trunk/scripts/CMakeLists.txt
>>
>> Modified: lldb/trunk/CMakeLists.txt
>> URL:
>> http://llvm.org/viewvc/llvm

[Lldb-commits] [lldb] r253505 - [TestExitDuringStep] Adjust after a recent type map change.

[Siva Chandra via lldb-commits]

Author: sivachandra
Date: Wed Nov 18 15:22:29 2015
New Revision: 253505

URL: http://llvm.org/viewvc/llvm-project?rev=253505&view=rev
Log:
[TestExitDuringStep] Adjust after a recent type map change.

Reviewers: zturner

Subscribers: lldb-commits

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

Modified:

lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/exit_during_step/TestExitDuringStep.py

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/exit_during_step/TestExitDuringStep.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/exit_during_step/TestExitDuringStep.py?rev=253505&r1=253504&r2=253505&view=diff
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/exit_during_step/TestExitDuringStep.py
 (original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/exit_during_step/TestExitDuringStep.py
 Wed Nov 18 15:22:29 2015
@@ -98,7 +98,8 @@ class ExitDuringStepTestCase(TestBase):
 stepping_thread = None
 for thread in process:
 expected_bp_desc = "breakpoint %s." % self.bp_num
-if expected_bp_desc in thread.GetStopDescription(100):
+stop_desc = thread.GetStopDescription(100)
+if stop_desc and (expected_bp_desc in stop_desc):
 stepping_thread = thread
 break
 self.assertTrue(stepping_thread != None, "unable to find thread 
stopped at %s" % expected_bp_desc)


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

Re: [Lldb-commits] [PATCH] D14718: Insert the SWIG version into LLDB's __init__.py

[Todd Fiala via lldb-commits]

tfiala added a comment.

We  can close this one out too, right?


http://reviews.llvm.org/D14718



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

Re: [Lldb-commits] [PATCH] D14726: Add the ability to skip or xfail based on Python and/or SWIG version

[Todd Fiala via lldb-commits]

tfiala added a comment.

Is this one ready to close out?


http://reviews.llvm.org/D14726



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

Re: [Lldb-commits] [PATCH] D14783: Remove superseded buildSwigWrapperClasses.py and buildSwigPython.py classes

[Todd Fiala via lldb-commits]

tfiala added a comment.

Looks like with your change in r253501, we are okay to delete these?


http://reviews.llvm.org/D14783



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

Re: [Lldb-commits] [PATCH] D14783: Remove superseded buildSwigWrapperClasses.py and buildSwigPython.py classes

[Zachary Turner via lldb-commits]

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

As long as with your new script these are no longer being called anywhere, 
should be safe to remove.


http://reviews.llvm.org/D14783



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

Re: [Lldb-commits] [PATCH] D14783: Remove superseded buildSwigWrapperClasses.py and buildSwigPython.py classes

[Todd Fiala via lldb-commits]

tfiala added a comment.

Okay, thanks.  I'll grep the source base first to make sure I'm not missing 
anything else.


http://reviews.llvm.org/D14783



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

Re: [Lldb-commits] [PATCH] D14783: Remove superseded buildSwigWrapperClasses.py and buildSwigPython.py classes

[Todd Fiala via lldb-commits]

tfiala updated this revision to Diff 40560.
tfiala added a comment.

Missed one reference in a cmake custom command dependency.  Fixed in latest 
diff.


http://reviews.llvm.org/D14783

Files:
  scripts/CMakeLists.txt
  scripts/Python/buildSwigPython.py
  scripts/buildSwigWrapperClasses.py

Index: scripts/buildSwigWrapperClasses.py
===
--- scripts/buildSwigWrapperClasses.py
+++ /dev/null
@@ -1,451 +0,0 @@
-""" SWIG creates Python C++ Script Bridge wrapper code Windows/LINUX/OSX platform
-
---
-File:   buildSwigWrapperClasses.py
-
-Overview:   Python script(s) to build the SWIG Python C++ Script
-Bridge wrapper code on the Windows/LINUX/OSX platform.
-The Python scripts are equivalent to the shell script (.sh)
-files.
-For each scripting language lib lldb supports, we need to
-create the appropriate Script Bridge wrapper classes for
-that language so that users can call Script Bridge
-functions from within the script interpreter.
-We use SWIG to help create the appropriate wrapper
-classes/functions for the scripting language.  In some
-cases the file generated by SWIG may need some tweaking
-before it is completely ready to use.
-
-Gotchas:For Windows OS it is assumed the SWIG executable can be
-found in the %PATH% environmental variable.
-
-Copyright:  None.
---
-
-"""
-
-# Python modules:
-import sys  # Provide argument parsing
-import os   # Provide directory and file handling
-
-# Third party modules:
-
-# In-house modules:
-import utilsArgsParse   # Parse and validate this script's input arguments
-import utilsOsType  # Determine the OS type this script is running on
-import utilsDebug   # Debug Python scripts
-
-# Instantiations:
-gbDbgVerbose = False   # True = Turn on script function tracing, False = off.
-gbDbgFlag = False  # Global debug mode flag, set by input parameter
-# --dbgFlag. True = operate in debug mode.
-gbMakeFileFlag = False # True = yes called from makefile system, False = not.
-gbSwigGenDepFileFlag = False   # True = SWIG generate a dependency file.
-
-# User facing text:
-strMsgErrorNoMain = "Program called by another Python script not allowed"
-strExitMsgSuccess = "Program successful"
-strExitMsgError = "Program error: "
-strParameter = "Parameter: "
-strMsgErrorOsTypeUnknown = "Unable to determine OS type"
-strSwigFileFound = "Found the \'lldb.swig\' file\n"
-strSwigFileFoundNotFound = "Unable to locate the file \'%s\'"
-strSwigExeFileNotFound = "Unable to locate the SWIG executable file \'swig\'"
-strSwigScriptDirNotFound = "Unable to locate the SWIG script directory \'/script\'"
-strSwigScriptNotFound = "Unable to locate the SWIG script file \'%s\' in \'%s\'. Is it a script directory?"
-strSwigScriptLangFound = "Found \'%s\' build script."
-strSwigScriptLangsFound = "Found the following script languages:"
-strSwigExecuteMsg = "Executing \'%s\' build script..."
-strSwigExecuteError = "Executing \'%s\' build script failed: "
-strHelpInfo = "\
-Python script(s) to build the SWIG Python C++ Script \n\
-Bridge wrapper code on various platforms.  The Python \n\
-scripts are equivalent to the shell script (.sh) files \n\
-run on others platforms.\n\
-Args:   -h  (optional) Print help information on this program.\n\
--d  (optional) Determines whether or not this script\n\
-outputs additional information when running.\n\
--m  (optional) Specify called from Makefile system.\n\
--M  (optional) Specify want SWIG to generate a dependency \n\
-file.\n\
---srcRoot=  The root of the lldb source tree.\n\
---targetDir=Where the lldb framework/shared library gets put.\n\
---cfgBldDir=(optional) Where the build-swig-Python-LLDB.py program \n\
-will put the lldb.py file it generated from running\n\
-SWIG.\n\
---prefix=   (optional) Is the root directory used to determine where\n\
-third-party modules for scripting languages should\n\
-be installed. Where non-Darwin systems want to put\n\
-the .py and .so files so that Python can find them\n\
-automatically. Python install directory.\n\
---argsFile= The args are read from a file instead of the\n\
-command line. Other command line args are ignored.\n\
---swigExecutable=   Full path of swig executable.\n\
-\n\
-Usage:\n\
-buildSwigWrapperClasses.py --srcRoot=ADirPath --targetDir=ADirPath\n\
---cfgBldDir=ADirPath --pr

Re: [Lldb-commits] [PATCH] D14783: Remove superseded buildSwigWrapperClasses.py and buildSwigPython.py classes

[Todd Fiala via lldb-commits]

tfiala added a comment.

Aside from that one fix in the second patch, a grep for those two scripts came 
back clean on the source tree.


http://reviews.llvm.org/D14783



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

[Lldb-commits] [lldb] r253513 - Remove superseded buildSwigWrapperClasses.py and buildSwigPython.py classes

[Todd Fiala via lldb-commits]

Author: tfiala
Date: Wed Nov 18 16:21:47 2015
New Revision: 253513

URL: http://llvm.org/viewvc/llvm-project?rev=253513&view=rev
Log:
Remove superseded buildSwigWrapperClasses.py and buildSwigPython.py classes

This closes:
http://reviews.llvm.org/D14783

Removed:
lldb/trunk/scripts/Python/buildSwigPython.py
lldb/trunk/scripts/buildSwigWrapperClasses.py
Modified:
lldb/trunk/scripts/CMakeLists.txt

Modified: lldb/trunk/scripts/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/scripts/CMakeLists.txt?rev=253513&r1=253512&r2=253513&view=diff
==
--- lldb/trunk/scripts/CMakeLists.txt (original)
+++ lldb/trunk/scripts/CMakeLists.txt Wed Nov 18 16:21:47 2015
@@ -16,7 +16,7 @@ add_custom_command(
   DEPENDS ${SWIG_SOURCES}
   DEPENDS ${SWIG_INTERFACES}
   DEPENDS ${SWIG_HEADERS}
-  DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/Python/buildSwigPython.py
+  DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/Python/prepare_binding_Python.py
   DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/Python/modify-python-lldb.py
   COMMAND ${PYTHON_EXECUTABLE} ${CMAKE_CURRENT_SOURCE_DIR}/prepare_bindings.py 
"--srcRoot=${LLDB_SOURCE_DIR}" "--targetDir=${CMAKE_CURRENT_BINARY_DIR}" 
"--cfgBldDir=${CMAKE_CURRENT_BINARY_DIR}" "--prefix=${CMAKE_BINARY_DIR}" 
"--swigExecutable=${SWIG_EXECUTABLE}"
   COMMENT "Python script building LLDB Python wrapper")

Removed: lldb/trunk/scripts/Python/buildSwigPython.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/scripts/Python/buildSwigPython.py?rev=253512&view=auto
==
--- lldb/trunk/scripts/Python/buildSwigPython.py (original)
+++ lldb/trunk/scripts/Python/buildSwigPython.py (removed)
@@ -1,782 +0,0 @@
-""" Python SWIG wrapper creation script Windows/LINUX/OSX platform
-
---
-File:  buildSwigPython.py
-
-Overview:  Creates SWIG Python C++ Script Bridge wrapper code. This
-   script is called by build-swig-wrapper-classes.py in turn.
-
-Gotchas:   Python debug complied pythonXX_d.lib is required for SWIG
-   to build correct LLDBWrapperPython.cpp in order for Visual
-   Studio to compile successfully. The release version of the
-   Python lib will not work.
-   LLDB (dir) CMakeLists.txt uses windows environmental
-   variables $PYTHON_INCLUDE and $PYTHON_LIB to locate
-   Python files required for the build.
-
-Copyright: None.
---
-
-"""
-
-# Python modules:
-import os # Provide directory and file handling, determine OS 
information
-import sys# sys.executable
-import subprocess # Call external programs
-import shutil # File handling
-
-# Third party modules:
-
-# In-house modules:
-import utilsOsType # Determine the OS type this script is running on
-import utilsDebug  # Debug Python scripts
-
-# User facing text:
-strMsgLldbDisablePythonEnv = "Python build aborted as LLDB_DISABLE_PYTHON \
-environmental variable is defined"
-strMsgLldbDisableGccEnv = "Python build aborted as 
GCC_PREPROCESSOR_DEFINITIONS \
-environmental variable is defined"
-strMsgHdrFiles = "Header files are:"
-strMsgIFaceFiles = "SWIG interface files are"
-strErrMsgProgFail = "Program failure: "
-strMsgFileNewrSwigOpFile = "\'%s\' is newer than \'%s\'\nSWIG file will need 
to be re-built"
-strMsgFileNotExist = "\'%s\' could not be found\nSWIG file will need to be 
re-built"
-strErrMsgOsTypeUnknown = "Unable to determine current OS type"
-strMsgNotNeedUpdate = "Everything is up-to-date"
-strMsgSwigNeedRebuild = "SWIG needs to be re-run"
-strErrMsgSwigParamsMissing = "This script was not passed '--swigExecutable' as 
required."
-strMsgSwigExecute = "SWIG executing the following:\n\'%s'"
-strErrMsgSwigExecute = "SWIG failed: %s"
-strErrMsgPythonExecute = "Python script '%s' failed: %s"
-strMsgSwigNoGenDep = "SWIG ran with no generated dependencies, script exit 
early"
-strMsgSwigGenDep = "SWIG ran and generated dependencies, script exit early, 
deleted '%s'"
-strErrMsgFrameWkPyDirNotExist = "Unable to find the LLDB. Framework directory 
is '%s'"
-strMsgFoundLldbFrameWkDir = "Found '%s'"
-strErrMsgModifyPythonLldbPyFileNotFound = "Unable to find '%s' in '%s'"
-
-#++---
-# Details: Retrieve the list of hard coded lldb header file names and
-#  put in the program's dictArgs map container. Make paths compatible
-#  with the current OS.
-#  Note this does not necessarily match the content of those
-#  directories. The resultant header string is inserted into the
-#  dictionary vDictArgs key "--headerFiles".
-# Args:vDictArgs - (RW) Program input parameters.
-# Returns: Bool - True = success, Fals

Re: [Lldb-commits] [PATCH] D14783: Remove superseded buildSwigWrapperClasses.py and buildSwigPython.py classes

[Zachary Turner via lldb-commits]

zturner added a comment.

sounds good


http://reviews.llvm.org/D14783



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

Re: [Lldb-commits] [PATCH] D14783: Remove superseded buildSwigWrapperClasses.py and buildSwigPython.py classes

[Todd Fiala via lldb-commits]

tfiala closed this revision.
tfiala added a comment.

Committed here:
r253513.


http://reviews.llvm.org/D14783



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

[Lldb-commits] [PATCH] D14790: cmake: add -DLLDB_ALLOW_STATIC_BINDINGS=1, defaults off

[Todd Fiala via lldb-commits]

tfiala created this revision.
tfiala added reviewers: labath, zturner, spyffe.
tfiala added a subscriber: lldb-commits.

This change does the following:
* Adds a cached LLDB_ALLOW_STATIC_BINDINGS variable, defaults to off/false
* If specified, flips on the --allow-static-binding flag to prepare_bindings.py
* Removes the REQUIRED marker in cmake-based swig discovery, but adds a fatal 
error for cmake if swig isn't found when LLDB_ALLOW_STATIC_BINDINGS is also not 
set.  i.e. unless -DLLDB_ALLOW_STATIC_BINDINGS=1 is specified on the command 
line, not finding swig will fail the cmake step as before.

As noted in a prior thread, I will be happy to rip this out once we no longer 
require swig via other means.  This can be considered temporary until that time.

http://reviews.llvm.org/D14790

Files:
  cmake/modules/LLDBConfig.cmake
  scripts/CMakeLists.txt

Index: scripts/CMakeLists.txt
===
--- scripts/CMakeLists.txt
+++ scripts/CMakeLists.txt
@@ -9,16 +9,25 @@
   ${LLDB_SOURCE_DIR}/include/lldb/lldb-versioning.h
 )
 
-find_package(SWIG REQUIRED)
+set(PREPARE_BINDINGS_ARGS "--src-root=${LLDB_SOURCE_DIR}" 
"--target-dir=${CMAKE_CURRENT_BINARY_DIR}" 
"--config-build-dir=${CMAKE_CURRENT_BINARY_DIR}" "--prefix=${CMAKE_BINARY_DIR}")
+
+find_package(SWIG)
+if( ${SWIG_FOUND} )
+set(PREPARE_BINDINGS_ARGS ${PREPARE_BINDINGS_ARGS} 
"--swig-executable=${SWIG_EXECUTABLE}")
+elseif( ${LLDB_ALLOW_STATIC_BINDINGS} )
+set(PREPARE_BINDINGS_ARGS ${PREPARE_BINDINGS_ARGS} --find-swig 
--allow-static-binding)
+else()
+message( FATAL_ERROR "swig not found and static bindings not permitted - 
install swig or specify -DLLDB_ALLOW_STATIC_BINDINGS=1")
+endif()
 add_custom_command(
   OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/LLDBWrapPython.cpp
   OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/lldb.py
   DEPENDS ${SWIG_SOURCES}
   DEPENDS ${SWIG_INTERFACES}
   DEPENDS ${SWIG_HEADERS}
   DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/Python/buildSwigPython.py
   DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/Python/modify-python-lldb.py
-  COMMAND ${PYTHON_EXECUTABLE} ${CMAKE_CURRENT_SOURCE_DIR}/prepare_bindings.py 
"--srcRoot=${LLDB_SOURCE_DIR}" "--targetDir=${CMAKE_CURRENT_BINARY_DIR}" 
"--cfgBldDir=${CMAKE_CURRENT_BINARY_DIR}" "--prefix=${CMAKE_BINARY_DIR}" 
"--swigExecutable=${SWIG_EXECUTABLE}"
+  COMMAND ${PYTHON_EXECUTABLE} ${CMAKE_CURRENT_SOURCE_DIR}/prepare_bindings.py 
${PREPARE_BINDINGS_ARGS}
   COMMENT "Python script building LLDB Python wrapper")
 set_source_files_properties(${CMAKE_CURRENT_BINARY_DIR}/LLDBWrapPython.cpp 
PROPERTIES GENERATED 1)
 set_source_files_properties(${CMAKE_CURRENT_BINARY_DIR}/lldb.py PROPERTIES 
GENERATED 1)
Index: cmake/modules/LLDBConfig.cmake
===
--- cmake/modules/LLDBConfig.cmake
+++ cmake/modules/LLDBConfig.cmake
@@ -23,6 +23,9 @@
 
 set(LLDB_DISABLE_PYTHON ${LLDB_DEFAULT_DISABLE_PYTHON} CACHE BOOL
   "Disables the Python scripting integration.")
+set(LLDB_ALLOW_STATIC_BINDINGS FALSE CACHE BOOL
+  "Enable using static/baked language bindings if swig is not present.")
+message(LLDB_ALLOW_STATIC_BINDINGS: ${LLDB_ALLOW_STATIC_BINDINGS})
 set(LLDB_DISABLE_CURSES ${LLDB_DEFAULT_DISABLE_CURSES} CACHE BOOL
   "Disables the Curses integration.")
 


Index: scripts/CMakeLists.txt
===
--- scripts/CMakeLists.txt
+++ scripts/CMakeLists.txt
@@ -9,16 +9,25 @@
   ${LLDB_SOURCE_DIR}/include/lldb/lldb-versioning.h
 )
 
-find_package(SWIG REQUIRED)
+set(PREPARE_BINDINGS_ARGS "--src-root=${LLDB_SOURCE_DIR}" "--target-dir=${CMAKE_CURRENT_BINARY_DIR}" "--config-build-dir=${CMAKE_CURRENT_BINARY_DIR}" "--prefix=${CMAKE_BINARY_DIR}")
+
+find_package(SWIG)
+if( ${SWIG_FOUND} )
+set(PREPARE_BINDINGS_ARGS ${PREPARE_BINDINGS_ARGS} "--swig-executable=${SWIG_EXECUTABLE}")
+elseif( ${LLDB_ALLOW_STATIC_BINDINGS} )
+set(PREPARE_BINDINGS_ARGS ${PREPARE_BINDINGS_ARGS} --find-swig --allow-static-binding)
+else()
+message( FATAL_ERROR "swig not found and static bindings not permitted - install swig or specify -DLLDB_ALLOW_STATIC_BINDINGS=1")
+endif()
 add_custom_command(
   OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/LLDBWrapPython.cpp
   OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/lldb.py
   DEPENDS ${SWIG_SOURCES}
   DEPENDS ${SWIG_INTERFACES}
   DEPENDS ${SWIG_HEADERS}
   DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/Python/buildSwigPython.py
   DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/Python/modify-python-lldb.py
-  COMMAND ${PYTHON_EXECUTABLE} ${CMAKE_CURRENT_SOURCE_DIR}/prepare_bindings.py "--srcRoot=${LLDB_SOURCE_DIR}" "--targetDir=${CMAKE_CURRENT_BINARY_DIR}" "--cfgBldDir=${CMAKE_CURRENT_BINARY_DIR}" "--prefix=${CMAKE_BINARY_DIR}" "--swigExecutable=${SWIG_EXECUTABLE}"
+  COMMAND ${PYTHON_EXECUTABLE} ${CMAKE_CURRENT_SOURCE_DIR}/prepare_bindings.py ${PREPARE_BINDINGS_ARGS}
   COMMENT "Python script building LLDB Python wrapper")
 set_source_files_properties(${CMAKE_CURRENT_BINARY_DIR}/LL

Re: [Lldb-commits] [PATCH] D14790: cmake: add -DLLDB_ALLOW_STATIC_BINDINGS=1, defaults off

[Todd Fiala via lldb-commits]

tfiala added a comment.

BTW I've tested this with the static bindings we use on OS X on Ubuntu 14.04 
with a clang 3.6 build.


http://reviews.llvm.org/D14790



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

Re: [Lldb-commits] [PATCH] D14790: cmake: add -DLLDB_ALLOW_STATIC_BINDINGS=1, defaults off

[Zachary Turner via lldb-commits]

zturner added a comment.

If nobody on the Apple side is using CMake, then I'm still not clear why we 
need this.  Everyone using CMake already will continue to work fine using 
dynamically generated bindings, right?

I still don't agree with the need for the static bindings in any configuration, 
but if it's entirely on the Xcode side then there's not much I can do about it. 
 But I really don't want this in the CMake build, and nobody else who depends 
on the CMake build has spoken up saying they need this.


http://reviews.llvm.org/D14790



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

Re: [Lldb-commits] [PATCH] D14790: cmake: add -DLLDB_ALLOW_STATIC_BINDINGS=1, defaults off

[Todd Fiala via lldb-commits]

tfiala added a comment.

In http://reviews.llvm.org/D14790#292220, @zturner wrote:

> If nobody on the Apple side is using CMake, then I'm still not clear why we 
> need this.  Everyone using CMake already will continue to work fine using 
> dynamically generated bindings, right?


I'm at Apple.  I build Linux.  I use cmake.

> I still don't agree with the need for the static bindings in any 
> configuration, but if it's entirely on the Xcode side then there's not much I 
> can do about it.  But I really don't want this in the CMake build, and nobody 
> else who depends on the CMake build has spoken up saying they need this.





http://reviews.llvm.org/D14790



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

Re: [Lldb-commits] [PATCH] D14790: cmake: add -DLLDB_ALLOW_STATIC_BINDINGS=1, defaults off

[Zachary Turner via lldb-commits]

zturner added a comment.

So you can't install swig on your Linux machines either?

I really can't wrap my head around why we need this.  What is the problem with 
installing swig, given that we need to install other software already?

The build instructions here 
[http://lldb.llvm.org/build.html#BuildingLldbOnLinux] say you need to install 
swig, libedit, python, and ninja.  You need either git or svn too.  Why must we 
insist on supporting this configuration when it is not necessary?

I want the CMake build to build one way.


http://reviews.llvm.org/D14790



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

Re: [Lldb-commits] [PATCH] D14790: cmake: add -DLLDB_ALLOW_STATIC_BINDINGS=1, defaults off

[Todd Fiala via lldb-commits]

tfiala added a comment.

(And I also work on cmake-based OS X lldb when there are issues that break 
there).


http://reviews.llvm.org/D14790



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

Re: [Lldb-commits] [PATCH] D14790: cmake: add -DLLDB_ALLOW_STATIC_BINDINGS=1, defaults off

[Todd Fiala via lldb-commits]

tfiala added a comment.

Keep in mind this is an opt-in flag.  No developers get the behavior unless 
they specifically ask for it.

I'm adding it because I specifically need it.


http://reviews.llvm.org/D14790



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

Re: [Lldb-commits] [PATCH] D14790: cmake: add -DLLDB_ALLOW_STATIC_BINDINGS=1, defaults off

[Todd Fiala via lldb-commits]

tfiala added a comment.

In http://reviews.llvm.org/D14790#292226, @zturner wrote:

> So you can't install swig on your Linux machines either?
>
> I really can't wrap my head around why we need this.  What is the problem 
> with installing swig, given that we need to install other software already?


Zachary, I appreciate your dislike of the idea.  And I have totally modified my 
approach to this to minimize its impact so that it is a no-op for everyone 
else.  And I am happy to remove this when we have an alternative to not require 
swig.

> The build instructions here 
> [http://lldb.llvm.org/build.html#BuildingLldbOnLinux] say you need to install 
> swig, libedit, python, and ninja.  You need either git or svn too.  Why must 
> we insist on supporting this configuration when it is not necessary?

> 

> I want the CMake build to build one way.


You are being obstructionist if you go with that statement.  You are not 
impacted by this change, so attempting to shoot it down based on you not liking 
it for reasons that your team doesn't care about is not a position that makes 
sense.  If I was forcing you to do something different, then we have something 
to work through if it caused undue harm.  When I need to get something done, 
and I'm tweaking it a lot to appease you, and you still come back with "no, I 
don't like this so, even though I'm not the one who has a requirement for it, 
I'm going to say I don't want it" seems counter to an supporting multiple 
groups with different objectives in the same source base.


http://reviews.llvm.org/D14790



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

Re: [Lldb-commits] [PATCH] D14790: cmake: add -DLLDB_ALLOW_STATIC_BINDINGS=1, defaults off

[Zachary Turner via lldb-commits]

zturner added a comment.

It's not that I don't like it.  I mean, it used to be, but it's a minor change. 
 At this point it's about that I've repeatedly asked for some kind of 
reasonable explanation about why swig is a contentious dependency, and the most 
I've gotten is "things are about to change".  I don't even know what that 
means, and plus it sounded like it was a statement about OSX.  But now all of a 
sudden it's abotu Linux too.  What do I make of that?

It's not that I don't like the change, it's that I don't want to add complexity 
to the build system for something that I simply do not understand the value of. 
 Installing swig is one command line on Linux, and one or two command lines on 
OSX.  So why do we need to add 15 lines of CMake code so that people don't have 
to do a one-time execution of one or two command lines the first time they ever 
check out and try to build LLDB?

That's what I don't get.  Maybe there's a reason, if so I'll LGTM it in a 
heartbeat, because it is a simple change.  But if so it hasn't been clearly 
communicated.


http://reviews.llvm.org/D14790



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

Re: [Lldb-commits] [PATCH] D14790: cmake: add -DLLDB_ALLOW_STATIC_BINDINGS=1, defaults off

[Zachary Turner via lldb-commits]

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

Anyway, just check it in.  The content of this patch is not worth arguing 
about.  What is worth arguing about, however, is that changes need to have some 
kind of reasonable justification.  "I don't want to install swig" is not -- to 
me -- a reasonable justification.  "I *need* to be able to not install swig" is 
a reasonable justification.  That's what I've been trying to get out of 
someone, but it hasn't come yet, despite many many requests.


http://reviews.llvm.org/D14790



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

[Lldb-commits] [PATCH] D14793: Enable saving of mini dumps with lldb process save-core.

[Adrian McCarthy via lldb-commits]

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

Enable the saving of a mini dump (on Windows) using the existing lldb save-core 
command.

Also plumbs a new method into SBProcess, and adds a very basic test to make 
sure it produces a file.

Future tests will open the mini dump in LLDB and make sure that it has the 
right information.

http://reviews.llvm.org/D14793

Files:
  include/lldb/API/SBProcess.h
  packages/Python/lldbsuite/test/functionalities/process_save_core/Makefile
  
packages/Python/lldbsuite/test/functionalities/process_save_core/TestProcessSaveCore.py
  packages/Python/lldbsuite/test/functionalities/process_save_core/main.cpp
  scripts/interface/SBProcess.i
  source/API/SBProcess.cpp
  source/Plugins/ObjectFile/PECOFF/CMakeLists.txt
  source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp
  source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.h
  source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFFMiniDump.cpp
  source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFFMiniDump.h

Index: source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFFMiniDump.h
===
--- /dev/null
+++ source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFFMiniDump.h
@@ -0,0 +1,24 @@
+//===-- ObjectFilePECOFFMiniDump.h --*- C++ -*-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#ifndef liblldb_ObjectFilePECOFFMiniDump_h_
+#define liblldb_ObjectFilePECOFFMiniDump_h_
+
+#include "lldb/Target/Process.h"
+
+namespace lldb_private {
+
+bool
+SaveMiniDump(const lldb::ProcessSP &process_sp,
+ const lldb_private::FileSpec &outfile,
+ lldb_private::Error &error);
+
+}  // namespace lldb_private
+
+#endif
Index: source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFFMiniDump.cpp
===
--- /dev/null
+++ source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFFMiniDump.cpp
@@ -0,0 +1,55 @@
+//===-- ObjectFilePECOFFMiniDump.cpp *- C++ -*-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+// This function is separated out from ObjectFilePECOFF.cpp to name avoid name
+// collisions with WinAPI preprocessor macros.
+
+#include "ObjectFilePECOFFMiniDump.h"
+#include "lldb/Host/FileSpec.h"
+#include "llvm/Support/ConvertUTF.h"
+
+#ifdef _WIN32
+#include "lldb/Host/windows/windows.h"
+#include   // for MiniDumpWriteDump
+#endif
+
+namespace lldb_private {
+
+bool
+SaveMiniDump(const lldb::ProcessSP &process_sp,
+ const lldb_private::FileSpec &outfile,
+ lldb_private::Error &error)
+{
+if (!process_sp) return false;
+#ifdef _WIN32
+HANDLE process_handle = ::OpenProcess(PROCESS_QUERY_INFORMATION | PROCESS_VM_READ, FALSE, process_sp->GetID());
+const std::string file_name = outfile.GetCString();
+std::wstring wide_name;
+wide_name.resize(file_name.size() + 1);
+char * result_ptr = reinterpret_cast(&wide_name[0]);
+const UTF8 *error_ptr = nullptr;
+if (!llvm::ConvertUTF8toWide(sizeof(wchar_t), file_name, result_ptr, error_ptr)) {
+error.SetErrorString("cannot convert file name");
+return false;
+}
+HANDLE file_handle = ::CreateFileW(wide_name.c_str(), GENERIC_WRITE, FILE_SHARE_READ, NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);
+const auto result = ::MiniDumpWriteDump(process_handle, process_sp->GetID(), file_handle, MiniDumpNormal, NULL, NULL, NULL);
+::CloseHandle(file_handle);
+::CloseHandle(process_handle);
+if (!result)
+{
+error.SetError(::GetLastError(), lldb::eErrorTypeWin32);
+return false;
+}
+return true;
+#endif
+return false;
+}
+
+}  // namesapce lldb_private
Index: source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.h
===
--- source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.h
+++ source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.h
@@ -95,6 +95,11 @@
  lldb_private::ModuleSpecList &specs);
 
 static bool
+SaveCore (const lldb::ProcessSP &process_sp,
+  const lldb_private::FileSpec &outfile,
+  lldb_private::Error &error);
+
+static bool
 MagicBytesMatch (lldb::DataBufferSP& data_sp);
 
 bool
Index: source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp
===
--- source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp
+++ source/Plugin

Re: [Lldb-commits] [PATCH] D14793: Enable saving of mini dumps with lldb process save-core.

[Zachary Turner via lldb-commits]

zturner added a reviewer: clayborg.
zturner added a comment.

+greg since this touches some SB stuff and the ObjectFile plugins.



Comment at: include/lldb/API/SBProcess.h:345-346
@@ +344,4 @@
+// Save the state of the process in a core file (or mini dump on Windows).
+lldb::SBError
+SaveCore(const char *file_name);
+

Greg, is there any reason why this couldn't be an `llvm::StringRef`?  I know 
historically we have used this char* mechanism, but it seems like `StringRef` 
could be a better, safer alternative than passing raw strings through the SB 
API.  As long as you provide an appropriate typemap, everything should work out.




Comment at: 
packages/Python/lldbsuite/test/functionalities/process_save_core/TestProcessSaveCore.py:20
@@ +19,3 @@
+@not_remote_testsuite_ready
+@skipUnlessWindows
+def test_windows_mini_dump (self):

How do you feel about `@skipIf(oslist=not_in(['windows']))`?

The generic skipIf and expectedFailure decorators were extended recently and 
are now flexible enough to handle unless cases, so I'm partial to the idea of 
eventually killing off the rest of the decorators, and just having a single one 
that handles everything.  But I want to dogfood the idea first and see what 
people think about it :)


Comment at: 
packages/Python/lldbsuite/test/functionalities/process_save_core/TestProcessSaveCore.py:32
@@ +31,3 @@
+self.assertTrue(process.Kill().Success())
+# Clean up the mini dump file.
+os.unlink(core)

Can you assert true that the file exists?  Is there some thing additional that 
we can add where you then load the core and try to read something out (say the 
executable name), and assert that it's equal to `a.out`?

Right now all we know is that there's a file.


Comment at: 
packages/Python/lldbsuite/test/functionalities/process_save_core/TestProcessSaveCore.py:33
@@ +32,3 @@
+# Clean up the mini dump file.
+os.unlink(core)
+

This isn't exception safe right now.  For example, it won't unlink the file if 
one the asserts fails.


Comment at: source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFFMiniDump.cpp:17
@@ +16,3 @@
+
+#ifdef _WIN32
+#include "lldb/Host/windows/windows.h"

I think it would be better to just not even compile this file on non-Windows.  
Exclude it at the CMake level, and have `SaveCore()` return false directly.  In 
the future we may add a way to deal with mini dumps outside of the Windows API, 
and then we can add that as a separate file like 
`ObjectFilePECOFFMiniDumpRaw.cpp` which can be used always, and then delete 
this one.


http://reviews.llvm.org/D14793



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

Re: [Lldb-commits] [PATCH] D14793: Enable saving of mini dumps with lldb process save-core.

[Greg Clayton via lldb-commits]

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

See inlined comments.



Comment at: include/lldb/API/SBProcess.h:344-346
@@ -343,1 +343,5 @@
 
+// Save the state of the process in a core file (or mini dump on Windows).
+lldb::SBError
+SaveCore(const char *file_name);
+

I don't want any llvm in our public API. Especially llvm::StringRef as it likes 
to assert when people use it incorrectly (construct one with nullptr and it 
will assert). So no llvm or clang in our public API.


Comment at: source/API/SBProcess.cpp:1433-1437
@@ +1432,7 @@
+{
+ProcessSP process_sp(GetSP());
+lldb::SBFileSpec core_file(file_name);
+lldb::SBError error;
+error.SetError(PluginManager::SaveCore(process_sp, core_file.get()));
+return error;
+}

You need to check your process_sp before using it since it comes from a 
std::weak_ptr<>. You also need to take the process run lock. You also don't 
need to create a lldb::SBFileSpec since you actually need a 
lldb_private::FileSpec. The code should be:

```
lldb::SBError
SBProcess::SaveCore(const char *file_name)
{
lldb::SBError error;
if (process_sp)
{
Mutex::Locker api_locker (process_sp->GetTarget().GetAPIMutex());
FileSpec core_file(file_name, false);
error.ref() = PluginManager::SaveCore(process_sp, core_file.get());
}
else
error.SetErrorString ("SBProcess is invalid");
return error;
}
```


Comment at: source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFFMiniDump.cpp:52
@@ +51,3 @@
+#endif
+return false;
+}

You should fill in the error and probably use a #else clause:

#else
error.SetErrorString("windows mini dumps are only supported on native 
windows machines");
return false;
#endif


http://reviews.llvm.org/D14793



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

Re: [Lldb-commits] [PATCH] D14793: Enable saving of mini dumps with lldb process save-core.

[Greg Clayton via lldb-commits]

clayborg added a comment.

Code correction and added that we should make sure the process is alive and 
stopped.



Comment at: source/API/SBProcess.cpp:1433-1437
@@ +1432,7 @@
+{
+ProcessSP process_sp(GetSP());
+lldb::SBFileSpec core_file(file_name);
+lldb::SBError error;
+error.SetError(PluginManager::SaveCore(process_sp, core_file.get()));
+return error;
+}

clayborg wrote:
> You need to check your process_sp before using it since it comes from a 
> std::weak_ptr<>. You also need to take the process run lock. You also don't 
> need to create a lldb::SBFileSpec since you actually need a 
> lldb_private::FileSpec. The code should be:
> 
> ```
> lldb::SBError
> SBProcess::SaveCore(const char *file_name)
> {
> lldb::SBError error;
> if (process_sp)
> {
> Mutex::Locker api_locker (process_sp->GetTarget().GetAPIMutex());
> FileSpec core_file(file_name, false);
> error.ref() = PluginManager::SaveCore(process_sp, core_file.get());
> }
> else
> error.SetErrorString ("SBProcess is invalid");
> return error;
> }
> ```
Code correction:
```
lldb::SBError
SBProcess::SaveCore(const char *file_name)
{
lldb::SBError error;
if (process_sp)
{
Mutex::Locker api_locker (process_sp->GetTarget().GetAPIMutex());
FileSpec core_file(file_name, false);
error.ref() = PluginManager::SaveCore(process_sp, core_file);
}
else
error.SetErrorString ("SBProcess is invalid");
return error;
}
```

We might also want to check to make sure the process is alive (the "save-core" 
command makes sure the process has been launched) and we should also make sure 
it does the right thing if the process is running (stop the process, make a 
core file, then resume if the process was running, or just fail if the process 
is running).


http://reviews.llvm.org/D14793



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

[Lldb-commits] [lldb] r253531 - Allow the language plugins a say in how the function name is rendered as part of frame formatting

[Enrico Granata via lldb-commits]

Author: enrico
Date: Wed Nov 18 19:11:53 2015
New Revision: 253531

URL: http://llvm.org/viewvc/llvm-project?rev=253531&view=rev
Log:
Allow the language plugins a say in how the function name is rendered as part 
of frame formatting

Modified:
lldb/trunk/include/lldb/Target/Language.h
lldb/trunk/source/Core/FormatEntity.cpp
lldb/trunk/source/Target/Language.cpp

Modified: lldb/trunk/include/lldb/Target/Language.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Target/Language.h?rev=253531&r1=253530&r2=253531&view=diff
==
--- lldb/trunk/include/lldb/Target/Language.h (original)
+++ lldb/trunk/include/lldb/Target/Language.h Wed Nov 18 19:11:53 2015
@@ -32,7 +32,6 @@ class Language :
 public PluginInterface
 {
 public:
-
 class TypeScavenger
 {
 public:
@@ -67,6 +66,13 @@ public:
const char *key,
ResultSet &results) = 0;
 };
+
+enum class FunctionNameRepresentation
+{
+eName,
+eNameWithArgs,
+eNameWithNoArgs
+};
 
 ~Language() override;
 
@@ -134,6 +140,11 @@ public:
 virtual bool
 IsUninitializedReference (ValueObject& valobj);
 
+virtual bool
+GetFunctionDisplayName (const SymbolContext *sc,
+FunctionNameRepresentation representation,
+Stream& s);
+
 // These are accessors for general information about the Languages lldb 
knows about:
 
 static lldb::LanguageType

Modified: lldb/trunk/source/Core/FormatEntity.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Core/FormatEntity.cpp?rev=253531&r1=253530&r2=253531&view=diff
==
--- lldb/trunk/source/Core/FormatEntity.cpp (original)
+++ lldb/trunk/source/Core/FormatEntity.cpp Wed Nov 18 19:11:53 2015
@@ -1653,201 +1653,264 @@ FormatEntity::Format (const Entry &entry
 
 case Entry::Type::FunctionName:
 {
-const char *name = NULL;
+Language *language_plugin = nullptr;
+bool language_plugin_handled = false;
+StreamString ss;
 if (sc->function)
-name = sc->function->GetName().AsCString (NULL);
+language_plugin = 
Language::FindPlugin(sc->function->GetLanguage());
 else if (sc->symbol)
-name = sc->symbol->GetName().AsCString (NULL);
-if (name)
+language_plugin = 
Language::FindPlugin(sc->symbol->GetLanguage());
+if (language_plugin)
 {
-s.PutCString(name);
-
-if (sc->block)
+language_plugin_handled = 
language_plugin->GetFunctionDisplayName(sc,
+   
   Language::FunctionNameRepresentation::eName,
+   
   ss);
+}
+if (language_plugin_handled)
+{
+s.PutCString(ss.GetData());
+return true;
+}
+else
+{
+const char *name = NULL;
+if (sc->function)
+name = sc->function->GetName().AsCString (NULL);
+else if (sc->symbol)
+name = sc->symbol->GetName().AsCString (NULL);
+if (name)
 {
-Block *inline_block = 
sc->block->GetContainingInlinedBlock ();
-if (inline_block)
+s.PutCString(name);
+
+if (sc->block)
 {
-const InlineFunctionInfo *inline_info = 
sc->block->GetInlinedFunctionInfo();
-if (inline_info)
+Block *inline_block = 
sc->block->GetContainingInlinedBlock ();
+if (inline_block)
 {
-s.PutCString(" [inlined] ");
-
inline_info->GetName(sc->function->GetLanguage()).Dump(&s);
+const InlineFunctionInfo *inline_info = 
sc->block->GetInlinedFunctionInfo();
+if (inline_info)
+{
+s.PutCString(" [inlined] ");
+
inline_info->GetName(sc->function->GetLanguage()).Dump(&s);
+}
 }
 }
+return true;
 }
-return true;
 }

Re: [Lldb-commits] [PATCH] D14793: Enable saving of mini dumps with lldb process save-core.

[Jim Ingham via lldb-commits]

> On Nov 18, 2015, at 4:31 PM, Zachary Turner via lldb-commits 
>  wrote:
> 
> zturner added a reviewer: clayborg.
> zturner added a comment.
> 
> +greg since this touches some SB stuff and the ObjectFile plugins.
> 
> 
> 
> Comment at: include/lldb/API/SBProcess.h:345-346
> @@ +344,4 @@
> +// Save the state of the process in a core file (or mini dump on 
> Windows).
> +lldb::SBError
> +SaveCore(const char *file_name);
> +
> 
> Greg, is there any reason why this couldn't be an `llvm::StringRef`?  I know 
> historically we have used this char* mechanism, but it seems like `StringRef` 
> could be a better, safer alternative than passing raw strings through the SB 
> API.  As long as you provide an appropriate typemap, everything should work 
> out.

Once we pass an llvm::StringRef to an SB API it becomes part of the API, and 
changes to llvm::StringRef make us binary incompatible.  Maybe llvm::StringRef 
won't ever change, but there's no guarantee about that, so unless we get some 
very persuasive benefit from this, I'd strongly prefer to use more vanilla data 
types.

Also, I would like to keep the process of compiling against the SB API's as 
simple as possible.  Right now you don't need the llvm headers to build an app 
that just uses the SB API's.  Again, the benefit would have to be fairly great 
before I'd want to add this requirement.  

If you want to be more formal about this, then have the API take an SBFileSpec.

Jim

> 
> 
> 
> 
> Comment at: 
> packages/Python/lldbsuite/test/functionalities/process_save_core/TestProcessSaveCore.py:20
> @@ +19,3 @@
> +@not_remote_testsuite_ready
> +@skipUnlessWindows
> +def test_windows_mini_dump (self):
> 
> How do you feel about `@skipIf(oslist=not_in(['windows']))`?
> 
> The generic skipIf and expectedFailure decorators were extended recently and 
> are now flexible enough to handle unless cases, so I'm partial to the idea of 
> eventually killing off the rest of the decorators, and just having a single 
> one that handles everything.  But I want to dogfood the idea first and see 
> what people think about it :)
> 
> 
> Comment at: 
> packages/Python/lldbsuite/test/functionalities/process_save_core/TestProcessSaveCore.py:32
> @@ +31,3 @@
> +self.assertTrue(process.Kill().Success())
> +# Clean up the mini dump file.
> +os.unlink(core)
> 
> Can you assert true that the file exists?  Is there some thing additional 
> that we can add where you then load the core and try to read something out 
> (say the executable name), and assert that it's equal to `a.out`?
> 
> Right now all we know is that there's a file.
> 
> 
> Comment at: 
> packages/Python/lldbsuite/test/functionalities/process_save_core/TestProcessSaveCore.py:33
> @@ +32,3 @@
> +# Clean up the mini dump file.
> +os.unlink(core)
> +
> 
> This isn't exception safe right now.  For example, it won't unlink the file 
> if one the asserts fails.
> 
> 
> Comment at: source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFFMiniDump.cpp:17
> @@ +16,3 @@
> +
> +#ifdef _WIN32
> +#include "lldb/Host/windows/windows.h"
> 
> I think it would be better to just not even compile this file on non-Windows. 
>  Exclude it at the CMake level, and have `SaveCore()` return false directly.  
> In the future we may add a way to deal with mini dumps outside of the Windows 
> API, and then we can add that as a separate file like 
> `ObjectFilePECOFFMiniDumpRaw.cpp` which can be used always, and then delete 
> this one.
> 
> 
> http://reviews.llvm.org/D14793
> 
> 
> 
> ___
> lldb-commits mailing list
> lldb-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

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

Re: [Lldb-commits] [PATCH] D14790: cmake: add -DLLDB_ALLOW_STATIC_BINDINGS=1, defaults off

[Todd Fiala via lldb-commits]

tfiala added a comment.

In http://reviews.llvm.org/D14790#292255, @zturner wrote:

>




> What is worth arguing about, however, is that changes need to have some kind 
> of reasonable justification.


I strongly disagree with this statement from a procedural point of view.  It is 
just an invalid expectation.  We are a bunch of commercial companies that work 
in a competitive environment.  This goes for Google, Apple, Qualcomm, Sony, 
etc.  I do not need a justification from each of these companies that explains 
items happening behind closed doors that motivate the desire for functionality 
in LLVM, clang, LLDB or any other open source project.

For example, Microsoft has an excellent debugger.  Truly.  World class.  Google 
is implementing a debugger to work on the Microsoft platform.  I don't need to 
know why that is the case.  It's totally fine that I don't know why.  It is not 
a requirement for me to know why.  Even if this requires changing support to 
add Python 3.5 (that doesn't break others), even if our directory structure 
gets 30 - 50+ characters deeper than it was before, whatever.  This is all okay 
procedurally speaking.  I don't have the prerogative to require knowing all 
those details.

I made it clear here what goal I (and by I, we're talking Apple now) am trying 
to achieve:
http://lists.llvm.org/pipermail/lldb-dev/2015-November/008802.html

In particular:
"The primary goal here is to remove the requirement of having swig on the
system (e.g. for builders and most developers)"

You keep asking the question and not liking the answer, but the goal is to "not 
require swig."  The approach has been watered down so that this only happens 
when opted in, but that is the goal.  And this is Apple's goal.  You may not 
like the goal, and I am not going to try to persuade you to like it.  But that 
is the goal.

At this point, it is entirely opt-in, and off by default.  Nobody other than 
Apple has to maintain the static bindings.  So it is our goal, we implemented a 
way to do it, and we are responsible for maintaining it.  If a by-product of 
this breaks somebody who didn't opt into this, then I think that is something 
I'd need to look at us addressing.

But no, asking for repeated justification for *why* that is Apple's goal beyond 
what I've already said (i.e. making it simpler for a casual developer to get a 
machine that can build lldb) seems both an unreasonable expectation and 
completely unnecessary to discuss.  Again, I'm happy to rip out the manner in 
which we're achieving that if something considered better comes along (which 
your bindings-as-a-service idea sounds like a potentially promising avenue to 
look at).  But I don't see there being a requirement to argue a goal that 
doesn't hamper the existing developer community.


http://reviews.llvm.org/D14790



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

Re: [Lldb-commits] [lldb] r253531 - Allow the language plugins a say in how the function name is rendered as part of frame formatting

[Zachary Turner via lldb-commits]

Hi Enrico, have there been any tests exercising any of the language plugin
stuff yet?  Hard to follow every CL that goes in, so just trying to catch
up.

On Wed, Nov 18, 2015 at 5:14 PM Enrico Granata via lldb-commits <
lldb-commits@lists.llvm.org> wrote:

> Author: enrico
> Date: Wed Nov 18 19:11:53 2015
> New Revision: 253531
>
> URL: http://llvm.org/viewvc/llvm-project?rev=253531&view=rev
> Log:
> Allow the language plugins a say in how the function name is rendered as
> part of frame formatting
>
> Modified:
> lldb/trunk/include/lldb/Target/Language.h
> lldb/trunk/source/Core/FormatEntity.cpp
> lldb/trunk/source/Target/Language.cpp
>
> Modified: lldb/trunk/include/lldb/Target/Language.h
> URL:
> http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Target/Language.h?rev=253531&r1=253530&r2=253531&view=diff
>
> ==
> --- lldb/trunk/include/lldb/Target/Language.h (original)
> +++ lldb/trunk/include/lldb/Target/Language.h Wed Nov 18 19:11:53 2015
> @@ -32,7 +32,6 @@ class Language :
>  public PluginInterface
>  {
>  public:
> -
>  class TypeScavenger
>  {
>  public:
> @@ -67,6 +66,13 @@ public:
> const char *key,
> ResultSet &results) = 0;
>  };
> +
> +enum class FunctionNameRepresentation
> +{
> +eName,
> +eNameWithArgs,
> +eNameWithNoArgs
> +};
>
>  ~Language() override;
>
> @@ -134,6 +140,11 @@ public:
>  virtual bool
>  IsUninitializedReference (ValueObject& valobj);
>
> +virtual bool
> +GetFunctionDisplayName (const SymbolContext *sc,
> +FunctionNameRepresentation representation,
> +Stream& s);
> +
>  // These are accessors for general information about the Languages
> lldb knows about:
>
>  static lldb::LanguageType
>
> Modified: lldb/trunk/source/Core/FormatEntity.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Core/FormatEntity.cpp?rev=253531&r1=253530&r2=253531&view=diff
>
> ==
> --- lldb/trunk/source/Core/FormatEntity.cpp (original)
> +++ lldb/trunk/source/Core/FormatEntity.cpp Wed Nov 18 19:11:53 2015
> @@ -1653,201 +1653,264 @@ FormatEntity::Format (const Entry &entry
>
>  case Entry::Type::FunctionName:
>  {
> -const char *name = NULL;
> +Language *language_plugin = nullptr;
> +bool language_plugin_handled = false;
> +StreamString ss;
>  if (sc->function)
> -name = sc->function->GetName().AsCString (NULL);
> +language_plugin =
> Language::FindPlugin(sc->function->GetLanguage());
>  else if (sc->symbol)
> -name = sc->symbol->GetName().AsCString (NULL);
> -if (name)
> +language_plugin =
> Language::FindPlugin(sc->symbol->GetLanguage());
> +if (language_plugin)
>  {
> -s.PutCString(name);
> -
> -if (sc->block)
> +language_plugin_handled =
> language_plugin->GetFunctionDisplayName(sc,
> +
> Language::FunctionNameRepresentation::eName,
> +
> ss);
> +}
> +if (language_plugin_handled)
> +{
> +s.PutCString(ss.GetData());
> +return true;
> +}
> +else
> +{
> +const char *name = NULL;
> +if (sc->function)
> +name = sc->function->GetName().AsCString (NULL);
> +else if (sc->symbol)
> +name = sc->symbol->GetName().AsCString (NULL);
> +if (name)
>  {
> -Block *inline_block =
> sc->block->GetContainingInlinedBlock ();
> -if (inline_block)
> +s.PutCString(name);
> +
> +if (sc->block)
>  {
> -const InlineFunctionInfo *inline_info =
> sc->block->GetInlinedFunctionInfo();
> -if (inline_info)
> +Block *inline_block =
> sc->block->GetContainingInlinedBlock ();
> +if (inline_block)
>  {
> -s.PutCString(" [inlined] ");
> -
> inline_info->GetName(sc->function->GetLanguage()).Dump(&s);
> +const InlineFunctionInfo *inline_info =
> sc->block->GetInlinedFunctionInfo();
> +if (inline_info)
> +{
> +s.PutCString(" [inlined] ");
> +
> inline_info->GetN

Re: [Lldb-commits] [PATCH] D14793: Enable saving of mini dumps with lldb process save-core.

[Zachary Turner via lldb-commits]

Fair enough.  I figured it was worth asking about, but the rationale makes
sense.

On Wed, Nov 18, 2015 at 5:18 PM Jim Ingham  wrote:

>
> > On Nov 18, 2015, at 4:31 PM, Zachary Turner via lldb-commits <
> lldb-commits@lists.llvm.org> wrote:
> >
> > zturner added a reviewer: clayborg.
> > zturner added a comment.
> >
> > +greg since this touches some SB stuff and the ObjectFile plugins.
> >
> >
> > 
> > Comment at: include/lldb/API/SBProcess.h:345-346
> > @@ +344,4 @@
> > +// Save the state of the process in a core file (or mini dump on
> Windows).
> > +lldb::SBError
> > +SaveCore(const char *file_name);
> > +
> > 
> > Greg, is there any reason why this couldn't be an `llvm::StringRef`?  I
> know historically we have used this char* mechanism, but it seems like
> `StringRef` could be a better, safer alternative than passing raw strings
> through the SB API.  As long as you provide an appropriate typemap,
> everything should work out.
>
> Once we pass an llvm::StringRef to an SB API it becomes part of the API,
> and changes to llvm::StringRef make us binary incompatible.  Maybe
> llvm::StringRef won't ever change, but there's no guarantee about that, so
> unless we get some very persuasive benefit from this, I'd strongly prefer
> to use more vanilla data types.
>
> Also, I would like to keep the process of compiling against the SB API's
> as simple as possible.  Right now you don't need the llvm headers to build
> an app that just uses the SB API's.  Again, the benefit would have to be
> fairly great before I'd want to add this requirement.
>
> If you want to be more formal about this, then have the API take an
> SBFileSpec.
>
> Jim
>
> >
> >
> >
> > 
> > Comment at:
> packages/Python/lldbsuite/test/functionalities/process_save_core/TestProcessSaveCore.py:20
> > @@ +19,3 @@
> > +@not_remote_testsuite_ready
> > +@skipUnlessWindows
> > +def test_windows_mini_dump (self):
> > 
> > How do you feel about `@skipIf(oslist=not_in(['windows']))`?
> >
> > The generic skipIf and expectedFailure decorators were extended recently
> and are now flexible enough to handle unless cases, so I'm partial to the
> idea of eventually killing off the rest of the decorators, and just having
> a single one that handles everything.  But I want to dogfood the idea first
> and see what people think about it :)
> >
> > 
> > Comment at:
> packages/Python/lldbsuite/test/functionalities/process_save_core/TestProcessSaveCore.py:32
> > @@ +31,3 @@
> > +self.assertTrue(process.Kill().Success())
> > +# Clean up the mini dump file.
> > +os.unlink(core)
> > 
> > Can you assert true that the file exists?  Is there some thing
> additional that we can add where you then load the core and try to read
> something out (say the executable name), and assert that it's equal to
> `a.out`?
> >
> > Right now all we know is that there's a file.
> >
> > 
> > Comment at:
> packages/Python/lldbsuite/test/functionalities/process_save_core/TestProcessSaveCore.py:33
> > @@ +32,3 @@
> > +# Clean up the mini dump file.
> > +os.unlink(core)
> > +
> > 
> > This isn't exception safe right now.  For example, it won't unlink the
> file if one the asserts fails.
> >
> > 
> > Comment at:
> source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFFMiniDump.cpp:17
> > @@ +16,3 @@
> > +
> > +#ifdef _WIN32
> > +#include "lldb/Host/windows/windows.h"
> > 
> > I think it would be better to just not even compile this file on
> non-Windows.  Exclude it at the CMake level, and have `SaveCore()` return
> false directly.  In the future we may add a way to deal with mini dumps
> outside of the Windows API, and then we can add that as a separate file
> like `ObjectFilePECOFFMiniDumpRaw.cpp` which can be used always, and then
> delete this one.
> >
> >
> > http://reviews.llvm.org/D14793
> >
> >
> >
> > ___
> > lldb-commits mailing list
> > lldb-commits@lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
>
>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [PATCH] D14793: Enable saving of mini dumps with lldb process save-core.

[Zachary Turner via lldb-commits]

zturner added a subscriber: zturner.
zturner added a comment.

Fair enough.  I figured it was worth asking about, but the rationale makes
sense.


http://reviews.llvm.org/D14793



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

Re: [Lldb-commits] [lldb] r253531 - Allow the language plugins a say in how the function name is rendered as part of frame formatting

[Enrico Granata via lldb-commits]

That depends - some of the language plugin stuff is being used in C/C++/ObjC, 
and then there either are new test cases, or existing test cases cover the fact 
that refactoring has not broken functionality

Some of the new functionality is not (yet) used, and is just infrastructural 
plumbing - in those cases, the best we can do to test is using existing test 
coverage to ensure our plumbing through does not break existing behavior
This change falls in this latter category - i.e. since it is just 
infrastructure work, there is no change in functionality, and the lack of 
regressions is the best testing coverage we can get in the current world
When I start using this, I will add tests (or rework existing tests) as needed

> On Nov 18, 2015, at 5:19 PM, Zachary Turner  wrote:
> 
> Hi Enrico, have there been any tests exercising any of the language plugin 
> stuff yet?  Hard to follow every CL that goes in, so just trying to catch up.
> 
> On Wed, Nov 18, 2015 at 5:14 PM Enrico Granata via lldb-commits 
> mailto:lldb-commits@lists.llvm.org>> wrote:
> Author: enrico
> Date: Wed Nov 18 19:11:53 2015
> New Revision: 253531
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=253531&view=rev 
> 
> Log:
> Allow the language plugins a say in how the function name is rendered as part 
> of frame formatting
> 
> Modified:
> lldb/trunk/include/lldb/Target/Language.h
> lldb/trunk/source/Core/FormatEntity.cpp
> lldb/trunk/source/Target/Language.cpp
> 
> Modified: lldb/trunk/include/lldb/Target/Language.h
> URL: 
> http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Target/Language.h?rev=253531&r1=253530&r2=253531&view=diff
>  
> 
> ==
> --- lldb/trunk/include/lldb/Target/Language.h (original)
> +++ lldb/trunk/include/lldb/Target/Language.h Wed Nov 18 19:11:53 2015
> @@ -32,7 +32,6 @@ class Language :
>  public PluginInterface
>  {
>  public:
> -
>  class TypeScavenger
>  {
>  public:
> @@ -67,6 +66,13 @@ public:
> const char *key,
> ResultSet &results) = 0;
>  };
> +
> +enum class FunctionNameRepresentation
> +{
> +eName,
> +eNameWithArgs,
> +eNameWithNoArgs
> +};
> 
>  ~Language() override;
> 
> @@ -134,6 +140,11 @@ public:
>  virtual bool
>  IsUninitializedReference (ValueObject& valobj);
> 
> +virtual bool
> +GetFunctionDisplayName (const SymbolContext *sc,
> +FunctionNameRepresentation representation,
> +Stream& s);
> +
>  // These are accessors for general information about the Languages lldb 
> knows about:
> 
>  static lldb::LanguageType
> 
> Modified: lldb/trunk/source/Core/FormatEntity.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Core/FormatEntity.cpp?rev=253531&r1=253530&r2=253531&view=diff
>  
> 
> ==
> --- lldb/trunk/source/Core/FormatEntity.cpp (original)
> +++ lldb/trunk/source/Core/FormatEntity.cpp Wed Nov 18 19:11:53 2015
> @@ -1653,201 +1653,264 @@ FormatEntity::Format (const Entry &entry
> 
>  case Entry::Type::FunctionName:
>  {
> -const char *name = NULL;
> +Language *language_plugin = nullptr;
> +bool language_plugin_handled = false;
> +StreamString ss;
>  if (sc->function)
> -name = sc->function->GetName().AsCString (NULL);
> +language_plugin = 
> Language::FindPlugin(sc->function->GetLanguage());
>  else if (sc->symbol)
> -name = sc->symbol->GetName().AsCString (NULL);
> -if (name)
> +language_plugin = 
> Language::FindPlugin(sc->symbol->GetLanguage());
> +if (language_plugin)
>  {
> -s.PutCString(name);
> -
> -if (sc->block)
> +language_plugin_handled = 
> language_plugin->GetFunctionDisplayName(sc,
> + 
>  Language::FunctionNameRepresentation::eName,
> + 
>  ss);
> +}
> +if (language_plugin_handled)
> +{
> +s.PutCString(ss.GetData());
> +return true;
> +}
> +else
> +{
> +const char *name = NULL;
> +if (sc->fun

Re: [Lldb-commits] [PATCH] D14530: Plug-in PlatformNetBSD initializer and terminator

[Kamil Rytarowski via lldb-commits]

krytarowski added a comment.

Are we ready to land it? Without this patch I cannot launch lldb.


Repository:
  rL LLVM

http://reviews.llvm.org/D14530



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

[Lldb-commits] [lldb] r253537 - Pass the ExecutionContext as well, since it is actually useful

[Enrico Granata via lldb-commits]

Author: enrico
Date: Wed Nov 18 20:50:27 2015
New Revision: 253537

URL: http://llvm.org/viewvc/llvm-project?rev=253537&view=rev
Log:
Pass the ExecutionContext as well, since it is actually useful

Modified:
lldb/trunk/include/lldb/Target/Language.h
lldb/trunk/source/Core/FormatEntity.cpp
lldb/trunk/source/Target/Language.cpp

Modified: lldb/trunk/include/lldb/Target/Language.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Target/Language.h?rev=253537&r1=253536&r2=253537&view=diff
==
--- lldb/trunk/include/lldb/Target/Language.h (original)
+++ lldb/trunk/include/lldb/Target/Language.h Wed Nov 18 20:50:27 2015
@@ -142,6 +142,7 @@ public:
 
 virtual bool
 GetFunctionDisplayName (const SymbolContext *sc,
+const ExecutionContext *exe_ctx,
 FunctionNameRepresentation representation,
 Stream& s);
 

Modified: lldb/trunk/source/Core/FormatEntity.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Core/FormatEntity.cpp?rev=253537&r1=253536&r2=253537&view=diff
==
--- lldb/trunk/source/Core/FormatEntity.cpp (original)
+++ lldb/trunk/source/Core/FormatEntity.cpp Wed Nov 18 20:50:27 2015
@@ -1663,6 +1663,7 @@ FormatEntity::Format (const Entry &entry
 if (language_plugin)
 {
 language_plugin_handled = 
language_plugin->GetFunctionDisplayName(sc,
+   
   exe_ctx,

   Language::FunctionNameRepresentation::eName,

   ss);
 }
@@ -1713,6 +1714,7 @@ FormatEntity::Format (const Entry &entry
 if (language_plugin)
 {
 language_plugin_handled = 
language_plugin->GetFunctionDisplayName(sc,
+   
   exe_ctx,

   Language::FunctionNameRepresentation::eNameWithNoArgs,

   ss);
 }
@@ -1749,6 +1751,7 @@ FormatEntity::Format (const Entry &entry
 if (language_plugin)
 {
 language_plugin_handled = 
language_plugin->GetFunctionDisplayName(sc,
+   
   exe_ctx,

   Language::FunctionNameRepresentation::eNameWithArgs,

   ss);
 }

Modified: lldb/trunk/source/Target/Language.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Target/Language.cpp?rev=253537&r1=253536&r2=253537&view=diff
==
--- lldb/trunk/source/Target/Language.cpp (original)
+++ lldb/trunk/source/Target/Language.cpp Wed Nov 18 20:50:27 2015
@@ -372,6 +372,7 @@ Language::IsUninitializedReference (Valu
 
 bool
 Language::GetFunctionDisplayName (const SymbolContext *sc,
+  const ExecutionContext *exe_ctx,
   FunctionNameRepresentation representation,
   Stream& s)
 {


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

Re: [Lldb-commits] [PATCH] D14793: Enable saving of mini dumps with lldb process save-core.

[Zachary Turner via lldb-commits]

zturner added inline comments.


Comment at: source/API/SBProcess.cpp:1433-1437
@@ +1432,7 @@
+{
+ProcessSP process_sp(GetSP());
+lldb::SBFileSpec core_file(file_name);
+lldb::SBError error;
+error.SetError(PluginManager::SaveCore(process_sp, core_file.get()));
+return error;
+}

clayborg wrote:
> clayborg wrote:
> > You need to check your process_sp before using it since it comes from a 
> > std::weak_ptr<>. You also need to take the process run lock. You also don't 
> > need to create a lldb::SBFileSpec since you actually need a 
> > lldb_private::FileSpec. The code should be:
> > 
> > ```
> > lldb::SBError
> > SBProcess::SaveCore(const char *file_name)
> > {
> > lldb::SBError error;
> > if (process_sp)
> > {
> > Mutex::Locker api_locker (process_sp->GetTarget().GetAPIMutex());
> > FileSpec core_file(file_name, false);
> > error.ref() = PluginManager::SaveCore(process_sp, core_file.get());
> > }
> > else
> > error.SetErrorString ("SBProcess is invalid");
> > return error;
> > }
> > ```
> Code correction:
> ```
> lldb::SBError
> SBProcess::SaveCore(const char *file_name)
> {
> lldb::SBError error;
> if (process_sp)
> {
> Mutex::Locker api_locker (process_sp->GetTarget().GetAPIMutex());
> FileSpec core_file(file_name, false);
> error.ref() = PluginManager::SaveCore(process_sp, core_file);
> }
> else
> error.SetErrorString ("SBProcess is invalid");
> return error;
> }
> ```
> 
> We might also want to check to make sure the process is alive (the 
> "save-core" command makes sure the process has been launched) and we should 
> also make sure it does the right thing if the process is running (stop the 
> process, make a core file, then resume if the process was running, or just 
> fail if the process is running).
I actually wonder if it should just generate an error if the process is not 
stopped.  Putting a bunch of extra logic in the implementation of `SaveCore()` 
seems counter to the "thin" nature of the wrapping.  Seems to me like the 
person using the SB API should stop it themselves before calling `SaveCore`.  

What do you think?


http://reviews.llvm.org/D14793



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

[Lldb-commits] [lldb] r253538 - I like how PlatformAndroid/PlatformLinux log when their platforms

[Jason Molenda via lldb-commits]

Author: jmolenda
Date: Wed Nov 18 21:15:37 2015
New Revision: 253538

URL: http://llvm.org/viewvc/llvm-project?rev=253538&view=rev
Log:
I like how PlatformAndroid/PlatformLinux log when their platforms
try to CreateInstance, and log the results.  I copied that for the
Mac platforms.


Modified:
lldb/trunk/source/Plugins/Platform/MacOSX/PlatformAppleTVSimulator.cpp
lldb/trunk/source/Plugins/Platform/MacOSX/PlatformAppleWatchSimulator.cpp
lldb/trunk/source/Plugins/Platform/MacOSX/PlatformDarwinKernel.cpp
lldb/trunk/source/Plugins/Platform/MacOSX/PlatformMacOSX.cpp
lldb/trunk/source/Plugins/Platform/MacOSX/PlatformRemoteAppleTV.cpp
lldb/trunk/source/Plugins/Platform/MacOSX/PlatformRemoteAppleWatch.cpp
lldb/trunk/source/Plugins/Platform/MacOSX/PlatformRemoteiOS.cpp
lldb/trunk/source/Plugins/Platform/MacOSX/PlatformiOSSimulator.cpp

Modified: lldb/trunk/source/Plugins/Platform/MacOSX/PlatformAppleTVSimulator.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/Platform/MacOSX/PlatformAppleTVSimulator.cpp?rev=253538&r1=253537&r2=253538&view=diff
==
--- lldb/trunk/source/Plugins/Platform/MacOSX/PlatformAppleTVSimulator.cpp 
(original)
+++ lldb/trunk/source/Plugins/Platform/MacOSX/PlatformAppleTVSimulator.cpp Wed 
Nov 18 21:15:37 2015
@@ -16,6 +16,7 @@
 #include "lldb/Breakpoint/BreakpointLocation.h"
 #include "lldb/Core/ArchSpec.h"
 #include "lldb/Core/Error.h"
+#include "lldb/Core/Log.h"
 #include "lldb/Core/Module.h"
 #include "lldb/Core/ModuleList.h"
 #include "lldb/Core/ModuleSpec.h"
@@ -68,6 +69,20 @@ PlatformAppleTVSimulator::Terminate ()
 PlatformSP
 PlatformAppleTVSimulator::CreateInstance (bool force, const ArchSpec *arch)
 {
+Log *log(GetLogIfAllCategoriesSet (LIBLLDB_LOG_PLATFORM));
+if (log)
+{
+const char *arch_name;
+if (arch && arch->GetArchitectureName ())
+arch_name = arch->GetArchitectureName ();
+else
+arch_name = "";
+
+const char *triple_cstr = arch ? arch->GetTriple ().getTriple 
().c_str() : "";
+
+log->Printf ("PlatformAppleTVSimulator::%s(force=%s, arch={%s,%s})", 
__FUNCTION__, force ? "true" : "false", arch_name, triple_cstr);
+}
+
 bool create = force;
 if (create == false && arch && arch->IsValid())
 {
@@ -121,7 +136,16 @@ PlatformAppleTVSimulator::CreateInstance
 }
 }
 if (create)
+{
+if (log)
+log->Printf ("PlatformAppleTVSimulator::%s() creating platform", 
__FUNCTION__);
+
 return PlatformSP(new PlatformAppleTVSimulator ());
+}
+
+if (log)
+log->Printf ("PlatformAppleTVSimulator::%s() aborting creation of 
platform", __FUNCTION__);
+
 return PlatformSP();
 }
 

Modified: 
lldb/trunk/source/Plugins/Platform/MacOSX/PlatformAppleWatchSimulator.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/Platform/MacOSX/PlatformAppleWatchSimulator.cpp?rev=253538&r1=253537&r2=253538&view=diff
==
--- lldb/trunk/source/Plugins/Platform/MacOSX/PlatformAppleWatchSimulator.cpp 
(original)
+++ lldb/trunk/source/Plugins/Platform/MacOSX/PlatformAppleWatchSimulator.cpp 
Wed Nov 18 21:15:37 2015
@@ -16,6 +16,7 @@
 #include "lldb/Breakpoint/BreakpointLocation.h"
 #include "lldb/Core/ArchSpec.h"
 #include "lldb/Core/Error.h"
+#include "lldb/Core/Log.h"
 #include "lldb/Core/Module.h"
 #include "lldb/Core/ModuleList.h"
 #include "lldb/Core/ModuleSpec.h"
@@ -68,6 +69,20 @@ PlatformAppleWatchSimulator::Terminate (
 PlatformSP
 PlatformAppleWatchSimulator::CreateInstance (bool force, const ArchSpec *arch)
 {
+Log *log(GetLogIfAllCategoriesSet (LIBLLDB_LOG_PLATFORM));
+if (log)
+{
+const char *arch_name;
+if (arch && arch->GetArchitectureName ())
+arch_name = arch->GetArchitectureName ();
+else
+arch_name = "";
+
+const char *triple_cstr = arch ? arch->GetTriple ().getTriple 
().c_str() : "";
+
+log->Printf ("PlatformAppleWatchSimulator::%s(force=%s, 
arch={%s,%s})", __FUNCTION__, force ? "true" : "false", arch_name, triple_cstr);
+}
+
 bool create = force;
 if (create == false && arch && arch->IsValid())
 {
@@ -121,7 +136,16 @@ PlatformAppleWatchSimulator::CreateInsta
 }
 }
 if (create)
+{
+if (log)
+log->Printf ("PlatformAppleWatchSimulator::%s() creating 
platform", __FUNCTION__);
+
 return PlatformSP(new PlatformAppleWatchSimulator ());
+}
+
+if (log)
+log->Printf ("PlatformAppleWatchSimulator::%s() aborting creation of 
platform", __FUNCTION__);
+
 return PlatformSP();
 }
 

Modified: lldb/trunk/source/Plugins/Platform/MacOSX/PlatformDarwinKernel.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/Platform/MacOSX/PlatformDarwinKernel.cpp?rev=253538&r1=253

Re: [Lldb-commits] [PATCH] D14790: cmake: add -DLLDB_ALLOW_STATIC_BINDINGS=1, defaults off

[Zachary Turner via lldb-commits]

zturner added a comment.

So, this is the last thing I'm going to say on this thread.

What I'm fighting for here is consistency.  We seem to have the same goal 
(making LLDB easier to build for the casual developer) but a different 
understanding of how to go about accomplishing this.  From your perspective, 
you want to reduce the number of dependencies required to build LLDB.  From my 
perspective, I want to reduce the number of *different* ways of accomplishing 
the exact same goal.  And reducing a dependency is not a fair trade for 
increasing the number of ways of doing the same thing.

Yes I'm drawing a line in the sand here, but it's because this has to stop.  We 
-- as a community -- have to stop adding many ways to do the exact same thing 
unless it is necessary.  I don't care if it makes things slightly more 
difficult for someone, the simplicity comes from the consistency.  You don't 
have to look hard to find examples of we do things differently on our own 
whims, disregarding established conventions of how to do the same thing.

We have a different coding standard than the rest of LLVM.

We have a different build system than the rest of LLVM.

We have a different directory structure than the rest of LLVM.

We have a different test infrastructure than the rest of LLVM.

*These* are the things that keep casual developers away, not installing swig on 
their machine.  I know this for a fact, because every time an LLVM developer 
breaks the buildbot, they send me nasty messages on LLVM's IRC about why it's 
so hard to run the test suite, how to interpreter the results, why doesn't it 
just use lit, why are my tab settings all messed up when I open the file in an 
editor, what is this weird directory structure, I can't even build!

Your goal is to remove the swig dependency, but my goal is to converge on a set 
of practices and conventions that are the same across all platforms.  That's 
the ease that I'm looking for.  Maybe this will be possible once the swig 
service is up and running and everyone can use the latest version of swig.  
From my perspective, it's possible right now if we use on-the-fly bindings.  
That's why I'm arguing this.  We, as a community, have to share each others' 
pain in order to reap each others' benefits.  That's how this whole process 
works.

In any case, lgtm.  Check in this change.  But please consider this in the 
future.  One way, unless there's no other way.


http://reviews.llvm.org/D14790



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

Re: [Lldb-commits] [PATCH] D14790: cmake: add -DLLDB_ALLOW_STATIC_BINDINGS=1, defaults off

[Kamil Rytarowski via lldb-commits]

krytarowski added a subscriber: krytarowski.
krytarowski added a comment.

Not long ago we rejected dynamic dependency on `curses`(3), as a fall-back for 
NetBSD (without `libpanel`(3) in the 7.0 release). Why doing the similar thing 
with swig is fine?

Why are we abstracting swig when there is no other option viable?

Is possible to improve this approach of finding swig? We are looking for it in 
CMake and later in Python?
`find_package(SWIG)`, `--find-swig`.

Maybe just add a single switch in CMake to enable or disable it without options.

Please explain what does static bindings mean here.


http://reviews.llvm.org/D14790



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

Re: [Lldb-commits] [PATCH] D14790: cmake: add -DLLDB_ALLOW_STATIC_BINDINGS=1, defaults off

[Zachary Turner via lldb-commits]

zturner added a comment.

In http://reviews.llvm.org/D14790#292493, @krytarowski wrote:

> Not long ago we rejected dynamic dependency on `curses`(3), as a fall-back 
> for NetBSD (without `libpanel`(3) in the 7.0 release). Why doing the similar 
> thing with swig is fine?
>
> Why are we abstracting swig when there is no other option viable?
>
> Is possible to improve this approach of finding swig? We are looking for it 
> in CMake and later in Python?
>  `find_package(SWIG)`, `--find-swig`.
>
> Maybe just add a single switch in CMake to enable or disable it without 
> options.
>
> Please explain what does static bindings mean here.


static binding = one person runs swig to generate `LLDBWrapPython.cpp` and 
`lldb.py`, then they check these files into the upstream.  Nobody else has to 
run swig.

Dynamic binding aka on-the-fly-binding = only the swig interface file is 
checked in.  There is a build step that automatically runs swig locally on 
every developer's machine when the interface file changes and automatically 
generates `LLDBWrapPython.cpp` and `lldb.py` at build time.


http://reviews.llvm.org/D14790



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

Re: [Lldb-commits] [PATCH] D14790: cmake: add -DLLDB_ALLOW_STATIC_BINDINGS=1, defaults off

[Kamil Rytarowski via lldb-commits]

krytarowski added a comment.

I dislike delegating jobs (or hiding problems) of CMake (assuming that 
autoconf/gmake is already dead) to external scripts like Python ones.

In the goal, I plan to add LLDB in the NetBSD base (next to LLVM and Clang) 
where there is no Python at all. In FreeBSD there is no Python in base as well. 
To state it stronger, there might never be Python in the base.

I would expect to just have a single switch like `-DLLDB_ENABLE_PYTHON`, while 
I don't understand `-DLLDB_ALLOW_STATIC_BINDINGS`.

When I will catch up with platform support I'm considering to prepare bindings 
in Lua, as this is the standard scripting language in NetBSD (we script with it 
kernel, packet filter, userland etc). Lua offers native C/C++ bindings (as 
there is no need for intermediate tool) by design and is a dynamic language 
close to Python. But this isn't plan for this year.

For now please leave an option that end user to disable Python. Otherwise 
erasing it will be done downstream without benefit for the project.


http://reviews.llvm.org/D14790



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

Re: [Lldb-commits] [PATCH] D14790: cmake: add -DLLDB_ALLOW_STATIC_BINDINGS=1, defaults off

[Todd Fiala via lldb-commits]

tfiala added a comment.

> For now please leave an option that end user to disable Python. Otherwise 
> erasing it will be done downstream without benefit for the project.


Nobody is talking about removing the option to disable python.

The static binding binding option is ignored (i.e. irrelevant) if python is 
disabled.


http://reviews.llvm.org/D14790



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

Re: [Lldb-commits] [PATCH] D14790: cmake: add -DLLDB_ALLOW_STATIC_BINDINGS=1, defaults off

[Kamil Rytarowski via lldb-commits]

krytarowski added a comment.

Sure, I'm just giving general feedback.

From a user perspective I want to get yes/no information whether I need swig or 
not, if so what version. If we allow Python, I don't see any reason to not 
allowing swig. if some version gives you problems (license, bad code 
generator), please enforce a certain one.


http://reviews.llvm.org/D14790



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