date:20151102

Re: [Lldb-commits] [PATCH] D14197: Handle the options and parameters separator in every MI command

2015-11-02 Thread Hafiz Abid Qadeer via lldb-commits

abidh updated this revision to Diff 38879.
abidh added a comment.

Handled review comment.

Added a test for -data-disassemble without "--" separator.


http://reviews.llvm.org/D14197

Files:
  packages/Python/lldbsuite/test/tools/lldb-mi/data/TestMiData.py
  tools/lldb-mi/MICmdBase.cpp
  tools/lldb-mi/MICmdBase.h
  tools/lldb-mi/MICmdCmdData.cpp
  tools/lldb-mi/MICmdCmdData.h

Index: tools/lldb-mi/MICmdCmdData.h
===
--- tools/lldb-mi/MICmdCmdData.h
+++ tools/lldb-mi/MICmdCmdData.h
@@ -106,7 +106,6 @@
   private:
 const CMIUtilString m_constStrArgAddrStart; // MI spec non mandatory, 
*this command mandatory
 const CMIUtilString m_constStrArgAddrEnd;   // MI spec non mandatory, 
*this command mandatory
-const CMIUtilString m_constStrArgConsume;
 const CMIUtilString m_constStrArgMode;
 CMICmnMIValueList m_miValueList;
 };
Index: tools/lldb-mi/MICmdCmdData.cpp
===
--- tools/lldb-mi/MICmdCmdData.cpp
+++ tools/lldb-mi/MICmdCmdData.cpp
@@ -239,7 +239,6 @@
 CMICmdCmdDataDisassemble::CMICmdCmdDataDisassemble()
 : m_constStrArgAddrStart("s")
 , m_constStrArgAddrEnd("e")
-, m_constStrArgConsume("--")
 , m_constStrArgMode("mode")
 , m_miValueList(true)
 {
@@ -277,7 +276,6 @@
 new CMICmdArgValOptionShort(m_constStrArgAddrStart, true, true, 
CMICmdArgValListBase::eArgValType_StringQuotedNumber, 1));
 m_setCmdArgs.Add(
 new CMICmdArgValOptionShort(m_constStrArgAddrEnd, true, true, 
CMICmdArgValListBase::eArgValType_StringQuotedNumber, 1));
-m_setCmdArgs.Add(new CMICmdArgValConsume(m_constStrArgConsume, true));
 m_setCmdArgs.Add(new CMICmdArgValNumber(m_constStrArgMode, true, true));
 return ParseValidateCmdOptions();
 }
Index: tools/lldb-mi/MICmdBase.h
===
--- tools/lldb-mi/MICmdBase.h
+++ tools/lldb-mi/MICmdBase.h
@@ -98,6 +98,7 @@
 const CMIUtilString m_constStrArgThreadGroup;
 const CMIUtilString m_constStrArgThread;
 const CMIUtilString m_constStrArgFrame;
+const CMIUtilString m_constStrArgConsume;
 
 // These 3 members can be used by the derived classes to make any of
 // "thread", "frame" or "thread-group" mandatory.
Index: tools/lldb-mi/MICmdBase.cpp
===
--- tools/lldb-mi/MICmdBase.cpp
+++ tools/lldb-mi/MICmdBase.cpp
@@ -12,6 +12,7 @@
 #include "MICmnMIValueConst.h"
 #include "MICmnLLDBDebugSessionInfo.h"
 #include "MICmdArgValOptionLong.h"
+#include "MICmdArgValConsume.h"
 
 //++ 

 // Details: CMICmdBase constructor.
@@ -27,6 +28,7 @@
 , m_constStrArgThreadGroup("thread-group")
 , m_constStrArgThread("thread")
 , m_constStrArgFrame("frame")
+, m_constStrArgConsume("--")
 , m_ThreadGrpArgMandatory(false)
 , m_ThreadArgMandatory(false)
 , m_FrameArgMandatory(false)
@@ -97,6 +99,7 @@
 m_setCmdArgs.Add(new CMICmdArgValOptionLong(m_constStrArgThreadGroup, 
m_ThreadGrpArgMandatory, true, CMICmdArgValListBase::eArgValType_ThreadGrp, 1));
 m_setCmdArgs.Add(new CMICmdArgValOptionLong(m_constStrArgThread, 
m_ThreadArgMandatory, true, CMICmdArgValListBase::eArgValType_Number, 1));
 m_setCmdArgs.Add(new CMICmdArgValOptionLong(m_constStrArgFrame, 
m_FrameArgMandatory, true, CMICmdArgValListBase::eArgValType_Number, 1));
+m_setCmdArgs.Add(new CMICmdArgValConsume(m_constStrArgConsume, false));
 }
 
 //++ 

Index: packages/Python/lldbsuite/test/tools/lldb-mi/data/TestMiData.py
===
--- packages/Python/lldbsuite/test/tools/lldb-mi/data/TestMiData.py
+++ packages/Python/lldbsuite/test/tools/lldb-mi/data/TestMiData.py
@@ -40,6 +40,10 @@
 # Test -data-disassemble: try to disassemble some address
 self.runCmd("-data-disassemble -s %#x -e %#x -- 0" % (addr, addr + 
0x10))
 
self.expect("\^done,asm_insns=\[{address=\"0x0*%x\",func-name=\"main\",offset=\"0\",size=\"[1-9]+\",inst=\".+?\"},"
 % addr)
+
+# Test -data-disassemble without "--"
+self.runCmd("-data-disassemble -s %#x -e %#x 0" % (addr, addr + 0x10))
+
self.expect("\^done,asm_insns=\[{address=\"0x0*%x\",func-name=\"main\",offset=\"0\",size=\"[1-9]+\",inst=\".+?\"},"
 % addr)
 
 # Run to hello_world
 self.runCmd("-break-insert -f hello_world")


Index: tools/lldb-mi/MICmdCmdData.h
===
--- tools/lldb-mi/MICmdCmdData.h
+++ tools/lldb-mi/MICmdCmdData.h
@@ -106,7 +106,6 @@
   private:
 const CMIUtilString m_constStrArgAddrStart; // MI spec non mandatory, *this command mandatory
 const CMIUtilString m_constStrArgAddrEnd;   //

Re: [Lldb-commits] [PATCH] D14197: Handle the options and parameters separator in every MI command

2015-11-02 Thread Hafiz Abid Qadeer via lldb-commits

abidh added inline comments.


Comment at: tools/lldb-mi/MICmdBase.cpp:102
@@ -99,2 +101,3 @@
 m_setCmdArgs.Add(new CMICmdArgValOptionLong(m_constStrArgFrame, 
m_FrameArgMandatory, true, CMICmdArgValListBase::eArgValType_Number, 1));
+m_setCmdArgs.Add(new CMICmdArgValConsume(m_constStrArgConsume, false));
 }

ki.stfu wrote:
> The -data-disassemble command has '--' mandatory argument, but now it's 
> always optional argument. Should it use m_ConsumeArgMandatory as it works for 
> --thread/--frame etc?
I changed this intentionally because "--" should not be mandatory. The MI 
specifications does not make it mandatory and in GDB, disassemble command works 
with and without it. So this change bring the same behavior in lldb-mi.


Comment at: tools/lldb-mi/MICmdCmdData.cpp:280
@@ -279,3 +278,2 @@
 new CMICmdArgValOptionShort(m_constStrArgAddrEnd, true, true, 
CMICmdArgValListBase::eArgValType_StringQuotedNumber, 1));
-m_setCmdArgs.Add(new CMICmdArgValConsume(m_constStrArgConsume, true));
 m_setCmdArgs.Add(new CMICmdArgValNumber(m_constStrArgMode, true, true));

ki.stfu wrote:
> Please expand MiDataTestCase.test_lldbmi_data_disassemble test to check that 
> it still gives an error without '--' argument.
I have added a test that check the -data-disassemble without "--" as it is not 
mandatory.


http://reviews.llvm.org/D14197



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

Re: [Lldb-commits] [PATCH] D14197: Handle the options and parameters separator in every MI command

2015-11-02 Thread Ilia K via lldb-commits

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

lgtm



Comment at: tools/lldb-mi/MICmdBase.cpp:102
@@ -99,2 +101,3 @@
 m_setCmdArgs.Add(new CMICmdArgValOptionLong(m_constStrArgFrame, 
m_FrameArgMandatory, true, CMICmdArgValListBase::eArgValType_Number, 1));
+m_setCmdArgs.Add(new CMICmdArgValConsume(m_constStrArgConsume, false));
 }

Well, I thought it's mandatory argument according to its spec: 
https://sourceware.org/gdb/onlinedocs/gdb/GDB_002fMI-Data-Manipulation.html
```
  -data-disassemble
 [ -s start-addr -e end-addr ]
   | [ -f filename -l linenum [ -n lines ] ]
   -- mode
```

But I think we can follow to the GDB syntax.


Comment at: tools/lldb-mi/MICmdCmdData.cpp:280
@@ -279,3 +278,2 @@
 new CMICmdArgValOptionShort(m_constStrArgAddrEnd, true, true, 
CMICmdArgValListBase::eArgValType_StringQuotedNumber, 1));
-m_setCmdArgs.Add(new CMICmdArgValConsume(m_constStrArgConsume, true));
 m_setCmdArgs.Add(new CMICmdArgValNumber(m_constStrArgMode, true, true));

ok, thanks.


http://reviews.llvm.org/D14197



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

Re: [Lldb-commits] [PATCH] D14197: Handle the options and parameters separator in every MI command

2015-11-02 Thread Hafiz Abid Qadeer via lldb-commits

abidh marked an inline comment as done.


Comment at: tools/lldb-mi/MICmdBase.cpp:102
@@ -99,2 +101,3 @@
 m_setCmdArgs.Add(new CMICmdArgValOptionLong(m_constStrArgFrame, 
m_FrameArgMandatory, true, CMICmdArgValListBase::eArgValType_Number, 1));
+m_setCmdArgs.Add(new CMICmdArgValConsume(m_constStrArgConsume, false));
 }

ki.stfu wrote:
> Well, I thought it's mandatory argument according to its spec: 
> https://sourceware.org/gdb/onlinedocs/gdb/GDB_002fMI-Data-Manipulation.html
> ```
>   -data-disassemble
>  [ -s start-addr -e end-addr ]
>| [ -f filename -l linenum [ -n lines ] ]
>-- mode
> ```
> 
> But I think we can follow to the GDB syntax.
If you read the following, you will see that "--" is not mandatory. It says 
"Options occur first in the parameter list and can be delimited from normal 
parameters using ‘--’ (this is useful when some parameters begin with a dash)."

https://sourceware.org/gdb/onlinedocs/gdb/GDB_002fMI-Input-Syntax.html#GDB_002fMI-Input-Syntax


http://reviews.llvm.org/D14197



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

[Lldb-commits] [lldb] r251793 - Handle the options and parameters separator in every MI command

2015-11-02 Thread Hafiz Abid Qadeer via lldb-commits

Author: abidh
Date: Mon Nov  2 05:43:40 2015
New Revision: 251793

URL: http://llvm.org/viewvc/llvm-project?rev=251793&view=rev
Log:
Handle the options and parameters separator in every MI command

Summary:
As per the following link, the "--" separator can appear between the options
and parameters of any MI command. Previously this separator was only
handled by the `-data-disassemble` MI command. I have moved the relevant
code into `CMICmdBase` so that any MI command can handle the
aforementioned separator.

https://sourceware.org/gdb/onlinedocs/gdb/GDB_002fMI-Input-Syntax.html#GDB_002fMI-Input-Syntax

Reviewers: ki.stfu

Subscribers: lldb-commits

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

Modified:
lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-mi/data/TestMiData.py
lldb/trunk/tools/lldb-mi/MICmdBase.cpp
lldb/trunk/tools/lldb-mi/MICmdBase.h
lldb/trunk/tools/lldb-mi/MICmdCmdData.cpp
lldb/trunk/tools/lldb-mi/MICmdCmdData.h

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-mi/data/TestMiData.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-mi/data/TestMiData.py?rev=251793&r1=251792&r2=251793&view=diff
==
--- lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-mi/data/TestMiData.py 
(original)
+++ lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-mi/data/TestMiData.py 
Mon Nov  2 05:43:40 2015
@@ -40,6 +40,10 @@ class MiDataTestCase(lldbmi_testcase.MiT
 # Test -data-disassemble: try to disassemble some address
 self.runCmd("-data-disassemble -s %#x -e %#x -- 0" % (addr, addr + 
0x10))
 
self.expect("\^done,asm_insns=\[{address=\"0x0*%x\",func-name=\"main\",offset=\"0\",size=\"[1-9]+\",inst=\".+?\"},"
 % addr)
+
+# Test -data-disassemble without "--"
+self.runCmd("-data-disassemble -s %#x -e %#x 0" % (addr, addr + 0x10))
+
self.expect("\^done,asm_insns=\[{address=\"0x0*%x\",func-name=\"main\",offset=\"0\",size=\"[1-9]+\",inst=\".+?\"},"
 % addr)
 
 # Run to hello_world
 self.runCmd("-break-insert -f hello_world")

Modified: lldb/trunk/tools/lldb-mi/MICmdBase.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/tools/lldb-mi/MICmdBase.cpp?rev=251793&r1=251792&r2=251793&view=diff
==
--- lldb/trunk/tools/lldb-mi/MICmdBase.cpp (original)
+++ lldb/trunk/tools/lldb-mi/MICmdBase.cpp Mon Nov  2 05:43:40 2015
@@ -12,6 +12,7 @@
 #include "MICmnMIValueConst.h"
 #include "MICmnLLDBDebugSessionInfo.h"
 #include "MICmdArgValOptionLong.h"
+#include "MICmdArgValConsume.h"
 
 //++ 

 // Details: CMICmdBase constructor.
@@ -27,6 +28,7 @@ CMICmdBase::CMICmdBase()
 , m_constStrArgThreadGroup("thread-group")
 , m_constStrArgThread("thread")
 , m_constStrArgFrame("frame")
+, m_constStrArgConsume("--")
 , m_ThreadGrpArgMandatory(false)
 , m_ThreadArgMandatory(false)
 , m_FrameArgMandatory(false)
@@ -97,6 +99,7 @@ CMICmdBase::AddCommonArgs()
 m_setCmdArgs.Add(new CMICmdArgValOptionLong(m_constStrArgThreadGroup, 
m_ThreadGrpArgMandatory, true, CMICmdArgValListBase::eArgValType_ThreadGrp, 1));
 m_setCmdArgs.Add(new CMICmdArgValOptionLong(m_constStrArgThread, 
m_ThreadArgMandatory, true, CMICmdArgValListBase::eArgValType_Number, 1));
 m_setCmdArgs.Add(new CMICmdArgValOptionLong(m_constStrArgFrame, 
m_FrameArgMandatory, true, CMICmdArgValListBase::eArgValType_Number, 1));
+m_setCmdArgs.Add(new CMICmdArgValConsume(m_constStrArgConsume, false));
 }
 
 //++ 


Modified: lldb/trunk/tools/lldb-mi/MICmdBase.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/tools/lldb-mi/MICmdBase.h?rev=251793&r1=251792&r2=251793&view=diff
==
--- lldb/trunk/tools/lldb-mi/MICmdBase.h (original)
+++ lldb/trunk/tools/lldb-mi/MICmdBase.h Mon Nov  2 05:43:40 2015
@@ -98,6 +98,7 @@ class CMICmdBase : public CMICmnBase, pu
 const CMIUtilString m_constStrArgThreadGroup;
 const CMIUtilString m_constStrArgThread;
 const CMIUtilString m_constStrArgFrame;
+const CMIUtilString m_constStrArgConsume;
 
 // These 3 members can be used by the derived classes to make any of
 // "thread", "frame" or "thread-group" mandatory.

Modified: lldb/trunk/tools/lldb-mi/MICmdCmdData.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/tools/lldb-mi/MICmdCmdData.cpp?rev=251793&r1=251792&r2=251793&view=diff
==
--- lldb/trunk/tools/lldb-mi/MICmdCmdData.cpp (original)
+++ lldb/trunk/tools/lldb-mi/MICmdCmdData.cpp Mon Nov  2 05:43:40 2015
@@ -239,7 +239,6 @@ CMICmdCmdDataEvalu

Re: [Lldb-commits] [PATCH] D14197: Handle the options and parameters separator in every MI command

2015-11-02 Thread Ilia K via lldb-commits

ki.stfu added inline comments.


Comment at: tools/lldb-mi/MICmdBase.cpp:102
@@ -99,2 +101,3 @@
 m_setCmdArgs.Add(new CMICmdArgValOptionLong(m_constStrArgFrame, 
m_FrameArgMandatory, true, CMICmdArgValListBase::eArgValType_Number, 1));
+m_setCmdArgs.Add(new CMICmdArgValConsume(m_constStrArgConsume, false));
 }

abidh wrote:
> ki.stfu wrote:
> > Well, I thought it's mandatory argument according to its spec: 
> > https://sourceware.org/gdb/onlinedocs/gdb/GDB_002fMI-Data-Manipulation.html
> > ```
> >   -data-disassemble
> >  [ -s start-addr -e end-addr ]
> >| [ -f filename -l linenum [ -n lines ] ]
> >-- mode
> > ```
> > 
> > But I think we can follow to the GDB syntax.
> If you read the following, you will see that "--" is not mandatory. It says 
> "Options occur first in the parameter list and can be delimited from normal 
> parameters using ‘--’ (this is useful when some parameters begin with a 
> dash)."
> 
> https://sourceware.org/gdb/onlinedocs/gdb/GDB_002fMI-Input-Syntax.html#GDB_002fMI-Input-Syntax
As for me, it says that dashes aren't mandatory in general cases (i.e. unless 
otherwise specified in command's spec). In case of -data-disassemble, we know 
that `mode` is either 0, 1, 2, or 3, and therefore according to your [[ 
https://sourceware.org/gdb/onlinedocs/gdb/GDB_002fMI-Input-Syntax.html#GDB_002fMI-Input-Syntax
 | link ]], the syntax would be:
```
-data-disassemble [ -s start-addr -e end-addr ] | [ -f filename -l linenum [ -n 
lines ] ] [--] mode
```
(i.e. "--" is optional)

But the [[ 
https://sourceware.org/gdb/onlinedocs/gdb/GDB_002fMI-Data-Manipulation.html | 
spec ]] says that '--' is mandatory argument and I perceive it as a special 
case of usage '--'. Therefore I supposed that it's mandatory argument.


http://reviews.llvm.org/D14197



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

Re: [Lldb-commits] [lldb] r251732 - Harden this test case to do the right thing in the face of compiler changes

2015-11-02 Thread Sean Callanan via lldb-commits

Enrico,

> +@expectedFailureDarwin

isn’t this commit supposed to fix the test?  Why are you making it xfail?

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

Re: [Lldb-commits] [PATCH] D13859: [LLDB][LLGS Test] Check length of register, only when its available

2015-11-02 Thread Greg Clayton via lldb-commits

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

Much better.


Repository:
  rL LLVM

http://reviews.llvm.org/D13859



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

Re: [Lldb-commits] [PATCH] D14226: Fix to solve Bug 23139 & Bug 23560

2015-11-02 Thread Greg Clayton via lldb-commits

clayborg resigned from this revision.
clayborg removed a reviewer: clayborg.
clayborg added a comment.

I will defer to Jason Molenda.


http://reviews.llvm.org/D14226



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

Re: [Lldb-commits] [lldb] r251678 - Some test cases that need the lldbExec path were failing because lldbExec was turning out to be None even though it was being validly set by dotest.py

2015-11-02 Thread Zachary Turner via lldb-commits

I looked into this some more, and unfortunately I can't reproduce it.  That
being said, I'm not convinced this patch fixes anything.  The reason is
that when you import something, whether it be through the `__import__`
function or the `import` statement, the module itself is cached in
`sys.modules`.  Whether the *name* for that module is introduced globally
(as is done in this patch) or locally (as is done when you use an `import`
statement) is irrelevant.  Because the next time someone else imports it,
it will still find the same instance of the module in `sys.modules` and
just create a new name.  It won't import it anew.

If this patch does actually fix something, I think it must be a
coincidence.  That said, I do have an idea as to what the problem might
be.  Or at the very least, I know of a problem that would definitely lead
to strange behavior.

`lldbsuite` is now a package, and it relies on the code in its
`__init__.py` being run.  If you run
`packages/python/lldbsuite/test/dotest.py` manually, then `__init__.py`
doesn't get run, and `lldbExec` doesn't get initialized properly.

Of course, this isn't what you're doing, but it *is* what `dosep` does
internally.  `dosep` manually constructs a path to
`packages/python/lldbsuite/test/dotest.py`
and execs it.  I have a patch that fixes this and makes `dosep` exec
`lldb/test/dotest.py` instead, which will then lead to the package being
imported, and `__init__.py` being run, and everything being initialized
properly.

I'm going to commit that patch by itself, and then I will submit a followup
patch that reverts the change from this patch (since I can't reproduce this
problem, I can't check whether or not my patch fixes it).  So if my revert
breaks you again, feel free to revert the revert.  Although if there's any
way you can investigate a bit to understand what's going on a little bit
more, but I would be very grateful.  In particular, I wonder about the
following things:

1) When lldbExec is not initialized properly, is this in the same process
instance that you ran from the command line, or is it in the
multiprocessing fork?
2) If you add code to `lldbsuite/__init__.py` to print the process id and
the value of `lldb_root`, and then add code in `dotest.py` to print the
process id and the value of lldbExec, what does the output look like?
 (Each line should be printed up to twice, due to the multiprocessing fork).

Anyway, I'll get those 2 patches submitted to fix the dosep issue and
revert this change, and see what happens.

On Fri, Oct 30, 2015 at 1:53 PM Jim Ingham  wrote:

> Note, the other important step was that you had to have an lldb installed
> in /usr/bin/lldb that FAILED this test.  If you have a more recent lldb
> there, the test will succeed, and you won't notice you aren't testing your
> newly built sources.
>
> Jim
>
> > On Oct 30, 2015, at 1:25 PM, Enrico Granata via lldb-commits <
> lldb-commits@lists.llvm.org> wrote:
> >
> > I think what I was doing is be in lldb/test and do
> >
> > $ ./dotest.py ../packages/python/lldbsuite/functionalities/completion
> >
> >> On Oct 30, 2015, at 12:22 PM, Zachary Turner 
> wrote:
> >>
> >> Can you give me a command line which will reproduce the original
> problem?  Because I ran through the entire test suite and nothing failed,
> so I want to make sure we're doing the same thing.  I'm still a little
> confused about how this happens, but I plan to look into it when I'm back
> on Monday and see if I can understand it better to identify a better fix.
> >>
> >> On Fri, Oct 30, 2015 at 11:58 AM Enrico Granata 
> wrote:
> >>> On Oct 29, 2015, at 11:31 PM, Zachary Turner 
> wrote:
> >>>
> >>> Wow.  That's a weird problem.  Thanks for finding it!
> >>>
> >>> Would it work if we move the definition of the `lldbtest_config` class
> into lldbsuite/test/__init__.py?  This way the configuration should be part
> of the global package state of the lldbsuite.test package, which all the
> tests are already members of the same package, so they wouldn't even need
> to import anything (I think).
> >>>
> >>
> >> I think the problem is exactly that we want lldbtest_config to be
> *global* state and not package local state.
> >> Honestly, I think if we are not content with the fix as it stands, the
> right way would be to change the way unittest2 imports test cases as to use
> the package-level global scope instead of the global global state as it is
> now.
> >>
> >>> On Oct 30, 2015, at 8:32 AM, Zachary Turner 
> wrote:
> >>>
> >>> I'm also still a little confused why this worked before my patch.  How
> is unittest2 importing the individual tests in a way that behaves
> differently when dotest is a package (now) versus a standalone script
> (before)?
> >>>
> >>
> >> That is a good question. One to which “because Python” is the only
> answer I can think of. I suspect scripts live at the global scope anyway,
> so we were just getting lucky with those imports making it through
> correctly.
> >>
> >>> On Thu, Oct 29, 2015 at 6:

[Lldb-commits] [lldb] r251819 - Make dosep correctly invoke the top-level script when forking out

2015-11-02 Thread Zachary Turner via lldb-commits

Author: zturner
Date: Mon Nov  2 13:19:49 2015
New Revision: 251819

URL: http://llvm.org/viewvc/llvm-project?rev=251819&view=rev
Log:
Make dosep correctly invoke the top-level script when forking out

packages/Python/lldbsuite is now a Python package, and it relies
on its __init__.py being called to do package-level initialization.
If you exec packages/Python/lldbsuite/dotest.py directly, you won't
get this package level initialization, and things will fail.  But
without this patch, this is exactly what dosep itself does.  To
launch the multi-processing fork, it was hardcoding a path to
dotest.py and exec'ing it from inside the package.

The fix here is to get the path of the top-level script, and
then exec'ing that instead.  A more robust solution would involve
refactoring the code so that dosep execs some internal script that
imports lldbsuite, but that's a bit more involved.

Differential Revision: http://reviews.llvm.org/D14157
Reviewed by: Todd Fiala

Modified:
lldb/trunk/packages/Python/lldbsuite/test/dosep.py
lldb/trunk/packages/Python/lldbsuite/test/dotest.py

Modified: lldb/trunk/packages/Python/lldbsuite/test/dosep.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/dosep.py?rev=251819&r1=251818&r2=251819&view=diff
==
--- lldb/trunk/packages/Python/lldbsuite/test/dosep.py (original)
+++ lldb/trunk/packages/Python/lldbsuite/test/dosep.py Mon Nov  2 13:19:49 2015
@@ -279,11 +279,12 @@ def call_with_timeout(command, timeout,
 return process_driver.results
 
 
-def process_dir(root, files, test_root, dotest_argv, inferior_pid_events):
+def process_dir(root, files, dotest_argv, inferior_pid_events):
 """Examine a directory for tests, and invoke any found within it."""
 results = []
 for name in files:
-script_file = os.path.join(test_root, "dotest.py")
+import __main__ as main
+script_file = main.__file__
 command = ([sys.executable, script_file] +
dotest_argv +
["--inferior", "-p", name, root])
@@ -966,7 +967,7 @@ def walk_and_invoke(test_directory, test
 test_work_items = []
 find_test_files_in_dir_tree(
 test_subdir, lambda testdir, test_files: test_work_items.append([
-test_subdir, test_files, test_directory, dotest_argv, None]))
+test_subdir, test_files, dotest_argv, None]))
 
 # Convert test work items into test results using whatever
 # was provided as the test run function.

Modified: lldb/trunk/packages/Python/lldbsuite/test/dotest.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/dotest.py?rev=251819&r1=251818&r2=251819&view=diff
==
--- lldb/trunk/packages/Python/lldbsuite/test/dotest.py (original)
+++ lldb/trunk/packages/Python/lldbsuite/test/dotest.py Mon Nov  2 13:19:49 2015
@@ -1,5 +1,3 @@
-#!/usr/bin/env python
-
 """
 A simple testing framework for lldb using python's unit testing framework.
 
@@ -2039,4 +2037,5 @@ def run_suite():
 exitTestSuite(failed)
 
 if __name__ == "__main__":
-run_suite()
\ No newline at end of file
+print(__file__ + " is for use as a module only.  It should not be run as a 
standalone script.")
+sys.exit(-1)


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

Re: [Lldb-commits] [lldb] r251678 - Some test cases that need the lldbExec path were failing because lldbExec was turning out to be None even though it was being validly set by dotest.py

2015-11-02 Thread Pavel Labath via lldb-commits

BTW, is lldb/test/dotest.py here to stay? I thought it was there just to
avoid breaking anybody who runs dotest directly (instead of ninja
check-lldb), and therefore we will remove it once everybody gets a chance
to migrate (I have already changed our buildbots to not use it).

Is that correct or I am misunderstanding something?

pl


On 2 November 2015 at 11:11, Zachary Turner via lldb-commits <
lldb-commits@lists.llvm.org> wrote:

> I looked into this some more, and unfortunately I can't reproduce it.
> That being said, I'm not convinced this patch fixes anything.  The reason
> is that when you import something, whether it be through the `__import__`
> function or the `import` statement, the module itself is cached in
> `sys.modules`.  Whether the *name* for that module is introduced globally
> (as is done in this patch) or locally (as is done when you use an `import`
> statement) is irrelevant.  Because the next time someone else imports it,
> it will still find the same instance of the module in `sys.modules` and
> just create a new name.  It won't import it anew.
>
> If this patch does actually fix something, I think it must be a
> coincidence.  That said, I do have an idea as to what the problem might
> be.  Or at the very least, I know of a problem that would definitely lead
> to strange behavior.
>
> `lldbsuite` is now a package, and it relies on the code in its
> `__init__.py` being run.  If you run
> `packages/python/lldbsuite/test/dotest.py` manually, then `__init__.py`
> doesn't get run, and `lldbExec` doesn't get initialized properly.
>
> Of course, this isn't what you're doing, but it *is* what `dosep` does
> internally.  `dosep` manually constructs a path to 
> `packages/python/lldbsuite/test/dotest.py`
> and execs it.  I have a patch that fixes this and makes `dosep` exec
> `lldb/test/dotest.py` instead, which will then lead to the package being
> imported, and `__init__.py` being run, and everything being initialized
> properly.
>
> I'm going to commit that patch by itself, and then I will submit a
> followup patch that reverts the change from this patch (since I can't
> reproduce this problem, I can't check whether or not my patch fixes it).
> So if my revert breaks you again, feel free to revert the revert.  Although
> if there's any way you can investigate a bit to understand what's going on
> a little bit more, but I would be very grateful.  In particular, I wonder
> about the following things:
>
> 1) When lldbExec is not initialized properly, is this in the same process
> instance that you ran from the command line, or is it in the
> multiprocessing fork?
> 2) If you add code to `lldbsuite/__init__.py` to print the process id and
> the value of `lldb_root`, and then add code in `dotest.py` to print the
> process id and the value of lldbExec, what does the output look like?
>  (Each line should be printed up to twice, due to the multiprocessing fork).
>
> Anyway, I'll get those 2 patches submitted to fix the dosep issue and
> revert this change, and see what happens.
>
> On Fri, Oct 30, 2015 at 1:53 PM Jim Ingham  wrote:
>
>> Note, the other important step was that you had to have an lldb installed
>> in /usr/bin/lldb that FAILED this test.  If you have a more recent lldb
>> there, the test will succeed, and you won't notice you aren't testing your
>> newly built sources.
>>
>> Jim
>>
>> > On Oct 30, 2015, at 1:25 PM, Enrico Granata via lldb-commits <
>> lldb-commits@lists.llvm.org> wrote:
>> >
>> > I think what I was doing is be in lldb/test and do
>> >
>> > $ ./dotest.py ../packages/python/lldbsuite/functionalities/completion
>> >
>> >> On Oct 30, 2015, at 12:22 PM, Zachary Turner 
>> wrote:
>> >>
>> >> Can you give me a command line which will reproduce the original
>> problem?  Because I ran through the entire test suite and nothing failed,
>> so I want to make sure we're doing the same thing.  I'm still a little
>> confused about how this happens, but I plan to look into it when I'm back
>> on Monday and see if I can understand it better to identify a better fix.
>> >>
>> >> On Fri, Oct 30, 2015 at 11:58 AM Enrico Granata 
>> wrote:
>> >>> On Oct 29, 2015, at 11:31 PM, Zachary Turner 
>> wrote:
>> >>>
>> >>> Wow.  That's a weird problem.  Thanks for finding it!
>> >>>
>> >>> Would it work if we move the definition of the `lldbtest_config`
>> class into lldbsuite/test/__init__.py?  This way the configuration should
>> be part of the global package state of the lldbsuite.test package, which
>> all the tests are already members of the same package, so they wouldn't
>> even need to import anything (I think).
>> >>>
>> >>
>> >> I think the problem is exactly that we want lldbtest_config to be
>> *global* state and not package local state.
>> >> Honestly, I think if we are not content with the fix as it stands, the
>> right way would be to change the way unittest2 imports test cases as to use
>> the package-level global scope instead of the global global state as it is
>> now.
>> >>
>>

Re: [Lldb-commits] [lldb] r251678 - Some test cases that need the lldbExec path were failing because lldbExec was turning out to be None even though it was being validly set by dotest.py

2015-11-02 Thread Zachary Turner via lldb-commits

Don't change your buildbot to not use it.  That's an error.
 packages/Python/lldbsuite/test/dotest *must* be imported, as it depends on
its __init__.py being run.  If your buildbot doesn't use it anymore, then I
think the patch I just submitted (r251819) will break your buildbot,
because I added this code:


if __name__ == "__main__":
print(__file__ + " is for use as a module only.  It should not be run
as a standalone script.")
sys.exit(-1)

to packages/Python/lldbsuite/test/dotest/dotest.py

On Mon, Nov 2, 2015 at 11:22 AM Pavel Labath  wrote:

> BTW, is lldb/test/dotest.py here to stay? I thought it was there just to
> avoid breaking anybody who runs dotest directly (instead of ninja
> check-lldb), and therefore we will remove it once everybody gets a chance
> to migrate (I have already changed our buildbots to not use it).
>
> Is that correct or I am misunderstanding something?
>
> pl
>
>
> On 2 November 2015 at 11:11, Zachary Turner via lldb-commits <
> lldb-commits@lists.llvm.org> wrote:
>
>> I looked into this some more, and unfortunately I can't reproduce it.
>> That being said, I'm not convinced this patch fixes anything.  The reason
>> is that when you import something, whether it be through the `__import__`
>> function or the `import` statement, the module itself is cached in
>> `sys.modules`.  Whether the *name* for that module is introduced globally
>> (as is done in this patch) or locally (as is done when you use an `import`
>> statement) is irrelevant.  Because the next time someone else imports it,
>> it will still find the same instance of the module in `sys.modules` and
>> just create a new name.  It won't import it anew.
>>
>> If this patch does actually fix something, I think it must be a
>> coincidence.  That said, I do have an idea as to what the problem might
>> be.  Or at the very least, I know of a problem that would definitely lead
>> to strange behavior.
>>
>> `lldbsuite` is now a package, and it relies on the code in its
>> `__init__.py` being run.  If you run
>> `packages/python/lldbsuite/test/dotest.py` manually, then `__init__.py`
>> doesn't get run, and `lldbExec` doesn't get initialized properly.
>>
>> Of course, this isn't what you're doing, but it *is* what `dosep` does
>> internally.  `dosep` manually constructs a path to 
>> `packages/python/lldbsuite/test/dotest.py`
>> and execs it.  I have a patch that fixes this and makes `dosep` exec
>> `lldb/test/dotest.py` instead, which will then lead to the package being
>> imported, and `__init__.py` being run, and everything being initialized
>> properly.
>>
>> I'm going to commit that patch by itself, and then I will submit a
>> followup patch that reverts the change from this patch (since I can't
>> reproduce this problem, I can't check whether or not my patch fixes it).
>> So if my revert breaks you again, feel free to revert the revert.  Although
>> if there's any way you can investigate a bit to understand what's going on
>> a little bit more, but I would be very grateful.  In particular, I wonder
>> about the following things:
>>
>> 1) When lldbExec is not initialized properly, is this in the same process
>> instance that you ran from the command line, or is it in the
>> multiprocessing fork?
>> 2) If you add code to `lldbsuite/__init__.py` to print the process id and
>> the value of `lldb_root`, and then add code in `dotest.py` to print the
>> process id and the value of lldbExec, what does the output look like?
>>  (Each line should be printed up to twice, due to the multiprocessing fork).
>>
>> Anyway, I'll get those 2 patches submitted to fix the dosep issue and
>> revert this change, and see what happens.
>>
>> On Fri, Oct 30, 2015 at 1:53 PM Jim Ingham  wrote:
>>
>>> Note, the other important step was that you had to have an lldb
>>> installed in /usr/bin/lldb that FAILED this test.  If you have a more
>>> recent lldb there, the test will succeed, and you won't notice you aren't
>>> testing your newly built sources.
>>>
>>> Jim
>>>
>>> > On Oct 30, 2015, at 1:25 PM, Enrico Granata via lldb-commits <
>>> lldb-commits@lists.llvm.org> wrote:
>>> >
>>> > I think what I was doing is be in lldb/test and do
>>> >
>>> > $ ./dotest.py ../packages/python/lldbsuite/functionalities/completion
>>> >
>>> >> On Oct 30, 2015, at 12:22 PM, Zachary Turner 
>>> wrote:
>>> >>
>>> >> Can you give me a command line which will reproduce the original
>>> problem?  Because I ran through the entire test suite and nothing failed,
>>> so I want to make sure we're doing the same thing.  I'm still a little
>>> confused about how this happens, but I plan to look into it when I'm back
>>> on Monday and see if I can understand it better to identify a better fix.
>>> >>
>>> >> On Fri, Oct 30, 2015 at 11:58 AM Enrico Granata 
>>> wrote:
>>> >>> On Oct 29, 2015, at 11:31 PM, Zachary Turner 
>>> wrote:
>>> >>>
>>> >>> Wow.  That's a weird problem.  Thanks for finding it!
>>> >>>
>>> >>> Would it work if we move the definition of the `lldbtest_

Re: [Lldb-commits] [lldb] r251678 - Some test cases that need the lldbExec path were failing because lldbExec was turning out to be None even though it was being validly set by dotest.py

2015-11-02 Thread Zachary Turner via lldb-commits

If you want to have a way to run the test suite without typing a long
relative path to go into the packages tree, then one thing that might work
is to make a new file packages/Python/dotest.py.

Then make it a copy of test/dotest.py.  Not real crazy about copying code,
but let me know what you think about that.

On Mon, Nov 2, 2015 at 11:24 AM Zachary Turner  wrote:

> Don't change your buildbot to not use it.  That's an error.
>  packages/Python/lldbsuite/test/dotest *must* be imported, as it depends on
> its __init__.py being run.  If your buildbot doesn't use it anymore, then I
> think the patch I just submitted (r251819) will break your buildbot,
> because I added this code:
>
>
> if __name__ == "__main__":
> print(__file__ + " is for use as a module only.  It should not be run
> as a standalone script.")
> sys.exit(-1)
>
> to packages/Python/lldbsuite/test/dotest/dotest.py
>
> On Mon, Nov 2, 2015 at 11:22 AM Pavel Labath  wrote:
>
>> BTW, is lldb/test/dotest.py here to stay? I thought it was there just to
>> avoid breaking anybody who runs dotest directly (instead of ninja
>> check-lldb), and therefore we will remove it once everybody gets a chance
>> to migrate (I have already changed our buildbots to not use it).
>>
>> Is that correct or I am misunderstanding something?
>>
>> pl
>>
>>
>> On 2 November 2015 at 11:11, Zachary Turner via lldb-commits <
>> lldb-commits@lists.llvm.org> wrote:
>>
>>> I looked into this some more, and unfortunately I can't reproduce it.
>>> That being said, I'm not convinced this patch fixes anything.  The reason
>>> is that when you import something, whether it be through the `__import__`
>>> function or the `import` statement, the module itself is cached in
>>> `sys.modules`.  Whether the *name* for that module is introduced globally
>>> (as is done in this patch) or locally (as is done when you use an `import`
>>> statement) is irrelevant.  Because the next time someone else imports it,
>>> it will still find the same instance of the module in `sys.modules` and
>>> just create a new name.  It won't import it anew.
>>>
>>> If this patch does actually fix something, I think it must be a
>>> coincidence.  That said, I do have an idea as to what the problem might
>>> be.  Or at the very least, I know of a problem that would definitely lead
>>> to strange behavior.
>>>
>>> `lldbsuite` is now a package, and it relies on the code in its
>>> `__init__.py` being run.  If you run
>>> `packages/python/lldbsuite/test/dotest.py` manually, then `__init__.py`
>>> doesn't get run, and `lldbExec` doesn't get initialized properly.
>>>
>>> Of course, this isn't what you're doing, but it *is* what `dosep` does
>>> internally.  `dosep` manually constructs a path to 
>>> `packages/python/lldbsuite/test/dotest.py`
>>> and execs it.  I have a patch that fixes this and makes `dosep` exec
>>> `lldb/test/dotest.py` instead, which will then lead to the package being
>>> imported, and `__init__.py` being run, and everything being initialized
>>> properly.
>>>
>>> I'm going to commit that patch by itself, and then I will submit a
>>> followup patch that reverts the change from this patch (since I can't
>>> reproduce this problem, I can't check whether or not my patch fixes it).
>>> So if my revert breaks you again, feel free to revert the revert.  Although
>>> if there's any way you can investigate a bit to understand what's going on
>>> a little bit more, but I would be very grateful.  In particular, I wonder
>>> about the following things:
>>>
>>> 1) When lldbExec is not initialized properly, is this in the same
>>> process instance that you ran from the command line, or is it in the
>>> multiprocessing fork?
>>> 2) If you add code to `lldbsuite/__init__.py` to print the process id
>>> and the value of `lldb_root`, and then add code in `dotest.py` to print the
>>> process id and the value of lldbExec, what does the output look like?
>>>  (Each line should be printed up to twice, due to the multiprocessing fork).
>>>
>>> Anyway, I'll get those 2 patches submitted to fix the dosep issue and
>>> revert this change, and see what happens.
>>>
>>> On Fri, Oct 30, 2015 at 1:53 PM Jim Ingham  wrote:
>>>
 Note, the other important step was that you had to have an lldb
 installed in /usr/bin/lldb that FAILED this test.  If you have a more
 recent lldb there, the test will succeed, and you won't notice you aren't
 testing your newly built sources.

 Jim

 > On Oct 30, 2015, at 1:25 PM, Enrico Granata via lldb-commits <
 lldb-commits@lists.llvm.org> wrote:
 >
 > I think what I was doing is be in lldb/test and do
 >
 > $ ./dotest.py ../packages/python/lldbsuite/functionalities/completion
 >
 >> On Oct 30, 2015, at 12:22 PM, Zachary Turner 
 wrote:
 >>
 >> Can you give me a command line which will reproduce the original
 problem?  Because I ran through the entire test suite and nothing failed,
 so I want to make sure we're d

Re: [Lldb-commits] [lldb] r251678 - Some test cases that need the lldbExec path were failing because lldbExec was turning out to be None even though it was being validly set by dotest.py

2015-11-02 Thread Zachary Turner via lldb-commits

Sorry for the email spam.  I still think the buildbot should run the
version in lldb/test though.  `test` should be a top-level folder, it makes
it easy for people who clone the repo to instantly look and figure out how
our test suite works.  So I think that's the flow that the buildbot should
test.  Developer convenience should come second.

On Mon, Nov 2, 2015 at 11:28 AM Zachary Turner  wrote:

> If you want to have a way to run the test suite without typing a long
> relative path to go into the packages tree, then one thing that might work
> is to make a new file packages/Python/dotest.py.
>
> Then make it a copy of test/dotest.py.  Not real crazy about copying code,
> but let me know what you think about that.
>
> On Mon, Nov 2, 2015 at 11:24 AM Zachary Turner  wrote:
>
>> Don't change your buildbot to not use it.  That's an error.
>>  packages/Python/lldbsuite/test/dotest *must* be imported, as it depends on
>> its __init__.py being run.  If your buildbot doesn't use it anymore, then I
>> think the patch I just submitted (r251819) will break your buildbot,
>> because I added this code:
>>
>>
>> if __name__ == "__main__":
>> print(__file__ + " is for use as a module only.  It should not be run
>> as a standalone script.")
>> sys.exit(-1)
>>
>> to packages/Python/lldbsuite/test/dotest/dotest.py
>>
>> On Mon, Nov 2, 2015 at 11:22 AM Pavel Labath  wrote:
>>
>>> BTW, is lldb/test/dotest.py here to stay? I thought it was there just to
>>> avoid breaking anybody who runs dotest directly (instead of ninja
>>> check-lldb), and therefore we will remove it once everybody gets a chance
>>> to migrate (I have already changed our buildbots to not use it).
>>>
>>> Is that correct or I am misunderstanding something?
>>>
>>> pl
>>>
>>>
>>> On 2 November 2015 at 11:11, Zachary Turner via lldb-commits <
>>> lldb-commits@lists.llvm.org> wrote:
>>>
 I looked into this some more, and unfortunately I can't reproduce it.
 That being said, I'm not convinced this patch fixes anything.  The reason
 is that when you import something, whether it be through the `__import__`
 function or the `import` statement, the module itself is cached in
 `sys.modules`.  Whether the *name* for that module is introduced globally
 (as is done in this patch) or locally (as is done when you use an `import`
 statement) is irrelevant.  Because the next time someone else imports it,
 it will still find the same instance of the module in `sys.modules` and
 just create a new name.  It won't import it anew.

 If this patch does actually fix something, I think it must be a
 coincidence.  That said, I do have an idea as to what the problem might
 be.  Or at the very least, I know of a problem that would definitely lead
 to strange behavior.

 `lldbsuite` is now a package, and it relies on the code in its
 `__init__.py` being run.  If you run
 `packages/python/lldbsuite/test/dotest.py` manually, then `__init__.py`
 doesn't get run, and `lldbExec` doesn't get initialized properly.

 Of course, this isn't what you're doing, but it *is* what `dosep` does
 internally.  `dosep` manually constructs a path to 
 `packages/python/lldbsuite/test/dotest.py`
 and execs it.  I have a patch that fixes this and makes `dosep` exec
 `lldb/test/dotest.py` instead, which will then lead to the package being
 imported, and `__init__.py` being run, and everything being initialized
 properly.

 I'm going to commit that patch by itself, and then I will submit a
 followup patch that reverts the change from this patch (since I can't
 reproduce this problem, I can't check whether or not my patch fixes it).
 So if my revert breaks you again, feel free to revert the revert.  Although
 if there's any way you can investigate a bit to understand what's going on
 a little bit more, but I would be very grateful.  In particular, I wonder
 about the following things:

 1) When lldbExec is not initialized properly, is this in the same
 process instance that you ran from the command line, or is it in the
 multiprocessing fork?
 2) If you add code to `lldbsuite/__init__.py` to print the process id
 and the value of `lldb_root`, and then add code in `dotest.py` to print the
 process id and the value of lldbExec, what does the output look like?
  (Each line should be printed up to twice, due to the multiprocessing 
 fork).

 Anyway, I'll get those 2 patches submitted to fix the dosep issue and
 revert this change, and see what happens.

 On Fri, Oct 30, 2015 at 1:53 PM Jim Ingham  wrote:

> Note, the other important step was that you had to have an lldb
> installed in /usr/bin/lldb that FAILED this test.  If you have a more
> recent lldb there, the test will succeed, and you won't notice you aren't
> testing your newly built sources.
>
> Jim
>
> > On Oct 30, 20

[Lldb-commits] [lldb] r251822 - Remove the import hack of lldbtest_config.

2015-11-02 Thread Zachary Turner via lldb-commits

Author: zturner
Date: Mon Nov  2 13:38:58 2015
New Revision: 251822

URL: http://llvm.org/viewvc/llvm-project?rev=251822&view=rev
Log:
Remove the __import__ hack of lldbtest_config.

I think the underlying problem was fixed by r251819, but I can't
reproduce the problem.  So this is to check whether it does in
fact fix the problem.

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

Modified: lldb/trunk/packages/Python/lldbsuite/test/dotest.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/dotest.py?rev=251822&r1=251821&r2=251822&view=diff
==
--- lldb/trunk/packages/Python/lldbsuite/test/dotest.py (original)
+++ lldb/trunk/packages/Python/lldbsuite/test/dotest.py Mon Nov  2 13:38:58 2015
@@ -19,15 +19,12 @@ for available options.
 """
 
 from __future__ import print_function
-# this module needs to have global visibility, otherwise test cases
-# will import it anew in their local namespace, essentially losing access
-# to all the configuration data
-globals()['lldbtest_config'] = __import__('lldbtest_config')
 
 import use_lldb_suite
-
 import lldbsuite
 
+import lldbtest_config
+
 import atexit
 import commands
 import importlib


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

Re: [Lldb-commits] [lldb] r251678 - Some test cases that need the lldbExec path were failing because lldbExec was turning out to be None even though it was being validly set by dotest.py

2015-11-02 Thread Pavel Labath via lldb-commits

It doesn't matter to me which dotest to run, I just want to know what is
the "right way". Due to enrico's patch, I couldn't run one dotest, so I
switched to another one. Now, with your patch, the other way is also
broken. Could you also go through with the other part of your change
(reverting enrico's commit), as we are out of ways to run the test suite?
(I have now switched back the builtbots to using test/dotest.py).

pl

On 2 November 2015 at 11:30, Zachary Turner  wrote:

> Sorry for the email spam.  I still think the buildbot should run the
> version in lldb/test though.  `test` should be a top-level folder, it makes
> it easy for people who clone the repo to instantly look and figure out how
> our test suite works.  So I think that's the flow that the buildbot should
> test.  Developer convenience should come second.
>
> On Mon, Nov 2, 2015 at 11:28 AM Zachary Turner  wrote:
>
>> If you want to have a way to run the test suite without typing a long
>> relative path to go into the packages tree, then one thing that might work
>> is to make a new file packages/Python/dotest.py.
>>
>> Then make it a copy of test/dotest.py.  Not real crazy about copying
>> code, but let me know what you think about that.
>>
>> On Mon, Nov 2, 2015 at 11:24 AM Zachary Turner 
>> wrote:
>>
>>> Don't change your buildbot to not use it.  That's an error.
>>>  packages/Python/lldbsuite/test/dotest *must* be imported, as it depends on
>>> its __init__.py being run.  If your buildbot doesn't use it anymore, then I
>>> think the patch I just submitted (r251819) will break your buildbot,
>>> because I added this code:
>>>
>>>
>>> if __name__ == "__main__":
>>> print(__file__ + " is for use as a module only.  It should not be
>>> run as a standalone script.")
>>> sys.exit(-1)
>>>
>>> to packages/Python/lldbsuite/test/dotest/dotest.py
>>>
>>> On Mon, Nov 2, 2015 at 11:22 AM Pavel Labath  wrote:
>>>
 BTW, is lldb/test/dotest.py here to stay? I thought it was there just
 to avoid breaking anybody who runs dotest directly (instead of ninja
 check-lldb), and therefore we will remove it once everybody gets a chance
 to migrate (I have already changed our buildbots to not use it).

 Is that correct or I am misunderstanding something?

 pl


 On 2 November 2015 at 11:11, Zachary Turner via lldb-commits <
 lldb-commits@lists.llvm.org> wrote:

> I looked into this some more, and unfortunately I can't reproduce it.
> That being said, I'm not convinced this patch fixes anything.  The reason
> is that when you import something, whether it be through the `__import__`
> function or the `import` statement, the module itself is cached in
> `sys.modules`.  Whether the *name* for that module is introduced globally
> (as is done in this patch) or locally (as is done when you use an `import`
> statement) is irrelevant.  Because the next time someone else imports it,
> it will still find the same instance of the module in `sys.modules` and
> just create a new name.  It won't import it anew.
>
> If this patch does actually fix something, I think it must be a
> coincidence.  That said, I do have an idea as to what the problem might
> be.  Or at the very least, I know of a problem that would definitely lead
> to strange behavior.
>
> `lldbsuite` is now a package, and it relies on the code in its
> `__init__.py` being run.  If you run
> `packages/python/lldbsuite/test/dotest.py` manually, then `__init__.py`
> doesn't get run, and `lldbExec` doesn't get initialized properly.
>
> Of course, this isn't what you're doing, but it *is* what `dosep` does
> internally.  `dosep` manually constructs a path to 
> `packages/python/lldbsuite/test/dotest.py`
> and execs it.  I have a patch that fixes this and makes `dosep` exec
> `lldb/test/dotest.py` instead, which will then lead to the package being
> imported, and `__init__.py` being run, and everything being initialized
> properly.
>
> I'm going to commit that patch by itself, and then I will submit a
> followup patch that reverts the change from this patch (since I can't
> reproduce this problem, I can't check whether or not my patch fixes it).
> So if my revert breaks you again, feel free to revert the revert.  
> Although
> if there's any way you can investigate a bit to understand what's going on
> a little bit more, but I would be very grateful.  In particular, I wonder
> about the following things:
>
> 1) When lldbExec is not initialized properly, is this in the same
> process instance that you ran from the command line, or is it in the
> multiprocessing fork?
> 2) If you add code to `lldbsuite/__init__.py` to print the process id
> and the value of `lldb_root`, and then add code in `dotest.py` to print 
> the
> process id and the value of lldbExec, what does the output look like

Re: [Lldb-commits] [lldb] r251678 - Some test cases that need the lldbExec path were failing because lldbExec was turning out to be None even though it was being validly set by dotest.py

2015-11-02 Thread Zachary Turner via lldb-commits

The other part of the patch should be in now (r251822).  Can you make sure
the bot is passing by running the top-level script now?  If not let me know.

On Mon, Nov 2, 2015 at 11:50 AM Pavel Labath  wrote:

> It doesn't matter to me which dotest to run, I just want to know what is
> the "right way". Due to enrico's patch, I couldn't run one dotest, so I
> switched to another one. Now, with your patch, the other way is also
> broken. Could you also go through with the other part of your change
> (reverting enrico's commit), as we are out of ways to run the test suite?
> (I have now switched back the builtbots to using test/dotest.py).
>
> pl
>
> On 2 November 2015 at 11:30, Zachary Turner  wrote:
>
>> Sorry for the email spam.  I still think the buildbot should run the
>> version in lldb/test though.  `test` should be a top-level folder, it makes
>> it easy for people who clone the repo to instantly look and figure out how
>> our test suite works.  So I think that's the flow that the buildbot should
>> test.  Developer convenience should come second.
>>
>> On Mon, Nov 2, 2015 at 11:28 AM Zachary Turner 
>> wrote:
>>
>>> If you want to have a way to run the test suite without typing a long
>>> relative path to go into the packages tree, then one thing that might work
>>> is to make a new file packages/Python/dotest.py.
>>>
>>> Then make it a copy of test/dotest.py.  Not real crazy about copying
>>> code, but let me know what you think about that.
>>>
>>> On Mon, Nov 2, 2015 at 11:24 AM Zachary Turner 
>>> wrote:
>>>
 Don't change your buildbot to not use it.  That's an error.
  packages/Python/lldbsuite/test/dotest *must* be imported, as it depends on
 its __init__.py being run.  If your buildbot doesn't use it anymore, then I
 think the patch I just submitted (r251819) will break your buildbot,
 because I added this code:


 if __name__ == "__main__":
 print(__file__ + " is for use as a module only.  It should not be
 run as a standalone script.")
 sys.exit(-1)

 to packages/Python/lldbsuite/test/dotest/dotest.py

 On Mon, Nov 2, 2015 at 11:22 AM Pavel Labath  wrote:

> BTW, is lldb/test/dotest.py here to stay? I thought it was there just
> to avoid breaking anybody who runs dotest directly (instead of ninja
> check-lldb), and therefore we will remove it once everybody gets a chance
> to migrate (I have already changed our buildbots to not use it).
>
> Is that correct or I am misunderstanding something?
>
> pl
>
>
> On 2 November 2015 at 11:11, Zachary Turner via lldb-commits <
> lldb-commits@lists.llvm.org> wrote:
>
>> I looked into this some more, and unfortunately I can't reproduce
>> it.  That being said, I'm not convinced this patch fixes anything.  The
>> reason is that when you import something, whether it be through the
>> `__import__` function or the `import` statement, the module itself is
>> cached in `sys.modules`.  Whether the *name* for that module is 
>> introduced
>> globally (as is done in this patch) or locally (as is done when you use 
>> an
>> `import` statement) is irrelevant.  Because the next time someone else
>> imports it, it will still find the same instance of the module in
>> `sys.modules` and just create a new name.  It won't import it anew.
>>
>> If this patch does actually fix something, I think it must be a
>> coincidence.  That said, I do have an idea as to what the problem might
>> be.  Or at the very least, I know of a problem that would definitely lead
>> to strange behavior.
>>
>> `lldbsuite` is now a package, and it relies on the code in its
>> `__init__.py` being run.  If you run
>> `packages/python/lldbsuite/test/dotest.py` manually, then `__init__.py`
>> doesn't get run, and `lldbExec` doesn't get initialized properly.
>>
>> Of course, this isn't what you're doing, but it *is* what `dosep`
>> does internally.  `dosep` manually constructs a path to 
>> `packages/python/lldbsuite/test/dotest.py`
>> and execs it.  I have a patch that fixes this and makes `dosep` exec
>> `lldb/test/dotest.py` instead, which will then lead to the package being
>> imported, and `__init__.py` being run, and everything being initialized
>> properly.
>>
>> I'm going to commit that patch by itself, and then I will submit a
>> followup patch that reverts the change from this patch (since I can't
>> reproduce this problem, I can't check whether or not my patch fixes it).
>> So if my revert breaks you again, feel free to revert the revert.  
>> Although
>> if there's any way you can investigate a bit to understand what's going 
>> on
>> a little bit more, but I would be very grateful.  In particular, I wonder
>> about the following things:
>>
>> 1) When lldbExec is not initialized properly, is this in the same
>>>

Re: [Lldb-commits] [PATCH] D13296: [LLDB] Fix watchpoint ignore feature for architectures with watchpoint_exceptions_received=before

2015-11-02 Thread Jim Ingham via lldb-commits

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

Yes.


Repository:
  rL LLVM

http://reviews.llvm.org/D13296



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

Re: [Lldb-commits] [lldb] r251678 - Some test cases that need the lldbExec path were failing because lldbExec was turning out to be None even though it was being validly set by dotest.py

2015-11-02 Thread Zachary Turner via lldb-commits

BTW, is your buildbot not just using "ninja check-lldb"?  So far I haven't
been able to reproduce any problems by using ninja check-lldb, but if I
know what command line is being used maybe I can reproduce a failure and
diagnose it.

On Mon, Nov 2, 2015 at 11:51 AM Zachary Turner  wrote:

> The other part of the patch should be in now (r251822).  Can you make sure
> the bot is passing by running the top-level script now?  If not let me know.
>
> On Mon, Nov 2, 2015 at 11:50 AM Pavel Labath  wrote:
>
>> It doesn't matter to me which dotest to run, I just want to know what is
>> the "right way". Due to enrico's patch, I couldn't run one dotest, so I
>> switched to another one. Now, with your patch, the other way is also
>> broken. Could you also go through with the other part of your change
>> (reverting enrico's commit), as we are out of ways to run the test suite?
>> (I have now switched back the builtbots to using test/dotest.py).
>>
>> pl
>>
>> On 2 November 2015 at 11:30, Zachary Turner  wrote:
>>
>>> Sorry for the email spam.  I still think the buildbot should run the
>>> version in lldb/test though.  `test` should be a top-level folder, it makes
>>> it easy for people who clone the repo to instantly look and figure out how
>>> our test suite works.  So I think that's the flow that the buildbot should
>>> test.  Developer convenience should come second.
>>>
>>> On Mon, Nov 2, 2015 at 11:28 AM Zachary Turner 
>>> wrote:
>>>
 If you want to have a way to run the test suite without typing a long
 relative path to go into the packages tree, then one thing that might work
 is to make a new file packages/Python/dotest.py.

 Then make it a copy of test/dotest.py.  Not real crazy about copying
 code, but let me know what you think about that.

 On Mon, Nov 2, 2015 at 11:24 AM Zachary Turner 
 wrote:

> Don't change your buildbot to not use it.  That's an error.
>  packages/Python/lldbsuite/test/dotest *must* be imported, as it depends 
> on
> its __init__.py being run.  If your buildbot doesn't use it anymore, then 
> I
> think the patch I just submitted (r251819) will break your buildbot,
> because I added this code:
>
>
> if __name__ == "__main__":
> print(__file__ + " is for use as a module only.  It should not be
> run as a standalone script.")
> sys.exit(-1)
>
> to packages/Python/lldbsuite/test/dotest/dotest.py
>
> On Mon, Nov 2, 2015 at 11:22 AM Pavel Labath 
> wrote:
>
>> BTW, is lldb/test/dotest.py here to stay? I thought it was there just
>> to avoid breaking anybody who runs dotest directly (instead of ninja
>> check-lldb), and therefore we will remove it once everybody gets a chance
>> to migrate (I have already changed our buildbots to not use it).
>>
>> Is that correct or I am misunderstanding something?
>>
>> pl
>>
>>
>> On 2 November 2015 at 11:11, Zachary Turner via lldb-commits <
>> lldb-commits@lists.llvm.org> wrote:
>>
>>> I looked into this some more, and unfortunately I can't reproduce
>>> it.  That being said, I'm not convinced this patch fixes anything.  The
>>> reason is that when you import something, whether it be through the
>>> `__import__` function or the `import` statement, the module itself is
>>> cached in `sys.modules`.  Whether the *name* for that module is 
>>> introduced
>>> globally (as is done in this patch) or locally (as is done when you use 
>>> an
>>> `import` statement) is irrelevant.  Because the next time someone else
>>> imports it, it will still find the same instance of the module in
>>> `sys.modules` and just create a new name.  It won't import it anew.
>>>
>>> If this patch does actually fix something, I think it must be a
>>> coincidence.  That said, I do have an idea as to what the problem might
>>> be.  Or at the very least, I know of a problem that would definitely 
>>> lead
>>> to strange behavior.
>>>
>>> `lldbsuite` is now a package, and it relies on the code in its
>>> `__init__.py` being run.  If you run
>>> `packages/python/lldbsuite/test/dotest.py` manually, then `__init__.py`
>>> doesn't get run, and `lldbExec` doesn't get initialized properly.
>>>
>>> Of course, this isn't what you're doing, but it *is* what `dosep`
>>> does internally.  `dosep` manually constructs a path to 
>>> `packages/python/lldbsuite/test/dotest.py`
>>> and execs it.  I have a patch that fixes this and makes `dosep` exec
>>> `lldb/test/dotest.py` instead, which will then lead to the package being
>>> imported, and `__init__.py` being run, and everything being initialized
>>> properly.
>>>
>>> I'm going to commit that patch by itself, and then I will submit a
>>> followup patch that reverts the change from this patch (since I can't
>>> reproduce this problem, I can't ch

[Lldb-commits] [lldb] r251825 - Calculate size of sockaddr_un manually for abstract sockets:

2015-11-02 Thread Oleksiy Vyalov via lldb-commits

Author: ovyalov
Date: Mon Nov  2 14:04:18 2015
New Revision: 251825

URL: http://llvm.org/viewvc/llvm-project?rev=251825&view=rev
Log:
Calculate size of sockaddr_un manually for abstract sockets:
 - SUN_LEN doesn't work because strlen(sun_path) == 0
 - sizeof(sockaddr_un) doesn't work on Android.


Modified:
lldb/trunk/source/Host/posix/DomainSocket.cpp

Modified: lldb/trunk/source/Host/posix/DomainSocket.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Host/posix/DomainSocket.cpp?rev=251825&r1=251824&r2=251825&view=diff
==
--- lldb/trunk/source/Host/posix/DomainSocket.cpp (original)
+++ lldb/trunk/source/Host/posix/DomainSocket.cpp Mon Nov  2 14:04:18 2015
@@ -11,29 +11,50 @@
 
 #include "lldb/Host/FileSystem.h"
 
+#include 
 #include 
 #include 
 
 using namespace lldb;
 using namespace lldb_private;
 
+#ifdef __ANDROID__
+// Android does not have SUN_LEN
+#ifndef SUN_LEN
+#define SUN_LEN(ptr) ((size_t) (((struct sockaddr_un *) 0)->sun_path) + 
strlen((ptr)->sun_path))
+#endif
+#endif // #ifdef __ANDROID__
+
 namespace {
 
 const int kDomain = AF_UNIX;
 const int kType   = SOCK_STREAM;
 
-bool SetSockAddr(llvm::StringRef name, const size_t name_offset, sockaddr_un* 
saddr_un)
+bool SetSockAddr(llvm::StringRef name,
+ const size_t name_offset,
+ sockaddr_un* saddr_un,
+ socklen_t& saddr_un_len)
 {
 if (name.size() + name_offset > sizeof(saddr_un->sun_path))
 return false;
 
+memset(saddr_un, 0, sizeof(*saddr_un));
 saddr_un->sun_family = kDomain;
-memset(saddr_un->sun_path, 0, sizeof(saddr_un->sun_path));
 
-strncpy(&saddr_un->sun_path[name_offset], name.data(), name.size());
+memcpy(saddr_un->sun_path + name_offset, name.data(), name.size());
+
+// For domain sockets we can use SUN_LEN in order to calculate size of
+// sockaddr_un, but for abstract sockets we have to calculate size manually
+// because of leading null symbol.
+if (name_offset == 0)
+saddr_un_len = SUN_LEN(saddr_un);
+else
+saddr_un_len = offsetof(struct sockaddr_un, sun_path) + name_offset + 
name.size();
+
 #if defined(__APPLE__) || defined(__FreeBSD__) || defined(__NetBSD__)
-saddr_un->sun_len = SUN_LEN (saddr_un);
+saddr_un->sun_len = saddr_un_len;
 #endif
+
 return true;
 }
 
@@ -58,11 +79,12 @@ Error
 DomainSocket::Connect(llvm::StringRef name)
 {
 sockaddr_un saddr_un;
-if (!SetSockAddr(name, GetNameOffset(), &saddr_un))
+socklen_t saddr_un_len;
+if (!SetSockAddr(name, GetNameOffset(), &saddr_un, saddr_un_len))
 return Error("Failed to set socket address");
 
 Error error;
-if (::connect(GetNativeSocket(), (struct sockaddr *)&saddr_un, 
sizeof(saddr_un)) < 0)
+if (::connect(GetNativeSocket(), (struct sockaddr *)&saddr_un, 
saddr_un_len) < 0)
 SetLastError (error);
 
 return error;
@@ -72,13 +94,14 @@ Error
 DomainSocket::Listen(llvm::StringRef name, int backlog)
 {
 sockaddr_un saddr_un;
-if (!SetSockAddr(name, GetNameOffset(), &saddr_un))
+socklen_t saddr_un_len;
+if (!SetSockAddr(name, GetNameOffset(), &saddr_un, saddr_un_len))
 return Error("Failed to set socket address");
 
 DeleteSocketFile(name);
 
 Error error;
-if (::bind(GetNativeSocket(), (struct sockaddr *)&saddr_un, 
sizeof(saddr_un)) == 0)
+if (::bind(GetNativeSocket(), (struct sockaddr *)&saddr_un, saddr_un_len) 
== 0)
 if (::listen(GetNativeSocket(), backlog) == 0)
 return error;
 


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

[Lldb-commits] [lldb] r251830 - [dosep] Fix-up callers of process_dir, after it got its argument removed

2015-11-02 Thread Pavel Labath via lldb-commits

Author: labath
Date: Mon Nov  2 14:54:25 2015
New Revision: 251830

URL: http://llvm.org/viewvc/llvm-project?rev=251830&view=rev
Log:
[dosep] Fix-up callers of process_dir, after it got its argument removed

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

Modified: lldb/trunk/packages/Python/lldbsuite/test/dosep.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/dosep.py?rev=251830&r1=251829&r2=251830&view=diff
==
--- lldb/trunk/packages/Python/lldbsuite/test/dosep.py (original)
+++ lldb/trunk/packages/Python/lldbsuite/test/dosep.py Mon Nov  2 14:54:25 2015
@@ -337,7 +337,7 @@ def process_dir_worker_multiprocessing(
 while not job_queue.empty():
 try:
 job = job_queue.get(block=False)
-result = process_dir(job[0], job[1], job[2], job[3],
+result = process_dir(job[0], job[1], job[2],
  inferior_pid_events)
 result_queue.put(result)
 except queue.Empty:
@@ -360,7 +360,7 @@ def process_dir_worker_threading(job_que
 while not job_queue.empty():
 try:
 job = job_queue.get(block=False)
-result = process_dir(job[0], job[1], job[2], job[3],
+result = process_dir(job[0], job[1], job[2],
  inferior_pid_events)
 result_queue.put(result)
 except queue.Empty:


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

Re: [Lldb-commits] [lldb] r251830 - [dosep] Fix-up callers of process_dir, after it got its argument removed

2015-11-02 Thread Zachary Turner via lldb-commits

Thanks.  I literally just built on Linux in order to try and reproduce some
of these issues others were seeing and I was just about to fix this before
you beat me to it.

On Mon, Nov 2, 2015 at 12:56 PM Pavel Labath via lldb-commits <
lldb-commits@lists.llvm.org> wrote:

> Author: labath
> Date: Mon Nov  2 14:54:25 2015
> New Revision: 251830
>
> URL: http://llvm.org/viewvc/llvm-project?rev=251830&view=rev
> Log:
> [dosep] Fix-up callers of process_dir, after it got its argument removed
>
> Modified:
> lldb/trunk/packages/Python/lldbsuite/test/dosep.py
>
> Modified: lldb/trunk/packages/Python/lldbsuite/test/dosep.py
> URL:
> http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/dosep.py?rev=251830&r1=251829&r2=251830&view=diff
>
> ==
> --- lldb/trunk/packages/Python/lldbsuite/test/dosep.py (original)
> +++ lldb/trunk/packages/Python/lldbsuite/test/dosep.py Mon Nov  2 14:54:25
> 2015
> @@ -337,7 +337,7 @@ def process_dir_worker_multiprocessing(
>  while not job_queue.empty():
>  try:
>  job = job_queue.get(block=False)
> -result = process_dir(job[0], job[1], job[2], job[3],
> +result = process_dir(job[0], job[1], job[2],
>   inferior_pid_events)
>  result_queue.put(result)
>  except queue.Empty:
> @@ -360,7 +360,7 @@ def process_dir_worker_threading(job_que
>  while not job_queue.empty():
>  try:
>  job = job_queue.get(block=False)
> -result = process_dir(job[0], job[1], job[2], job[3],
> +result = process_dir(job[0], job[1], job[2],
>   inferior_pid_events)
>  result_queue.put(result)
>  except queue.Empty:
>
>
> ___
> lldb-commits mailing list
> lldb-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] r251831 - First pass on www docs: Adding Programming Language Support to LLDB

2015-11-02 Thread Todd Fiala via lldb-commits

Author: tfiala
Date: Mon Nov  2 15:05:28 2015
New Revision: 251831

URL: http://llvm.org/viewvc/llvm-project?rev=251831&view=rev
Log:
First pass on www docs: Adding Programming Language Support to LLDB

We'll hook this up to the main page after Greg, Sean and others
iterate on it to a useful point.

Added:
lldb/trunk/www/adding-language-support.html

Added: lldb/trunk/www/adding-language-support.html
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/www/adding-language-support.html?rev=251831&view=auto
==
--- lldb/trunk/www/adding-language-support.html (added)
+++ lldb/trunk/www/adding-language-support.html Mon Nov  2 15:05:28 2015
@@ -0,0 +1,170 @@
+http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";>
+http://www.w3.org/1999/xhtml";>
+
+
+
+Adding Programming Language Support to LLDB
+
+
+
+  
+The LLDB Debugger
+  
+  
+
+  
+  
+   
+ Adding Programming Language Support to 
LLDB
+ 
+   
+  LLDB has been architected to make it straightforward to
+ add support for a programming language. Only a small
+ enum in core LLDB needs to be modified to make LLDB
+ aware of a new programming language. Everything else can
+ be supplied in derived classes that need not even be
+ present in the core LLDB repository. This makes it
+ convenient for developers adding language support either
+ in branches or downstream repositories since it
+ practically eliminates the potential for merge
+ conflicts.
+
+
+  The basic steps needed are as follows:
+  
+Add the language to the LanguageType enum
+Add a TypeSystem for the language
+Add expression evaluation support
+  
+
+  
+  
+
+
+   
+ Add the Language to the LanguageType enum
+ 
+
+  The LanguageType enum
+  (see http://llvm.org/svn/llvm-project/lldb/trunk/include/lldb/lldb-enumerations.h";>lldb-enumerations.h)
+  contains a list of every language known to LLDB. It is
+  the one place where support for a language must live
+  that will need to merge cleanly with core LLDB if you
+  are developing your language support in a separate
+  branch. When adding support for a language previously
+  unknown to LLDB, start by adding an enumeration entry to
+  LanguageType.
+
+  
+  
+
+   
+ Add a TypeSystem for the Language
+ 
+
+  Both http://llvm.org/svn/llvm-project/lldb/trunk/include/lldb/Core/Module.h";>Module
+  and http://llvm.org/svn/llvm-project/lldb/trunk/include/lldb/Target/Target.h";>Target
+  support the retrieval of a TypeSystem instance via
+  GetTypeSystemForLanguage(). For Module, this method is
+  directly on the Module instance. For Target, this is
+  retrieved indirectly via the TypeSystemMap for the
+  Target instance.
+
+
+  The TypeSystem instance returned by the Target is
+  expected to be capable of evaluating expressions, while
+  the TypeSystem instance returned by the Module is not.
+  If you will support expression evaluation for your
+  language, you could consider following one of these
+  approaches:
+  
+
+  implement a single TypeSystem class that supports
+  evaluation when given an optional Target,
+  implementing all the expression evaluation methods
+  on the TypeSystem in this case, OR
+
+
+  create multiple TypeSystem classes, one for
+  evaluation and one for static Module usage.
+
+  
+
+  For clang and Swift, we chose to go with the latter,
+  primarily to make it clearer that evaluation with the
+  static Module-returned TypeSystem instances make no
+  sense, and have them error out on those calls. But
+  either approach is fine to pursue.
+
+  
+  
+
+
+ Add Expression Evaluation Support
+ 
+
+  Expression Evaluation support is enabled by implementing
+  the relevant methods on a TypeSystem-derived class.
+  Search for "Expression" in the
+  http://llvm.org/svn/llvm-project/lldb/trunk/include/lldb/Symbol/TypeSystem.h";>TypeSystem
 header
+  to find relevant
+  methods to implem

[Lldb-commits] [lldb] r251835 - Move go expression tests to the new location.

2015-11-02 Thread Ryan Brown via lldb-commits

Author: ribrdb
Date: Mon Nov  2 15:28:18 2015
New Revision: 251835

URL: http://llvm.org/viewvc/llvm-project?rev=251835&view=rev
Log:
Move go expression tests to the new location.

Added:
lldb/trunk/packages/Python/lldbsuite/test/lang/go/expressions/

lldb/trunk/packages/Python/lldbsuite/test/lang/go/expressions/TestExpressions.py
  - copied, changed from r251831, 
lldb/trunk/test/lang/go/expressions/TestExpressions.py
lldb/trunk/packages/Python/lldbsuite/test/lang/go/expressions/main.go
  - copied, changed from r251831, 
lldb/trunk/test/lang/go/expressions/main.go
Removed:
lldb/trunk/test/lang/go/expressions/TestExpressions.py
lldb/trunk/test/lang/go/expressions/main.go

Copied: 
lldb/trunk/packages/Python/lldbsuite/test/lang/go/expressions/TestExpressions.py
 (from r251831, lldb/trunk/test/lang/go/expressions/TestExpressions.py)
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/lang/go/expressions/TestExpressions.py?p2=lldb/trunk/packages/Python/lldbsuite/test/lang/go/expressions/TestExpressions.py&p1=lldb/trunk/test/lang/go/expressions/TestExpressions.py&r1=251831&r2=251835&rev=251835&view=diff
==
(empty)

Copied: lldb/trunk/packages/Python/lldbsuite/test/lang/go/expressions/main.go 
(from r251831, lldb/trunk/test/lang/go/expressions/main.go)
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/lang/go/expressions/main.go?p2=lldb/trunk/packages/Python/lldbsuite/test/lang/go/expressions/main.go&p1=lldb/trunk/test/lang/go/expressions/main.go&r1=251831&r2=251835&rev=251835&view=diff
==
(empty)

Removed: lldb/trunk/test/lang/go/expressions/TestExpressions.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/test/lang/go/expressions/TestExpressions.py?rev=251834&view=auto
==
--- lldb/trunk/test/lang/go/expressions/TestExpressions.py (original)
+++ lldb/trunk/test/lang/go/expressions/TestExpressions.py (removed)
@@ -1,113 +0,0 @@
-"""Test the go expression parser/interpreter."""
-
-import os, time
-import unittest2
-import lldb
-import lldbutil
-from lldbtest import *
-
-class TestGoUserExpression(TestBase):
-
-mydir = TestBase.compute_mydir(__file__)
-
-@python_api_test
-@skipIfRemote # Not remote test suit ready
-@skipUnlessGoInstalled
-def test_with_dsym_and_python_api(self):
-"""Test GoASTUserExpress."""
-self.buildGo()
-self.launchProcess()
-self.go_expressions()
-
-def setUp(self):
-# Call super's setUp().
-TestBase.setUp(self)
-# Find the line numbers to break inside main().
-self.main_source = "main.go"
-self.break_line = line_number(self.main_source, '// Set breakpoint 
here.')
-
-def check_builtin(self, name, size=0, typeclass=lldb.eTypeClassBuiltin):
-tl = self.target().FindTypes(name)
-self.assertEqual(1, len(tl))
-t = list(tl)[0]
-self.assertEqual(name, t.name)
-self.assertEqual(typeclass, t.type)
-if size > 0:
-self.assertEqual(size, t.size)
-
-def launchProcess(self):
-exe = os.path.join(os.getcwd(), "a.out")
-
-target = self.dbg.CreateTarget(exe)
-self.assertTrue(target, VALID_TARGET)
-
-bpt = target.BreakpointCreateByLocation(self.main_source, 
self.break_line)
-self.assertTrue(bpt, VALID_BREAKPOINT)
-
-# Now launch the process, and do not stop at entry point.
-process = target.LaunchSimple (None, None, 
self.get_process_working_directory())
-
-self.assertTrue(process, PROCESS_IS_VALID)
-
-# The stop reason of the thread should be breakpoint.
-thread_list = lldbutil.get_threads_stopped_at_breakpoint (process, bpt)
-
-# Make sure we stopped at the first breakpoint.
-self.assertTrue (len(thread_list) != 0, "No thread stopped at our 
breakpoint.")
-self.assertTrue (len(thread_list) == 1, "More than one thread stopped 
at our breakpoint.")
-
-frame = thread_list[0].GetFrameAtIndex(0)
-self.assertTrue (frame, "Got a valid frame 0 frame.")
-
-def go_expressions(self):
-frame = self.frame()
-v = frame.EvaluateExpression("1")
-self.assertEqual(1, v.GetValueAsSigned())
-x = frame.EvaluateExpression("x")
-self.assertEqual(22, x.GetValueAsSigned())
-
-a = frame.EvaluateExpression("a")
-self.assertEqual(3, a.GetNumChildren())
-a0 = a.GetChildAtIndex(0)
-self.assertEqual(8, a0.GetValueAsSigned())
-
-# Array indexing
-a0 = frame.EvaluateExpression("a[0]")
-self.assertEqual(8, a0.GetValueAsSigned())
-
-# Slice indexing
-b1 = frame.EvaluateExpression("b[1]")
-self.as

[Lldb-commits] [lldb] r251838 - Change ValueObject::IsLogicalTrue so that it starts by asking the applicable Language plugin before using the C-style rule

2015-11-02 Thread Enrico Granata via lldb-commits

Author: enrico
Date: Mon Nov  2 15:52:05 2015
New Revision: 251838

URL: http://llvm.org/viewvc/llvm-project?rev=251838&view=rev
Log:
Change ValueObject::IsLogicalTrue so that it starts by asking the applicable 
Language plugin before using the C-style rule

Modified:
lldb/trunk/include/lldb/Target/Language.h
lldb/trunk/source/Core/ValueObject.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=251838&r1=251837&r2=251838&view=diff
==
--- lldb/trunk/include/lldb/Target/Language.h (original)
+++ lldb/trunk/include/lldb/Target/Language.h Mon Nov  2 15:52:05 2015
@@ -119,6 +119,10 @@ public:
 virtual DumpValueObjectOptions::DeclPrintingHelper
 GetDeclPrintingHelper ();
 
+virtual LazyBool
+IsLogicalTrue (ValueObject& valobj,
+   Error& error);
+
 // These are accessors for general information about the Languages lldb 
knows about:
 
 static lldb::LanguageType

Modified: lldb/trunk/source/Core/ValueObject.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Core/ValueObject.cpp?rev=251838&r1=251837&r2=251838&view=diff
==
--- lldb/trunk/source/Core/ValueObject.cpp (original)
+++ lldb/trunk/source/Core/ValueObject.cpp Mon Nov  2 15:52:05 2015
@@ -47,6 +47,7 @@
 #include "lldb/Symbol/Type.h"
 
 #include "lldb/Target/ExecutionContext.h"
+#include "lldb/Target/Language.h"
 #include "lldb/Target/LanguageRuntime.h"
 #include "lldb/Target/ObjCLanguageRuntime.h"
 #include "lldb/Target/Process.h"
@@ -515,6 +516,20 @@ ValueObject::ResolveValue (Scalar &scala
 bool
 ValueObject::IsLogicalTrue (Error& error)
 {
+if (Language *language = Language::FindPlugin(GetObjectRuntimeLanguage()))
+{
+LazyBool is_logical_true = language->IsLogicalTrue(*this, error);
+switch (is_logical_true)
+{
+case eLazyBoolYes:
+case eLazyBoolNo:
+return (is_logical_true == true);
+case eLazyBoolCalculate:
+default:
+break;
+}
+}
+
 Scalar scalar_value;
 
 if (!ResolveValue (scalar_value))

Modified: lldb/trunk/source/Target/Language.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Target/Language.cpp?rev=251838&r1=251837&r2=251838&view=diff
==
--- lldb/trunk/source/Target/Language.cpp (original)
+++ lldb/trunk/source/Target/Language.cpp Mon Nov  2 15:52:05 2015
@@ -351,6 +351,13 @@ Language::GetDeclPrintingHelper ()
 return nullptr;
 }
 
+LazyBool
+Language::IsLogicalTrue (ValueObject& valobj,
+ Error& error)
+{
+return eLazyBoolCalculate;
+}
+
 //--
 // Constructor
 //--


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

[Lldb-commits] [lldb] r251840 - Revert part of r239007 related to creating the Python symlink.

2015-11-02 Thread Zachary Turner via lldb-commits

Author: zturner
Date: Mon Nov  2 16:13:13 2015
New Revision: 251840

URL: http://llvm.org/viewvc/llvm-project?rev=251840&view=rev
Log:
Revert part of r239007 related to creating the Python symlink.

This has apparently been broken since June, but only on non-Windows.
Perhaps nobody noticed it because if the symlink is already there
it won't try to re-create it, and nobody ever tried doing a clean
build.

In any case, I will let the original author attempt to fix this if
he is still interested.  the problem is that in the normal case
of not setting BUILD_SHARED_LIBS and simply running ninja, it would
link _lldb.so to a non-existent location, creating a dangling
symlink.

Modified:
lldb/trunk/scripts/Python/finishSwigPythonLLDB.py

Modified: lldb/trunk/scripts/Python/finishSwigPythonLLDB.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/scripts/Python/finishSwigPythonLLDB.py?rev=251840&r1=251839&r2=251840&view=diff
==
--- lldb/trunk/scripts/Python/finishSwigPythonLLDB.py (original)
+++ lldb/trunk/scripts/Python/finishSwigPythonLLDB.py Mon Nov  2 16:13:13 2015
@@ -304,8 +304,6 @@ def make_symlink( vDictArgs, vstrFramewo
 # llvm/build/lib/python2.7/site-packages/lldb
 strBuildDir = os.path.join("..", "..", "..", "..");
 strSrc = os.path.normcase(os.path.join(strBuildDir, vstrSrcFile));
-strTargetDir = os.path.dirname(strTarget);
-strSrc = os.path.relpath(os.path.abspath(strSrc), strTargetDir);
 
 if eOSType == utilsOsType.EnumOsType.Unknown:
 bOk = False;
@@ -373,13 +371,6 @@ def make_symlink_liblldb( vDictArgs, vst
 strLibFileExtn = ".so";
 strSrc = os.path.join("lib", "liblldb" + strLibFileExtn);
 
-if eOSType != utilsOsType.EnumOsType.Windows:
-# Create a symlink to the "lib" directory, to ensure liblldb's RPATH is
-# effective.
-bOk, strErrMsg = make_symlink( vDictArgs, vstrFrameworkPythonDir, 
"lib", os.path.join("../lib") );
-if not bOk:
-return (bOk, strErrMsg)
-
 bOk, strErrMsg = make_symlink( vDictArgs, vstrFrameworkPythonDir, strSrc, 
strTarget );
 
 return (bOk, strErrMsg);


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

Re: [Lldb-commits] [lldb] r239007 - [lldb] Enable building with Cmake/BUILD_SHARED_LIBS

2015-11-02 Thread Zachary Turner via lldb-commits

Resending to the correct mailing list.

On Mon, Nov 2, 2015 at 2:17 PM Zachary Turner  wrote:

> Hi Andrew,
>
> This CL has been in for quite a while, but apparently it was broken all
> this time.  I reverted the changes to finishSwigPythonLLDB.py as they were
> creating a dangling symlink.  Please see r251840 (
> http://lists.llvm.org/pipermail/lldb-commits/Week-of-Mon-20151102/024878.html)
>  for
> more information in case you're interested in resubmitting after you figure
> out the correct fix.
>
> On Wed, Jun 3, 2015 at 8:56 PM Andrew Wilkins  wrote:
>
>> Author: axw
>> Date: Wed Jun  3 22:12:37 2015
>> New Revision: 239007
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=239007&view=rev
>> Log:
>> [lldb] Enable building with Cmake/BUILD_SHARED_LIBS
>>
>> Summary:
>> Several changes to fix CMake builds of LLDB with the
>> BUILD_SHARED_LIBS setting on.
>>
>> - Force all internal libraries to be built STATIC.
>> - Add additional library dependencies (pthread, dl,
>>   runtimedyld).
>> - modify finalisation of SWIG wrapper to symlink the
>>   "lib" dir into python/site-packages, so _lldb.so's
>>   RPATH resolves.
>>
>> Test Plan: Verified one test case with "dotest.py".
>>
>> Reviewers: sylvestre.ledru, zturner
>>
>> Reviewed By: zturner
>>
>> Subscribers: zturner, ted, tberghammer, emaste, lldb-commits
>>
>> Differential Revision: http://reviews.llvm.org/D10157
>>
>> Modified:
>> lldb/trunk/cmake/LLDBDependencies.cmake
>> lldb/trunk/cmake/modules/AddLLDB.cmake
>> lldb/trunk/cmake/modules/LLDBConfig.cmake
>> lldb/trunk/scripts/Python/finishSwigPythonLLDB.py
>> lldb/trunk/tools/lldb-server/CMakeLists.txt
>>
>> Modified: lldb/trunk/cmake/LLDBDependencies.cmake
>> URL:
>> http://llvm.org/viewvc/llvm-project/lldb/trunk/cmake/LLDBDependencies.cmake?rev=239007&r1=239006&r2=239007&view=diff
>>
>> ==
>> --- lldb/trunk/cmake/LLDBDependencies.cmake (original)
>> +++ lldb/trunk/cmake/LLDBDependencies.cmake Wed Jun  3 22:12:37 2015
>> @@ -169,6 +169,7 @@ set( LLVM_LINK_COMPONENTS
>>core
>>mcdisassembler
>>executionengine
>> +  runtimedyld
>>option
>>support
>>)
>>
>> Modified: lldb/trunk/cmake/modules/AddLLDB.cmake
>> URL:
>> http://llvm.org/viewvc/llvm-project/lldb/trunk/cmake/modules/AddLLDB.cmake?rev=239007&r1=239006&r2=239007&view=diff
>>
>> ==
>> --- lldb/trunk/cmake/modules/AddLLDB.cmake (original)
>> +++ lldb/trunk/cmake/modules/AddLLDB.cmake Wed Jun  3 22:12:37 2015
>> @@ -44,13 +44,14 @@ macro(add_lldb_library name)
>>  set(libkind MODULE)
>>elseif (PARAM_SHARED)
>>  set(libkind SHARED)
>> -  elseif (PARAM_STATIC)
>> -set(libkind STATIC)
>>elseif (PARAM_OBJECT)
>>  set(libkind OBJECT)
>>else ()
>> -# library type unspecified - controlled by BUILD_SHARED_LIBS
>> -unset(libkind)
>> +# PARAM_STATIC or library type unspecified. BUILD_SHARED_LIBS
>> +# does not control the kind of libraries created for LLDB,
>> +# only whether or not they link to shared/static LLVM/Clang
>> +# libraries.
>> +set(libkind STATIC)
>>endif()
>>
>>#PIC not needed on Win
>>
>> Modified: lldb/trunk/cmake/modules/LLDBConfig.cmake
>> URL:
>> http://llvm.org/viewvc/llvm-project/lldb/trunk/cmake/modules/LLDBConfig.cmake?rev=239007&r1=239006&r2=239007&view=diff
>>
>> ==
>> --- lldb/trunk/cmake/modules/LLDBConfig.cmake (original)
>> +++ lldb/trunk/cmake/modules/LLDBConfig.cmake Wed Jun  3 22:12:37 2015
>> @@ -219,6 +219,14 @@ else()
>>
>>  endif()
>>
>> +if (HAVE_LIBPTHREAD)
>> +  list(APPEND system_libs pthread)
>> +endif(HAVE_LIBPTHREAD)
>> +
>> +if (HAVE_LIBDL)
>> +  list(APPEND system_libs ${CMAKE_DL_LIBS})
>> +endif()
>> +
>>  if(LLDB_REQUIRES_EH)
>>set(LLDB_REQUIRES_RTTI ON)
>>  else()
>>
>> Modified: lldb/trunk/scripts/Python/finishSwigPythonLLDB.py
>> URL:
>> http://llvm.org/viewvc/llvm-project/lldb/trunk/scripts/Python/finishSwigPythonLLDB.py?rev=239007&r1=239006&r2=239007&view=diff
>>
>> =

Re: [Lldb-commits] [lldb] r251678 - Some test cases that need the lldbExec path were failing because lldbExec was turning out to be None even though it was being validly set by dotest.py

2015-11-02 Thread Zachary Turner via lldb-commits

Finally managed to get a working Linux build.  This seems to be fixed on
Linux -- or at the very least, it works right now (maybe it always did?)
 So I'm hoping this means it's fixed on OSX now too, but please let me know
if it's still broken.

On Mon, Nov 2, 2015 at 11:59 AM Zachary Turner  wrote:

> BTW, is your buildbot not just using "ninja check-lldb"?  So far I haven't
> been able to reproduce any problems by using ninja check-lldb, but if I
> know what command line is being used maybe I can reproduce a failure and
> diagnose it.
>
> On Mon, Nov 2, 2015 at 11:51 AM Zachary Turner  wrote:
>
>> The other part of the patch should be in now (r251822).  Can you make
>> sure the bot is passing by running the top-level script now?  If not let me
>> know.
>>
>> On Mon, Nov 2, 2015 at 11:50 AM Pavel Labath  wrote:
>>
>>> It doesn't matter to me which dotest to run, I just want to know what is
>>> the "right way". Due to enrico's patch, I couldn't run one dotest, so I
>>> switched to another one. Now, with your patch, the other way is also
>>> broken. Could you also go through with the other part of your change
>>> (reverting enrico's commit), as we are out of ways to run the test suite?
>>> (I have now switched back the builtbots to using test/dotest.py).
>>>
>>> pl
>>>
>>> On 2 November 2015 at 11:30, Zachary Turner  wrote:
>>>
 Sorry for the email spam.  I still think the buildbot should run the
 version in lldb/test though.  `test` should be a top-level folder, it makes
 it easy for people who clone the repo to instantly look and figure out how
 our test suite works.  So I think that's the flow that the buildbot should
 test.  Developer convenience should come second.

 On Mon, Nov 2, 2015 at 11:28 AM Zachary Turner 
 wrote:

> If you want to have a way to run the test suite without typing a long
> relative path to go into the packages tree, then one thing that might work
> is to make a new file packages/Python/dotest.py.
>
> Then make it a copy of test/dotest.py.  Not real crazy about copying
> code, but let me know what you think about that.
>
> On Mon, Nov 2, 2015 at 11:24 AM Zachary Turner 
> wrote:
>
>> Don't change your buildbot to not use it.  That's an error.
>>  packages/Python/lldbsuite/test/dotest *must* be imported, as it depends 
>> on
>> its __init__.py being run.  If your buildbot doesn't use it anymore, 
>> then I
>> think the patch I just submitted (r251819) will break your buildbot,
>> because I added this code:
>>
>>
>> if __name__ == "__main__":
>> print(__file__ + " is for use as a module only.  It should not be
>> run as a standalone script.")
>> sys.exit(-1)
>>
>> to packages/Python/lldbsuite/test/dotest/dotest.py
>>
>> On Mon, Nov 2, 2015 at 11:22 AM Pavel Labath 
>> wrote:
>>
>>> BTW, is lldb/test/dotest.py here to stay? I thought it was there
>>> just to avoid breaking anybody who runs dotest directly (instead of 
>>> ninja
>>> check-lldb), and therefore we will remove it once everybody gets a 
>>> chance
>>> to migrate (I have already changed our buildbots to not use it).
>>>
>>> Is that correct or I am misunderstanding something?
>>>
>>> pl
>>>
>>>
>>> On 2 November 2015 at 11:11, Zachary Turner via lldb-commits <
>>> lldb-commits@lists.llvm.org> wrote:
>>>
 I looked into this some more, and unfortunately I can't reproduce
 it.  That being said, I'm not convinced this patch fixes anything.  The
 reason is that when you import something, whether it be through the
 `__import__` function or the `import` statement, the module itself is
 cached in `sys.modules`.  Whether the *name* for that module is 
 introduced
 globally (as is done in this patch) or locally (as is done when you 
 use an
 `import` statement) is irrelevant.  Because the next time someone else
 imports it, it will still find the same instance of the module in
 `sys.modules` and just create a new name.  It won't import it anew.

 If this patch does actually fix something, I think it must be a
 coincidence.  That said, I do have an idea as to what the problem might
 be.  Or at the very least, I know of a problem that would definitely 
 lead
 to strange behavior.

 `lldbsuite` is now a package, and it relies on the code in its
 `__init__.py` being run.  If you run
 `packages/python/lldbsuite/test/dotest.py` manually, then `__init__.py`
 doesn't get run, and `lldbExec` doesn't get initialized properly.

 Of course, this isn't what you're doing, but it *is* what `dosep`
 does internally.  `dosep` manually constructs a path to 
 `packages/python/lldbsuite/test/dotest.py`
 and execs it.  I have a

[Lldb-commits] [lldb] r251844 - Add a sketched out section on adding Language and LanguageRuntime plugins for language support

2015-11-02 Thread Enrico Granata via lldb-commits

Author: enrico
Date: Mon Nov  2 16:26:55 2015
New Revision: 251844

URL: http://llvm.org/viewvc/llvm-project?rev=251844&view=rev
Log:
Add a sketched out section on adding Language and LanguageRuntime plugins for 
language support

Modified:
lldb/trunk/www/adding-language-support.html

Modified: lldb/trunk/www/adding-language-support.html
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/www/adding-language-support.html?rev=251844&r1=251843&r2=251844&view=diff
==
--- lldb/trunk/www/adding-language-support.html (original)
+++ lldb/trunk/www/adding-language-support.html Mon Nov  2 16:26:55 2015
@@ -37,6 +37,8 @@
 Add expression evaluation support
   
 
+
+  Additionally, you may want to create a Language and 
LanguageRuntime plugin for your language, which enables support for advanced 
features like dynamic typing and data formatting.
   
   
 
@@ -163,6 +165,27 @@
   
   
 
+  
+   
+ Language and LanguageRuntime plugins
+ 
+
+  If you followed the steps outlined above, you already have 
taught LLDB a great deal about your language. And if your language's runtime 
model and fundamental data types don't differ much from the C model, you are 
pretty much done.
+  
+  However, it is likely that your language offers its own data 
types for things like strings, arrays, ..., and probably has a notion of 
dynamic types, where the effective type of a variable can only be known at 
runtime.
+
+
+  These tasks are covered by two plugins:
+  
+a LanguageRuntime plugin, which provides LLDB with a 
dynamic view of your language; this plugin answers questions that require a 
live process to acquire information (e.g. dynamic type resolution)
+a Language plugin, which provides LLDB with a static view 
of your language; questions that are statically knoawble and do not require a 
process are answered by this plugin (e.g. data formatters)
+  
+
+  
+  
+
+  
+
   
 
   


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

[Lldb-commits] [lldb] r251847 - Create lldbsuite.support package with `seven` file.

2015-11-02 Thread Zachary Turner via lldb-commits

Author: zturner
Date: Mon Nov  2 16:41:01 2015
New Revision: 251847

URL: http://llvm.org/viewvc/llvm-project?rev=251847&view=rev
Log:
Create lldbsuite.support package with `seven` file.

This file will be useful for filling in the gaps where `six` is
missing some things we need.

Added:
lldb/trunk/packages/Python/lldbsuite/support/
lldb/trunk/packages/Python/lldbsuite/support/__init__.py
lldb/trunk/packages/Python/lldbsuite/support/seven.py

Added: lldb/trunk/packages/Python/lldbsuite/support/__init__.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/support/__init__.py?rev=251847&view=auto
==
(empty)

Added: lldb/trunk/packages/Python/lldbsuite/support/seven.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/support/seven.py?rev=251847&view=auto
==
--- lldb/trunk/packages/Python/lldbsuite/support/seven.py (added)
+++ lldb/trunk/packages/Python/lldbsuite/support/seven.py Mon Nov  2 16:41:01 
2015
@@ -0,0 +1,17 @@
+import six
+
+if six.PY2:
+import commands
+get_command_output = commands.getoutput
+get_command_status_output = commands.getstatusoutput
+
+else:
+def get_command_status_output(command):
+try:
+import subprocess
+return (0, subprocess.check_output(command, shell=True))
+except subprocess.CalledProcessError as e:
+return (e.returncode, e.output)
+
+def get_command_output(command):
+return get_command_status_output(command)[1]


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

[Lldb-commits] [PATCH] D14262: Provide ADB port forwarding support for abstract sockets

2015-11-02 Thread Oleksiy Vyalov via lldb-commits

ovyalov created this revision.
ovyalov added reviewers: clayborg, tberghammer.
ovyalov added a subscriber: lldb-commits.
Herald added subscribers: danalbert, tberghammer.

Provide ADB port forwarding support for abstract sockets.

http://reviews.llvm.org/D14262

Files:
  include/lldb/Host/posix/ConnectionFileDescriptorPosix.h
  source/Host/posix/ConnectionFileDescriptorPosix.cpp
  source/Plugins/Platform/Android/AdbClient.cpp
  source/Plugins/Platform/Android/AdbClient.h
  source/Plugins/Platform/Android/PlatformAndroidRemoteGDBServer.cpp
  source/Plugins/Platform/Android/PlatformAndroidRemoteGDBServer.h

Index: source/Plugins/Platform/Android/PlatformAndroidRemoteGDBServer.h
===
--- source/Plugins/Platform/Android/PlatformAndroidRemoteGDBServer.h
+++ source/Plugins/Platform/Android/PlatformAndroidRemoteGDBServer.h
@@ -19,6 +19,10 @@
 // Project includes
 #include "Plugins/Platform/gdb-server/PlatformRemoteGDBServer.h"
 
+#include "llvm/ADT/Optional.h"
+
+#include "AdbClient.h"
+
 namespace lldb_private {
 namespace platform_android {
 
@@ -38,6 +42,7 @@
 protected:
 std::string m_device_id;
 std::map m_port_forwards;
+llvm::Optional m_socket_namespace;
 
 bool
 LaunchGDBServer (lldb::pid_t &pid, std::string &connect_url) override;
Index: source/Plugins/Platform/Android/PlatformAndroidRemoteGDBServer.cpp
===
--- source/Plugins/Platform/Android/PlatformAndroidRemoteGDBServer.cpp
+++ source/Plugins/Platform/Android/PlatformAndroidRemoteGDBServer.cpp
@@ -11,7 +11,6 @@
 #include "lldb/Core/Error.h"
 #include "lldb/Core/Log.h"
 #include "lldb/Host/common/TCPSocket.h"
-#include "AdbClient.h"
 #include "PlatformAndroidRemoteGDBServer.h"
 #include "Utility/UriParser.h"
 
@@ -27,6 +26,7 @@
 ForwardPortWithAdb (const uint16_t local_port,
 const uint16_t remote_port,
 const char* remote_socket_name,
+const llvm::Optional& socket_namespace,
 std::string& device_id)
 {
 Log *log(GetLogIfAllCategoriesSet (LIBLLDB_LOG_PLATFORM));
@@ -49,7 +49,11 @@
 
 if (log)
 log->Printf("Forwarding remote socket \"%s\" to local TCP port %d", remote_socket_name, local_port);
-return adb.SetPortForwarding(local_port, remote_socket_name);
+
+if (!socket_namespace)
+return Error("Invalid socket namespace");
+
+return adb.SetPortForwarding(local_port, remote_socket_name, *socket_namespace);
 }
 
 static Error
@@ -129,6 +133,12 @@
 if (host != "localhost")
 m_device_id = host;
 
+m_socket_namespace.reset();
+if (scheme == ConnectionFileDescriptor::UNIX_CONNECT_SCHEME)
+m_socket_namespace = AdbClient::UnixSocketNamespaceFileSystem;
+else if (scheme == ConnectionFileDescriptor::UNIX_ABSTRACT_CONNECT_SCHEME)
+m_socket_namespace = AdbClient::UnixSocketNamespaceAbstract;
+
 std::string connect_url;
 auto error = MakeConnectURL (g_remote_platform_pid,
  (remote_port < 0) ? 0 : remote_port,
@@ -196,7 +206,11 @@
 if (error.Fail())
 return error;
 
-error = ForwardPortWithAdb(local_port, remote_port, remote_socket_name, m_device_id);
+error = ForwardPortWithAdb(local_port,
+   remote_port,
+   remote_socket_name,
+   m_socket_namespace,
+   m_device_id);
 if (error.Success())
 {
 m_port_forwards[pid] = local_port;
Index: source/Plugins/Platform/Android/AdbClient.h
===
--- source/Plugins/Platform/Android/AdbClient.h
+++ source/Plugins/Platform/Android/AdbClient.h
@@ -33,6 +33,12 @@
 class AdbClient
 {
 public:
+enum UnixSocketNamespace
+{
+UnixSocketNamespaceAbstract,
+UnixSocketNamespaceFileSystem,
+};
+
 using DeviceIDList = std::list;
 
 static Error
@@ -51,7 +57,9 @@
 SetPortForwarding (const uint16_t local_port, const uint16_t remote_port);
 
 Error
-SetPortForwarding (const uint16_t local_port, const char* remote_socket_name);
+SetPortForwarding (const uint16_t local_port,
+   const char* remote_socket_name,
+   const UnixSocketNamespace socket_namespace);
 
 Error
 DeletePortForwarding (const uint16_t local_port);
Index: source/Plugins/Platform/Android/AdbClient.cpp
===
--- source/Plugins/Platform/Android/AdbClient.cpp
+++ source/Plugins/Platform/Android/AdbClient.cpp
@@ -50,6 +50,9 @@
 // Default mode for pushed files.
 const uint32_t kDefaultMode = 0100770; // S_IFREG | S_IRWXU | S_IRWXG
 
+const char * kSocketNamespaceAbstract = "localabstract";
+const char * kSocketNamespaceFileSystem = "lo

[Lldb-commits] [lldb] r251861 - This test case does not actually depend on Cocoa; Foundation is good enoguh

2015-11-02 Thread Enrico Granata via lldb-commits

Author: enrico
Date: Mon Nov  2 17:37:55 2015
New Revision: 251861

URL: http://llvm.org/viewvc/llvm-project?rev=251861&view=rev
Log:
This test case does not actually depend on Cocoa; Foundation is good enoguh

Modified:
lldb/trunk/packages/Python/lldbsuite/test/python_api/objc_type/Makefile
lldb/trunk/packages/Python/lldbsuite/test/python_api/objc_type/main.m

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/python_api/objc_type/Makefile
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/python_api/objc_type/Makefile?rev=251861&r1=251860&r2=251861&view=diff
==
--- lldb/trunk/packages/Python/lldbsuite/test/python_api/objc_type/Makefile 
(original)
+++ lldb/trunk/packages/Python/lldbsuite/test/python_api/objc_type/Makefile Mon 
Nov  2 17:37:55 2015
@@ -6,4 +6,4 @@ CFLAGS_EXTRAS += -w
 
 include $(LEVEL)/Makefile.rules
 
-LDFLAGS += -framework Cocoa
+LDFLAGS += -framework Foundation

Modified: lldb/trunk/packages/Python/lldbsuite/test/python_api/objc_type/main.m
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/python_api/objc_type/main.m?rev=251861&r1=251860&r2=251861&view=diff
==
--- lldb/trunk/packages/Python/lldbsuite/test/python_api/objc_type/main.m 
(original)
+++ lldb/trunk/packages/Python/lldbsuite/test/python_api/objc_type/main.m Mon 
Nov  2 17:37:55 2015
@@ -7,7 +7,7 @@
 //
 
//===--===//
 
-#import 
+#import 
 
 @interface Foo: NSObject
 {}


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

[Lldb-commits] [lldb] r251862 - Revert "Remove the import hack of lldbtest_config."

2015-11-02 Thread Pavel Labath via lldb-commits

Author: labath
Date: Mon Nov  2 17:39:09 2015
New Revision: 251862

URL: http://llvm.org/viewvc/llvm-project?rev=251862&view=rev
Log:
Revert "Remove the __import__ hack of lldbtest_config."

The hack still seems to be necessary. Putting it back in until we figure out 
why.

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

Modified: lldb/trunk/packages/Python/lldbsuite/test/dotest.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/dotest.py?rev=251862&r1=251861&r2=251862&view=diff
==
--- lldb/trunk/packages/Python/lldbsuite/test/dotest.py (original)
+++ lldb/trunk/packages/Python/lldbsuite/test/dotest.py Mon Nov  2 17:39:09 2015
@@ -19,11 +19,14 @@ for available options.
 """
 
 from __future__ import print_function
+# this module needs to have global visibility, otherwise test cases
+# will import it anew in their local namespace, essentially losing access
+# to all the configuration data
+globals()['lldbtest_config'] = __import__('lldbtest_config')
 
 import use_lldb_suite
-import lldbsuite
 
-import lldbtest_config
+import lldbsuite
 
 import atexit
 import commands


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

[Lldb-commits] [lldb] r251863 - Revert "Make new dotest.py executable"

2015-11-02 Thread Pavel Labath via lldb-commits

Author: labath
Date: Mon Nov  2 17:41:44 2015
New Revision: 251863

URL: http://llvm.org/viewvc/llvm-project?rev=251863&view=rev
Log:
Revert "Make new dotest.py executable"

This was a misunderstanding on my part. The new dotest.py is not meant to be 
executed directly.

Modified:
lldb/trunk/packages/Python/lldbsuite/test/dotest.py   (contents, props 
changed)

Modified: lldb/trunk/packages/Python/lldbsuite/test/dotest.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/dotest.py?rev=251863&r1=251862&r2=251863&view=diff
==
(empty)

Propchange: lldb/trunk/packages/Python/lldbsuite/test/dotest.py
--
--- svn:executable (original)
+++ svn:executable (removed)
@@ -1 +0,0 @@
-*


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

[Lldb-commits] [PATCH] D14264: Fix module cache sym links' creation for symbol files

2015-11-02 Thread Oleksiy Vyalov via lldb-commits

ovyalov created this revision.
ovyalov added a reviewer: tberghammer.
ovyalov added a subscriber: lldb-commits.
Herald added subscribers: danalbert, tberghammer, aemerson.

Pass symbol file platform's file spec to ModuleCache::Put  - i.e., to make sym 
link path like this: 
.lldb/module_cache/remote-android/04a2366b2238fb06/data/dalvik-cache/arm/system@framew...@boot.oat.sym

http://reviews.llvm.org/D14264

Files:
  source/Utility/ModuleCache.cpp

Index: source/Utility/ModuleCache.cpp
===
--- source/Utility/ModuleCache.cpp
+++ source/Utility/ModuleCache.cpp
@@ -304,13 +304,13 @@
 // contain the neccessary symbols and the debugging is also possible 
without a symfile.
 return Error ();
 
-FileSpec symfile_spec = GetSymbolFileSpec (cached_module_sp->GetFileSpec 
());
-error = Put (root_dir_spec, hostname, module_spec, 
tmp_download_sym_file_spec, symfile_spec);
+error = Put (root_dir_spec, hostname, module_spec, 
tmp_download_sym_file_spec, GetSymbolFileSpec(module_spec.GetFileSpec ()));
 if (error.Fail ())
 return Error ("Failed to put symbol file into cache: %s", 
error.AsCString ());
 
 tmp_symfile_remover.releaseFile();
 
+FileSpec symfile_spec = GetSymbolFileSpec (cached_module_sp->GetFileSpec 
());
 cached_module_sp->SetSymbolFileFileSpec (symfile_spec);
 return Error ();
 }


Index: source/Utility/ModuleCache.cpp
===
--- source/Utility/ModuleCache.cpp
+++ source/Utility/ModuleCache.cpp
@@ -304,13 +304,13 @@
 // contain the neccessary symbols and the debugging is also possible without a symfile.
 return Error ();
 
-FileSpec symfile_spec = GetSymbolFileSpec (cached_module_sp->GetFileSpec ());
-error = Put (root_dir_spec, hostname, module_spec, tmp_download_sym_file_spec, symfile_spec);
+error = Put (root_dir_spec, hostname, module_spec, tmp_download_sym_file_spec, GetSymbolFileSpec(module_spec.GetFileSpec ()));
 if (error.Fail ())
 return Error ("Failed to put symbol file into cache: %s", error.AsCString ());
 
 tmp_symfile_remover.releaseFile();
 
+FileSpec symfile_spec = GetSymbolFileSpec (cached_module_sp->GetFileSpec ());
 cached_module_sp->SetSymbolFileFileSpec (symfile_spec);
 return Error ();
 }
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [PATCH] D14264: Fix module cache sym links' creation for symbol files

2015-11-02 Thread Tamas Berghammer via lldb-commits

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

LGTM


http://reviews.llvm.org/D14264



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

[Lldb-commits] [lldb] r251871 - Fix module cache sym links' creation for symbol files.

2015-11-02 Thread Oleksiy Vyalov via lldb-commits

Author: ovyalov
Date: Mon Nov  2 18:30:19 2015
New Revision: 251871

URL: http://llvm.org/viewvc/llvm-project?rev=251871&view=rev
Log:
Fix module cache sym links' creation for symbol files.

http://reviews.llvm.org/D14264


Modified:
lldb/trunk/source/Utility/ModuleCache.cpp

Modified: lldb/trunk/source/Utility/ModuleCache.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Utility/ModuleCache.cpp?rev=251871&r1=251870&r2=251871&view=diff
==
--- lldb/trunk/source/Utility/ModuleCache.cpp (original)
+++ lldb/trunk/source/Utility/ModuleCache.cpp Mon Nov  2 18:30:19 2015
@@ -304,13 +304,13 @@ ModuleCache::GetAndPut (const FileSpec &
 // contain the neccessary symbols and the debugging is also possible 
without a symfile.
 return Error ();
 
-FileSpec symfile_spec = GetSymbolFileSpec (cached_module_sp->GetFileSpec 
());
-error = Put (root_dir_spec, hostname, module_spec, 
tmp_download_sym_file_spec, symfile_spec);
+error = Put (root_dir_spec, hostname, module_spec, 
tmp_download_sym_file_spec, GetSymbolFileSpec(module_spec.GetFileSpec ()));
 if (error.Fail ())
 return Error ("Failed to put symbol file into cache: %s", 
error.AsCString ());
 
 tmp_symfile_remover.releaseFile();
 
+FileSpec symfile_spec = GetSymbolFileSpec (cached_module_sp->GetFileSpec 
());
 cached_module_sp->SetSymbolFileFileSpec (symfile_spec);
 return Error ();
 }


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

Re: [Lldb-commits] [lldb] r251862 - Revert "Remove the import hack of lldbtest_config."

2015-11-02 Thread Zachary Turner via lldb-commits

I think what is happening is that when we go through unittest2, the package
link is being broken.

Inside dotest.py : __package__ = lldbsuite.test
Inside unittest2.loadTestsFromName : __package__ = unittest2
Inside TestMultithreaded.py : __package__ = None

Restoring the link by writing

__package__ = "lldbsuite.test"

at the top of TestMultithreaded.py seems to fix the problem, although that
really bothersome to have to do that in every single file.  I'm still
trying to figure out the proper fix.

On Mon, Nov 2, 2015 at 3:41 PM Pavel Labath via lldb-commits <
lldb-commits@lists.llvm.org> wrote:

> Author: labath
> Date: Mon Nov  2 17:39:09 2015
> New Revision: 251862
>
> URL: http://llvm.org/viewvc/llvm-project?rev=251862&view=rev
> Log:
> Revert "Remove the __import__ hack of lldbtest_config."
>
> The hack still seems to be necessary. Putting it back in until we figure
> out why.
>
> Modified:
> lldb/trunk/packages/Python/lldbsuite/test/dotest.py
>
> Modified: lldb/trunk/packages/Python/lldbsuite/test/dotest.py
> URL:
> http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/dotest.py?rev=251862&r1=251861&r2=251862&view=diff
>
> ==
> --- lldb/trunk/packages/Python/lldbsuite/test/dotest.py (original)
> +++ lldb/trunk/packages/Python/lldbsuite/test/dotest.py Mon Nov  2
> 17:39:09 2015
> @@ -19,11 +19,14 @@ for available options.
>  """
>
>  from __future__ import print_function
> +# this module needs to have global visibility, otherwise test cases
> +# will import it anew in their local namespace, essentially losing access
> +# to all the configuration data
> +globals()['lldbtest_config'] = __import__('lldbtest_config')
>
>  import use_lldb_suite
> -import lldbsuite
>
> -import lldbtest_config
> +import lldbsuite
>
>  import atexit
>  import commands
>
>
> ___
> 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] D14264: Fix module cache sym links' creation for symbol files

2015-11-02 Thread Oleksiy Vyalov via lldb-commits

ovyalov closed this revision.
ovyalov added a comment.

Submitted as http://reviews.llvm.org/rL251871


http://reviews.llvm.org/D14264



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

Re: [Lldb-commits] [PATCH] D14262: Provide ADB port forwarding support for abstract sockets

2015-11-02 Thread Tamas Berghammer via lldb-commits

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

LGTM



Comment at: source/Host/posix/ConnectionFileDescriptorPosix.cpp:182
@@ -156,2 +181,3 @@
 {
-if (strstr(s, "listen://") == s)
+const char *addr;
+if ((addr = GetURLAddress(s, LISTEN_SCHEME)))

(nit): Please initialize


http://reviews.llvm.org/D14262



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

Re: [Lldb-commits] [lldb] r251862 - Revert "Remove the import hack of lldbtest_config."

2015-11-02 Thread Zachary Turner via lldb-commits

+Enrico Granata 

On Mon, Nov 2, 2015 at 4:42 PM Zachary Turner  wrote:

> Ok, I think I figured out the root of all the problems.
>
> First, in setupSysPath we have this:
>
> sys.path.insert(0, scriptPath)
>
> This basically adds `lldb/packages/Python/lldbsuite/test` to sys.path.
>
> Then, in the individual tests we write this:
>
> from lldbtest import *
>
> It finds lldbtest at the above path, and imports it.  But this is *not*
> the same copy of lldbtest that has already been imported, because that copy
> was imported as a member of the lldbsuite.test package.  So now we have
> this module in sys.modules twice.  Once as lldbtest, found by looking in
> lldbsuite/test since it was in sys.path.  And once as
> lldbsuite.test.lldbtest, found because lldbsuite was in sys.path, using
> subpackage resolution.
>
> I think the fix for all of these problems is to *remove* scriptPath from
> sys.path.  We shouldn't be mucking with sys.path for stuff in our own test
> suite.  We should resolve the references explicitly with subpackage
> references.  For example, even if I don't write __package__ =
> "lldbsuite.test" in TestMultithreaded.py, I can still fix the problem with
> the below patch:
>
> - from lldbtest import *
> + from lldbsuite.test.lldbtest import *
>
> because now we're referencing the module that has already been imported.
> This is the "correct" way to do it, so if we tighten up sys.path, nobody
> should be able to make this mistake again.
>
> On Mon, Nov 2, 2015 at 4:32 PM Zachary Turner  wrote:
>
>> I think what is happening is that when we go through unittest2, the
>> package link is being broken.
>>
>> Inside dotest.py : __package__ = lldbsuite.test
>> Inside unittest2.loadTestsFromName : __package__ = unittest2
>> Inside TestMultithreaded.py : __package__ = None
>>
>> Restoring the link by writing
>>
>> __package__ = "lldbsuite.test"
>>
>> at the top of TestMultithreaded.py seems to fix the problem, although
>> that really bothersome to have to do that in every single file.  I'm still
>> trying to figure out the proper fix.
>>
>> On Mon, Nov 2, 2015 at 3:41 PM Pavel Labath via lldb-commits <
>> lldb-commits@lists.llvm.org> wrote:
>>
>>> Author: labath
>>> Date: Mon Nov  2 17:39:09 2015
>>> New Revision: 251862
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=251862&view=rev
>>> Log:
>>> Revert "Remove the __import__ hack of lldbtest_config."
>>>
>>> The hack still seems to be necessary. Putting it back in until we figure
>>> out why.
>>>
>>> Modified:
>>> lldb/trunk/packages/Python/lldbsuite/test/dotest.py
>>>
>>> Modified: lldb/trunk/packages/Python/lldbsuite/test/dotest.py
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/dotest.py?rev=251862&r1=251861&r2=251862&view=diff
>>>
>>> ==
>>> --- lldb/trunk/packages/Python/lldbsuite/test/dotest.py (original)
>>> +++ lldb/trunk/packages/Python/lldbsuite/test/dotest.py Mon Nov  2
>>> 17:39:09 2015
>>> @@ -19,11 +19,14 @@ for available options.
>>>  """
>>>
>>>  from __future__ import print_function
>>> +# this module needs to have global visibility, otherwise test cases
>>> +# will import it anew in their local namespace, essentially losing
>>> access
>>> +# to all the configuration data
>>> +globals()['lldbtest_config'] = __import__('lldbtest_config')
>>>
>>>  import use_lldb_suite
>>> -import lldbsuite
>>>
>>> -import lldbtest_config
>>> +import lldbsuite
>>>
>>>  import atexit
>>>  import commands
>>>
>>>
>>> ___
>>> 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] r251862 - Revert "Remove the import hack of lldbtest_config."

2015-11-02 Thread Zachary Turner via lldb-commits

Ok, I think I figured out the root of all the problems.

First, in setupSysPath we have this:

sys.path.insert(0, scriptPath)

This basically adds `lldb/packages/Python/lldbsuite/test` to sys.path.

Then, in the individual tests we write this:

from lldbtest import *

It finds lldbtest at the above path, and imports it.  But this is *not* the
same copy of lldbtest that has already been imported, because that copy was
imported as a member of the lldbsuite.test package.  So now we have this
module in sys.modules twice.  Once as lldbtest, found by looking in
lldbsuite/test since it was in sys.path.  And once as
lldbsuite.test.lldbtest, found because lldbsuite was in sys.path, using
subpackage resolution.

I think the fix for all of these problems is to *remove* scriptPath from
sys.path.  We shouldn't be mucking with sys.path for stuff in our own test
suite.  We should resolve the references explicitly with subpackage
references.  For example, even if I don't write __package__ =
"lldbsuite.test" in TestMultithreaded.py, I can still fix the problem with
the below patch:

- from lldbtest import *
+ from lldbsuite.test.lldbtest import *

because now we're referencing the module that has already been imported.
This is the "correct" way to do it, so if we tighten up sys.path, nobody
should be able to make this mistake again.

On Mon, Nov 2, 2015 at 4:32 PM Zachary Turner  wrote:

> I think what is happening is that when we go through unittest2, the
> package link is being broken.
>
> Inside dotest.py : __package__ = lldbsuite.test
> Inside unittest2.loadTestsFromName : __package__ = unittest2
> Inside TestMultithreaded.py : __package__ = None
>
> Restoring the link by writing
>
> __package__ = "lldbsuite.test"
>
> at the top of TestMultithreaded.py seems to fix the problem, although that
> really bothersome to have to do that in every single file.  I'm still
> trying to figure out the proper fix.
>
> On Mon, Nov 2, 2015 at 3:41 PM Pavel Labath via lldb-commits <
> lldb-commits@lists.llvm.org> wrote:
>
>> Author: labath
>> Date: Mon Nov  2 17:39:09 2015
>> New Revision: 251862
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=251862&view=rev
>> Log:
>> Revert "Remove the __import__ hack of lldbtest_config."
>>
>> The hack still seems to be necessary. Putting it back in until we figure
>> out why.
>>
>> Modified:
>> lldb/trunk/packages/Python/lldbsuite/test/dotest.py
>>
>> Modified: lldb/trunk/packages/Python/lldbsuite/test/dotest.py
>> URL:
>> http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/dotest.py?rev=251862&r1=251861&r2=251862&view=diff
>>
>> ==
>> --- lldb/trunk/packages/Python/lldbsuite/test/dotest.py (original)
>> +++ lldb/trunk/packages/Python/lldbsuite/test/dotest.py Mon Nov  2
>> 17:39:09 2015
>> @@ -19,11 +19,14 @@ for available options.
>>  """
>>
>>  from __future__ import print_function
>> +# this module needs to have global visibility, otherwise test cases
>> +# will import it anew in their local namespace, essentially losing access
>> +# to all the configuration data
>> +globals()['lldbtest_config'] = __import__('lldbtest_config')
>>
>>  import use_lldb_suite
>> -import lldbsuite
>>
>> -import lldbtest_config
>> +import lldbsuite
>>
>>  import atexit
>>  import commands
>>
>>
>> ___
>> 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] r251862 - Revert "Remove the import hack of lldbtest_config."

2015-11-02 Thread Pavel Labath via lldb-commits

Good news Zachary, I'm glad we finally got to the bottom of this.

I've tested your proposed changes locally, and on our buildbot (which,
for whatever reason, did not like Enrico's workaround). Could we get
this in as soon as possible?

cheers,
pl


On 2 November 2015 at 16:43, Zachary Turner  wrote:
> +Enrico Granata
>
>
> On Mon, Nov 2, 2015 at 4:42 PM Zachary Turner  wrote:
>>
>> Ok, I think I figured out the root of all the problems.
>>
>> First, in setupSysPath we have this:
>>
>> sys.path.insert(0, scriptPath)
>>
>> This basically adds `lldb/packages/Python/lldbsuite/test` to sys.path.
>>
>> Then, in the individual tests we write this:
>>
>> from lldbtest import *
>>
>> It finds lldbtest at the above path, and imports it.  But this is *not*
>> the same copy of lldbtest that has already been imported, because that copy
>> was imported as a member of the lldbsuite.test package.  So now we have this
>> module in sys.modules twice.  Once as lldbtest, found by looking in
>> lldbsuite/test since it was in sys.path.  And once as
>> lldbsuite.test.lldbtest, found because lldbsuite was in sys.path, using
>> subpackage resolution.
>>
>> I think the fix for all of these problems is to *remove* scriptPath from
>> sys.path.  We shouldn't be mucking with sys.path for stuff in our own test
>> suite.  We should resolve the references explicitly with subpackage
>> references.  For example, even if I don't write __package__ =
>> "lldbsuite.test" in TestMultithreaded.py, I can still fix the problem with
>> the below patch:
>>
>> - from lldbtest import *
>> + from lldbsuite.test.lldbtest import *
>>
>> because now we're referencing the module that has already been imported.
>> This is the "correct" way to do it, so if we tighten up sys.path, nobody
>> should be able to make this mistake again.
>>
>> On Mon, Nov 2, 2015 at 4:32 PM Zachary Turner  wrote:
>>>
>>> I think what is happening is that when we go through unittest2, the
>>> package link is being broken.
>>>
>>> Inside dotest.py : __package__ = lldbsuite.test
>>> Inside unittest2.loadTestsFromName : __package__ = unittest2
>>> Inside TestMultithreaded.py : __package__ = None
>>>
>>> Restoring the link by writing
>>>
>>> __package__ = "lldbsuite.test"
>>>
>>> at the top of TestMultithreaded.py seems to fix the problem, although
>>> that really bothersome to have to do that in every single file.  I'm still
>>> trying to figure out the proper fix.
>>>
>>> On Mon, Nov 2, 2015 at 3:41 PM Pavel Labath via lldb-commits
>>>  wrote:

 Author: labath
 Date: Mon Nov  2 17:39:09 2015
 New Revision: 251862

 URL: http://llvm.org/viewvc/llvm-project?rev=251862&view=rev
 Log:
 Revert "Remove the __import__ hack of lldbtest_config."

 The hack still seems to be necessary. Putting it back in until we figure
 out why.

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

 Modified: lldb/trunk/packages/Python/lldbsuite/test/dotest.py
 URL:
 http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/dotest.py?rev=251862&r1=251861&r2=251862&view=diff

 ==
 --- lldb/trunk/packages/Python/lldbsuite/test/dotest.py (original)
 +++ lldb/trunk/packages/Python/lldbsuite/test/dotest.py Mon Nov  2
 17:39:09 2015
 @@ -19,11 +19,14 @@ for available options.
  """

  from __future__ import print_function
 +# this module needs to have global visibility, otherwise test cases
 +# will import it anew in their local namespace, essentially losing
 access
 +# to all the configuration data
 +globals()['lldbtest_config'] = __import__('lldbtest_config')

  import use_lldb_suite
 -import lldbsuite

 -import lldbtest_config
 +import lldbsuite

  import atexit
  import commands


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

[Lldb-commits] [lldb] r251879 - Provide ADB port forwarding support for abstract sockets.

2015-11-02 Thread Oleksiy Vyalov via lldb-commits

Author: ovyalov
Date: Mon Nov  2 19:37:01 2015
New Revision: 251879

URL: http://llvm.org/viewvc/llvm-project?rev=251879&view=rev
Log:
Provide ADB port forwarding support for abstract sockets.

http://reviews.llvm.org/D14262


Modified:
lldb/trunk/include/lldb/Host/posix/ConnectionFileDescriptorPosix.h
lldb/trunk/source/Host/posix/ConnectionFileDescriptorPosix.cpp
lldb/trunk/source/Plugins/Platform/Android/AdbClient.cpp
lldb/trunk/source/Plugins/Platform/Android/AdbClient.h

lldb/trunk/source/Plugins/Platform/Android/PlatformAndroidRemoteGDBServer.cpp
lldb/trunk/source/Plugins/Platform/Android/PlatformAndroidRemoteGDBServer.h

Modified: lldb/trunk/include/lldb/Host/posix/ConnectionFileDescriptorPosix.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Host/posix/ConnectionFileDescriptorPosix.h?rev=251879&r1=251878&r2=251879&view=diff
==
--- lldb/trunk/include/lldb/Host/posix/ConnectionFileDescriptorPosix.h 
(original)
+++ lldb/trunk/include/lldb/Host/posix/ConnectionFileDescriptorPosix.h Mon Nov  
2 19:37:01 2015
@@ -34,6 +34,17 @@ class SocketAddress;
 class ConnectionFileDescriptor : public Connection
 {
   public:
+static const char* LISTEN_SCHEME;
+static const char* ACCEPT_SCHEME;
+static const char* UNIX_ACCEPT_SCHEME;
+static const char* CONNECT_SCHEME;
+static const char* TCP_CONNECT_SCHEME;
+static const char* UDP_SCHEME;
+static const char* UNIX_CONNECT_SCHEME;
+static const char* UNIX_ABSTRACT_CONNECT_SCHEME;
+static const char* FD_SCHEME;
+static const char* FILE_SCHEME;
+
 ConnectionFileDescriptor(bool child_processes_inherit = false);
 
 ConnectionFileDescriptor(int fd, bool owns_fd);

Modified: lldb/trunk/source/Host/posix/ConnectionFileDescriptorPosix.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Host/posix/ConnectionFileDescriptorPosix.cpp?rev=251879&r1=251878&r2=251879&view=diff
==
--- lldb/trunk/source/Host/posix/ConnectionFileDescriptorPosix.cpp (original)
+++ lldb/trunk/source/Host/posix/ConnectionFileDescriptorPosix.cpp Mon Nov  2 
19:37:01 2015
@@ -53,6 +53,31 @@
 using namespace lldb;
 using namespace lldb_private;
 
+const char* ConnectionFileDescriptor::LISTEN_SCHEME = "listen";
+const char* ConnectionFileDescriptor::ACCEPT_SCHEME = "accept";
+const char* ConnectionFileDescriptor::UNIX_ACCEPT_SCHEME = "unix-accept";
+const char* ConnectionFileDescriptor::CONNECT_SCHEME = "connect";
+const char* ConnectionFileDescriptor::TCP_CONNECT_SCHEME = "tcp-connect";
+const char* ConnectionFileDescriptor::UDP_SCHEME = "udp";
+const char* ConnectionFileDescriptor::UNIX_CONNECT_SCHEME = "unix-connect";
+const char* ConnectionFileDescriptor::UNIX_ABSTRACT_CONNECT_SCHEME = 
"unix-abstract-connect";
+const char* ConnectionFileDescriptor::FD_SCHEME = "fd";
+const char* ConnectionFileDescriptor::FILE_SCHEME = "file";
+
+namespace {
+
+const char*
+GetURLAddress(const char *url, const char *scheme)
+{
+const auto prefix = std::string(scheme) + "://";
+if (strstr(url, prefix.c_str()) != url)
+return nullptr;
+
+return url + prefix.size();
+}
+
+}
+
 ConnectionFileDescriptor::ConnectionFileDescriptor(bool 
child_processes_inherit)
 : Connection()
 , m_pipe()
@@ -154,51 +179,51 @@ ConnectionFileDescriptor::Connect(const
 
 if (s && s[0])
 {
-if (strstr(s, "listen://") == s)
+const char *addr = nullptr;
+if ((addr = GetURLAddress(s, LISTEN_SCHEME)))
 {
 // listen://HOST:PORT
-return SocketListenAndAccept(s + strlen("listen://"), error_ptr);
+return SocketListenAndAccept(addr, error_ptr);
 }
-else if (strstr(s, "accept://") == s)
+else if ((addr = GetURLAddress(s, ACCEPT_SCHEME)))
 {
 // unix://SOCKNAME
-return NamedSocketAccept(s + strlen("accept://"), error_ptr);
+return NamedSocketAccept(addr, error_ptr);
 }
-else if (strstr(s, "unix-accept://") == s)
+else if ((addr = GetURLAddress(s, UNIX_ACCEPT_SCHEME)))
 {
 // unix://SOCKNAME
-return NamedSocketAccept(s + strlen("unix-accept://"), error_ptr);
+return NamedSocketAccept(addr, error_ptr);
 }
-else if (strstr(s, "connect://") == s)
+else if ((addr = GetURLAddress(s, CONNECT_SCHEME)))
 {
-return ConnectTCP(s + strlen("connect://"), error_ptr);
+return ConnectTCP(addr, error_ptr);
 }
-else if (strstr(s, "tcp-connect://") == s)
+else if ((addr = GetURLAddress(s, TCP_CONNECT_SCHEME)))
 {
-return ConnectTCP(s + strlen("tcp-connect://"), error_ptr);
+return ConnectTCP(addr, error_ptr);
 }
-else if (strstr(s, "udp://") == s)
+else if ((a

Re: [Lldb-commits] [PATCH] D14262: Provide ADB port forwarding support for abstract sockets

2015-11-02 Thread Oleksiy Vyalov via lldb-commits

ovyalov closed this revision.
ovyalov added a comment.

Files:

  /lldb/trunk/include/lldb/Host/posix/ConnectionFileDescriptorPosix.h
  /lldb/trunk/source/Host/posix/ConnectionFileDescriptorPosix.cpp
  /lldb/trunk/source/Plugins/Platform/Android/AdbClient.cpp
  /lldb/trunk/source/Plugins/Platform/Android/AdbClient.h
  /lldb/trunk/source/Plugins/Platform/Android/PlatformAndroidRemoteGDBServer.cpp
  /lldb/trunk/source/Plugins/Platform/Android/PlatformAndroidRemoteGDBServer.h

Users:

  ovyalov (Author)

http://reviews.llvm.org/rL251879


http://reviews.llvm.org/D14262



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

Re: [Lldb-commits] [lldb] r251862 - Revert "Remove the import hack of lldbtest_config."

2015-11-02 Thread Zachary Turner via lldb-commits

Yes, but it's a VERY large mechanical code change.  For example, everywhere
we were doign something like this:

import lldbutil

from one of the tests, we have to rewrite this as:

import lldbsuite.test.lldbutil as lldbutil

And we have to catch all the different ways of importing, like:

from lldbutil import x
import lldb, lldbutil

and there are about 20 or 30 modules other than lldbutil I have to fix up
as well.

I'm in the process of doing this right now, and I've almost got all the
instances found and fixed.  But I have to leave in about 15 minutes.  If I
don't get it in tonight, it will be in tomorrow morning first thing.

On Mon, Nov 2, 2015 at 5:37 PM Pavel Labath  wrote:

> Good news Zachary, I'm glad we finally got to the bottom of this.
>
> I've tested your proposed changes locally, and on our buildbot (which,
> for whatever reason, did not like Enrico's workaround). Could we get
> this in as soon as possible?
>
> cheers,
> pl
>
>
> On 2 November 2015 at 16:43, Zachary Turner  wrote:
> > +Enrico Granata
> >
> >
> > On Mon, Nov 2, 2015 at 4:42 PM Zachary Turner 
> wrote:
> >>
> >> Ok, I think I figured out the root of all the problems.
> >>
> >> First, in setupSysPath we have this:
> >>
> >> sys.path.insert(0, scriptPath)
> >>
> >> This basically adds `lldb/packages/Python/lldbsuite/test` to sys.path.
> >>
> >> Then, in the individual tests we write this:
> >>
> >> from lldbtest import *
> >>
> >> It finds lldbtest at the above path, and imports it.  But this is *not*
> >> the same copy of lldbtest that has already been imported, because that
> copy
> >> was imported as a member of the lldbsuite.test package.  So now we have
> this
> >> module in sys.modules twice.  Once as lldbtest, found by looking in
> >> lldbsuite/test since it was in sys.path.  And once as
> >> lldbsuite.test.lldbtest, found because lldbsuite was in sys.path, using
> >> subpackage resolution.
> >>
> >> I think the fix for all of these problems is to *remove* scriptPath from
> >> sys.path.  We shouldn't be mucking with sys.path for stuff in our own
> test
> >> suite.  We should resolve the references explicitly with subpackage
> >> references.  For example, even if I don't write __package__ =
> >> "lldbsuite.test" in TestMultithreaded.py, I can still fix the problem
> with
> >> the below patch:
> >>
> >> - from lldbtest import *
> >> + from lldbsuite.test.lldbtest import *
> >>
> >> because now we're referencing the module that has already been imported.
> >> This is the "correct" way to do it, so if we tighten up sys.path, nobody
> >> should be able to make this mistake again.
> >>
> >> On Mon, Nov 2, 2015 at 4:32 PM Zachary Turner 
> wrote:
> >>>
> >>> I think what is happening is that when we go through unittest2, the
> >>> package link is being broken.
> >>>
> >>> Inside dotest.py : __package__ = lldbsuite.test
> >>> Inside unittest2.loadTestsFromName : __package__ = unittest2
> >>> Inside TestMultithreaded.py : __package__ = None
> >>>
> >>> Restoring the link by writing
> >>>
> >>> __package__ = "lldbsuite.test"
> >>>
> >>> at the top of TestMultithreaded.py seems to fix the problem, although
> >>> that really bothersome to have to do that in every single file.  I'm
> still
> >>> trying to figure out the proper fix.
> >>>
> >>> On Mon, Nov 2, 2015 at 3:41 PM Pavel Labath via lldb-commits
> >>>  wrote:
> 
>  Author: labath
>  Date: Mon Nov  2 17:39:09 2015
>  New Revision: 251862
> 
>  URL: http://llvm.org/viewvc/llvm-project?rev=251862&view=rev
>  Log:
>  Revert "Remove the __import__ hack of lldbtest_config."
> 
>  The hack still seems to be necessary. Putting it back in until we
> figure
>  out why.
> 
>  Modified:
>  lldb/trunk/packages/Python/lldbsuite/test/dotest.py
> 
>  Modified: lldb/trunk/packages/Python/lldbsuite/test/dotest.py
>  URL:
> 
> http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/dotest.py?rev=251862&r1=251861&r2=251862&view=diff
> 
> 
> ==
>  --- lldb/trunk/packages/Python/lldbsuite/test/dotest.py (original)
>  +++ lldb/trunk/packages/Python/lldbsuite/test/dotest.py Mon Nov  2
>  17:39:09 2015
>  @@ -19,11 +19,14 @@ for available options.
>   """
> 
>   from __future__ import print_function
>  +# this module needs to have global visibility, otherwise test cases
>  +# will import it anew in their local namespace, essentially losing
>  access
>  +# to all the configuration data
>  +globals()['lldbtest_config'] = __import__('lldbtest_config')
> 
>   import use_lldb_suite
>  -import lldbsuite
> 
>  -import lldbtest_config
>  +import lldbsuite
> 
>   import atexit
>   import commands
> 
> 
>  ___
>  lldb-commits mailing list
>  lldb-commits@lists.llvm.org
>  http://l

[Lldb-commits] [lldb] r251880 - Fix usage of removed decorator in TestExpressions

2015-11-02 Thread Pavel Labath via lldb-commits

Author: labath
Date: Mon Nov  2 19:39:03 2015
New Revision: 251880

URL: http://llvm.org/viewvc/llvm-project?rev=251880&view=rev
Log:
Fix usage of removed decorator in TestExpressions

Modified:

lldb/trunk/packages/Python/lldbsuite/test/lang/go/expressions/TestExpressions.py

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/lang/go/expressions/TestExpressions.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/lang/go/expressions/TestExpressions.py?rev=251880&r1=251879&r2=251880&view=diff
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/lang/go/expressions/TestExpressions.py
 (original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/lang/go/expressions/TestExpressions.py
 Mon Nov  2 19:39:03 2015
@@ -10,7 +10,7 @@ class TestGoUserExpression(TestBase):
 
 mydir = TestBase.compute_mydir(__file__)
 
-@python_api_test
+@add_test_categories(['pyapi'])
 @skipIfRemote # Not remote test suit ready
 @skipUnlessGoInstalled
 def test_with_dsym_and_python_api(self):


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

Re: [Lldb-commits] [lldb] r251862 - Revert "Remove the import hack of lldbtest_config."

2015-11-02 Thread Zachary Turner via lldb-commits

As an alternative, since this is breaking your buildbot, I can check in the
lion's share of the work (which should fix about 95% of the fixups), and
you can do any remaining ones that pop up on the linux buildbot after I'm
gone.  Do you prefer that?



On Mon, Nov 2, 2015 at 5:40 PM Zachary Turner  wrote:

> Yes, but it's a VERY large mechanical code change.  For example,
> everywhere we were doign something like this:
>
> import lldbutil
>
> from one of the tests, we have to rewrite this as:
>
> import lldbsuite.test.lldbutil as lldbutil
>
> And we have to catch all the different ways of importing, like:
>
> from lldbutil import x
> import lldb, lldbutil
>
> and there are about 20 or 30 modules other than lldbutil I have to fix up
> as well.
>
> I'm in the process of doing this right now, and I've almost got all the
> instances found and fixed.  But I have to leave in about 15 minutes.  If I
> don't get it in tonight, it will be in tomorrow morning first thing.
>
> On Mon, Nov 2, 2015 at 5:37 PM Pavel Labath  wrote:
>
>> Good news Zachary, I'm glad we finally got to the bottom of this.
>>
>> I've tested your proposed changes locally, and on our buildbot (which,
>> for whatever reason, did not like Enrico's workaround). Could we get
>> this in as soon as possible?
>>
>> cheers,
>> pl
>>
>>
>> On 2 November 2015 at 16:43, Zachary Turner  wrote:
>> > +Enrico Granata
>> >
>> >
>> > On Mon, Nov 2, 2015 at 4:42 PM Zachary Turner 
>> wrote:
>> >>
>> >> Ok, I think I figured out the root of all the problems.
>> >>
>> >> First, in setupSysPath we have this:
>> >>
>> >> sys.path.insert(0, scriptPath)
>> >>
>> >> This basically adds `lldb/packages/Python/lldbsuite/test` to sys.path.
>> >>
>> >> Then, in the individual tests we write this:
>> >>
>> >> from lldbtest import *
>> >>
>> >> It finds lldbtest at the above path, and imports it.  But this is *not*
>> >> the same copy of lldbtest that has already been imported, because that
>> copy
>> >> was imported as a member of the lldbsuite.test package.  So now we
>> have this
>> >> module in sys.modules twice.  Once as lldbtest, found by looking in
>> >> lldbsuite/test since it was in sys.path.  And once as
>> >> lldbsuite.test.lldbtest, found because lldbsuite was in sys.path, using
>> >> subpackage resolution.
>> >>
>> >> I think the fix for all of these problems is to *remove* scriptPath
>> from
>> >> sys.path.  We shouldn't be mucking with sys.path for stuff in our own
>> test
>> >> suite.  We should resolve the references explicitly with subpackage
>> >> references.  For example, even if I don't write __package__ =
>> >> "lldbsuite.test" in TestMultithreaded.py, I can still fix the problem
>> with
>> >> the below patch:
>> >>
>> >> - from lldbtest import *
>> >> + from lldbsuite.test.lldbtest import *
>> >>
>> >> because now we're referencing the module that has already been
>> imported.
>> >> This is the "correct" way to do it, so if we tighten up sys.path,
>> nobody
>> >> should be able to make this mistake again.
>> >>
>> >> On Mon, Nov 2, 2015 at 4:32 PM Zachary Turner 
>> wrote:
>> >>>
>> >>> I think what is happening is that when we go through unittest2, the
>> >>> package link is being broken.
>> >>>
>> >>> Inside dotest.py : __package__ = lldbsuite.test
>> >>> Inside unittest2.loadTestsFromName : __package__ = unittest2
>> >>> Inside TestMultithreaded.py : __package__ = None
>> >>>
>> >>> Restoring the link by writing
>> >>>
>> >>> __package__ = "lldbsuite.test"
>> >>>
>> >>> at the top of TestMultithreaded.py seems to fix the problem, although
>> >>> that really bothersome to have to do that in every single file.  I'm
>> still
>> >>> trying to figure out the proper fix.
>> >>>
>> >>> On Mon, Nov 2, 2015 at 3:41 PM Pavel Labath via lldb-commits
>> >>>  wrote:
>> 
>>  Author: labath
>>  Date: Mon Nov  2 17:39:09 2015
>>  New Revision: 251862
>> 
>>  URL: http://llvm.org/viewvc/llvm-project?rev=251862&view=rev
>>  Log:
>>  Revert "Remove the __import__ hack of lldbtest_config."
>> 
>>  The hack still seems to be necessary. Putting it back in until we
>> figure
>>  out why.
>> 
>>  Modified:
>>  lldb/trunk/packages/Python/lldbsuite/test/dotest.py
>> 
>>  Modified: lldb/trunk/packages/Python/lldbsuite/test/dotest.py
>>  URL:
>> 
>> http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/dotest.py?rev=251862&r1=251861&r2=251862&view=diff
>> 
>> 
>> ==
>>  --- lldb/trunk/packages/Python/lldbsuite/test/dotest.py (original)
>>  +++ lldb/trunk/packages/Python/lldbsuite/test/dotest.py Mon Nov  2
>>  17:39:09 2015
>>  @@ -19,11 +19,14 @@ for available options.
>>   """
>> 
>>   from __future__ import print_function
>>  +# this module needs to have global visibility, otherwise test cases
>>  +# will import it anew in their local namespace, essentiall

[Lldb-commits] [lldb] r251882 - Emit an error message if the current working directory does not exist when the user is trying to launch argdumper to do shell expansion

2015-11-02 Thread Enrico Granata via lldb-commits

Author: enrico
Date: Mon Nov  2 19:47:19 2015
New Revision: 251882

URL: http://llvm.org/viewvc/llvm-project?rev=251882&view=rev
Log:
Emit an error message if the current working directory does not exist when the 
user is trying to launch argdumper to do shell expansion

Modified:
lldb/trunk/source/Host/macosx/Host.mm

Modified: lldb/trunk/source/Host/macosx/Host.mm
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Host/macosx/Host.mm?rev=251882&r1=251881&r2=251882&view=diff
==
--- lldb/trunk/source/Host/macosx/Host.mm (original)
+++ lldb/trunk/source/Host/macosx/Host.mm Mon Nov  2 19:47:19 2015
@@ -1371,7 +1371,13 @@ Host::ShellExpandArguments (ProcessLaunc
 
 int status;
 std::string output;
-RunShellCommand(expand_command, launch_info.GetWorkingDirectory(), 
&status, nullptr, &output, 10);
+FileSpec cwd(launch_info.GetWorkingDirectory());
+if (!cwd.Exists())
+{
+error.SetErrorStringWithFormat("cwd does not exist; cannot launch 
with shell argument expansion");
+return error;
+}
+RunShellCommand(expand_command, cwd, &status, nullptr, &output, 10);
 
 if (status != 0)
 {


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

[Lldb-commits] [lldb] r251887 - Add the ability to pass an EvaluateExpressionOptions when you make a UserExpression. This

2015-11-02 Thread Jim Ingham via lldb-commits

Author: jingham
Date: Mon Nov  2 20:11:24 2015
New Revision: 251887

URL: http://llvm.org/viewvc/llvm-project?rev=251887&view=rev
Log:
Add the ability to pass an EvaluateExpressionOptions when you make a 
UserExpression.  This
isn't used in this commit but will be in a future commit.

Modified:
lldb/trunk/include/lldb/Expression/Expression.h
lldb/trunk/include/lldb/Expression/LLVMUserExpression.h
lldb/trunk/include/lldb/Expression/UserExpression.h
lldb/trunk/include/lldb/Symbol/ClangASTContext.h
lldb/trunk/include/lldb/Symbol/GoASTContext.h
lldb/trunk/include/lldb/Symbol/TypeSystem.h
lldb/trunk/include/lldb/Target/Target.h
lldb/trunk/source/Breakpoint/BreakpointLocation.cpp
lldb/trunk/source/Breakpoint/Watchpoint.cpp
lldb/trunk/source/Expression/LLVMUserExpression.cpp
lldb/trunk/source/Expression/UserExpression.cpp
lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangUserExpression.cpp
lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangUserExpression.h
lldb/trunk/source/Plugins/ExpressionParser/Go/GoUserExpression.cpp
lldb/trunk/source/Plugins/ExpressionParser/Go/GoUserExpression.h
lldb/trunk/source/Symbol/ClangASTContext.cpp
lldb/trunk/source/Symbol/GoASTContext.cpp
lldb/trunk/source/Target/Target.cpp

Modified: lldb/trunk/include/lldb/Expression/Expression.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Expression/Expression.h?rev=251887&r1=251886&r2=251887&view=diff
==
--- lldb/trunk/include/lldb/Expression/Expression.h (original)
+++ lldb/trunk/include/lldb/Expression/Expression.h Mon Nov  2 20:11:24 2015
@@ -109,6 +109,8 @@ public:
 virtual bool
 NeedsVariableResolution () = 0;
 
+virtual EvaluateExpressionOptions *GetOptions() { return nullptr; };
+
 //--
 /// Return the address of the function's JIT-compiled code, or
 /// LLDB_INVALID_ADDRESS if the function is not JIT compiled

Modified: lldb/trunk/include/lldb/Expression/LLVMUserExpression.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Expression/LLVMUserExpression.h?rev=251887&r1=251886&r2=251887&view=diff
==
--- lldb/trunk/include/lldb/Expression/LLVMUserExpression.h (original)
+++ lldb/trunk/include/lldb/Expression/LLVMUserExpression.h Mon Nov  2 20:11:24 
2015
@@ -35,15 +35,23 @@ namespace lldb_private
 class LLVMUserExpression : public UserExpression
 {
   public:
-LLVMUserExpression(ExecutionContextScope &exe_scope, const char *expr, 
const char *expr_prefix,
-   lldb::LanguageType language, ResultType desired_type);
+LLVMUserExpression(ExecutionContextScope &exe_scope,
+   const char *expr,
+   const char *expr_prefix,
+   lldb::LanguageType language,
+   ResultType desired_type,
+   const EvaluateExpressionOptions &options);
 ~LLVMUserExpression() override;
 
-lldb::ExpressionResults Execute(Stream &error_stream, ExecutionContext 
&exe_ctx,
-const EvaluateExpressionOptions &options, 
lldb::UserExpressionSP &shared_ptr_to_me,
+lldb::ExpressionResults Execute(Stream &error_stream,
+ExecutionContext &exe_ctx,
+const EvaluateExpressionOptions &options,
+lldb::UserExpressionSP &shared_ptr_to_me,
 lldb::ExpressionVariableSP &result) 
override;
 
-bool FinalizeJITExecution(Stream &error_stream, ExecutionContext &exe_ctx, 
lldb::ExpressionVariableSP &result,
+bool FinalizeJITExecution(Stream &error_stream,
+  ExecutionContext &exe_ctx,
+  lldb::ExpressionVariableSP &result,
   lldb::addr_t function_stack_bottom = 
LLDB_INVALID_ADDRESS,
   lldb::addr_t function_stack_top = 
LLDB_INVALID_ADDRESS) override;
 

Modified: lldb/trunk/include/lldb/Expression/UserExpression.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Expression/UserExpression.h?rev=251887&r1=251886&r2=251887&view=diff
==
--- lldb/trunk/include/lldb/Expression/UserExpression.h (original)
+++ lldb/trunk/include/lldb/Expression/UserExpression.h Mon Nov  2 20:11:24 2015
@@ -24,6 +24,7 @@
 #include "lldb/Expression/Expression.h"
 #include "lldb/Expression/Materializer.h"
 #include "lldb/Target/ExecutionContext.h"
+#include "lldb/Target/Target.h"
 
 namespace lldb_private
 {
@@ -67,7 +68,8 @@ public:
 const char *expr,
 const char *expr_prefix,
 lldb::Lang

[Lldb-commits] [lldb] r251889 - Do not try to copy host memory from address 0

2015-11-02 Thread Enrico Granata via lldb-commits

Author: enrico
Date: Mon Nov  2 20:34:43 2015
New Revision: 251889

URL: http://llvm.org/viewvc/llvm-project?rev=251889&view=rev
Log:
Do not try to copy host memory from address 0

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

Modified: lldb/trunk/source/Core/ValueObject.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Core/ValueObject.cpp?rev=251889&r1=251888&r2=251889&view=diff
==
--- lldb/trunk/source/Core/ValueObject.cpp (original)
+++ lldb/trunk/source/Core/ValueObject.cpp Mon Nov  2 20:34:43 2015
@@ -1105,7 +1105,7 @@ ValueObject::GetPointeeData (DataExtract
 {
 size_t bytes_read = std::min(max_bytes - 
offset, bytes);
 addr = 
m_value.GetScalar().ULongLong(LLDB_INVALID_ADDRESS);
-if (addr == LLDB_INVALID_ADDRESS)
+if (addr == 0 || addr == LLDB_INVALID_ADDRESS)
 break;
 heap_buf_ptr->CopyData((uint8_t*)(addr + offset), 
bytes_read);
 data.SetData(data_sp);


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

Re: [Lldb-commits] [lldb] r251886 - Tighten up sys.path, and use absolute imports everywhere.

2015-11-02 Thread Zachary Turner via lldb-commits

On Mon, Nov 2, 2015 at 10:02 PM Todd Fiala  wrote:

> Do you have a script you used to tweak these?
>
> (We have a ton of stuff broken internally on this that I need to fix up).
>
> We're starting to need to do quite a bit of extra typing for the package
> structure :-/
>

No, I just used a recursive regex replacement.  I had to find a few
different patterns:

from X import foo # from lldbsuite.test.X import foo
import X   # import lldbsuite.test.X as X
import foo, X   #import foo\nimport lldbsuite.test.X as X

and I handled each one on a case-by-case basis.

Luckily the extra typing only comes at the import site.  If you use the
syntax I suggested in #2 and #3 above (import lldbsuite.test.X as X) then
the syntax at any sites where you use a definition from inside the module
are the same.

I was a little bit annoyed at the extra typing myself, but when I look into
it, it's considered a "feature".  See PEP 0328 - Imports: Multi-Line and
Absolute/Relative  and as far as
I can tell the way we were doing things before was considered "wrong"  :(

How much of a problem is this going to be on your side?  Is there an
equally "good" solution that doesn't require so much fixup on your side?

the only fixup I encountered was in individual test cases and test suites
(i.e. files that are loaded by unittest2).  Does this account for all the
test failures on your side as well, or is there something else going on I
missed?
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [lldb] r251886 - Tighten up sys.path, and use absolute imports everywhere.

2015-11-02 Thread Zachary Turner via lldb-commits

Also as far as I can tell, X has to be in the following set: [lldbutil,
lldbtest, lldbinline, lldbbench].  In theory there are other possibilities
(any .py file that is in packages/Python/lldbsuite/test is fair game) but I
don't think I encountered any aside from those 4.

On Mon, Nov 2, 2015 at 10:12 PM Zachary Turner  wrote:

> On Mon, Nov 2, 2015 at 10:02 PM Todd Fiala  wrote:
>
>> Do you have a script you used to tweak these?
>>
>> (We have a ton of stuff broken internally on this that I need to fix up).
>>
>> We're starting to need to do quite a bit of extra typing for the package
>> structure :-/
>>
>
> No, I just used a recursive regex replacement.  I had to find a few
> different patterns:
>
> from X import foo # from lldbsuite.test.X import foo
> import X   # import lldbsuite.test.X as X
> import foo, X   #import foo\nimport lldbsuite.test.X as X
>
> and I handled each one on a case-by-case basis.
>
> Luckily the extra typing only comes at the import site.  If you use the
> syntax I suggested in #2 and #3 above (import lldbsuite.test.X as X) then
> the syntax at any sites where you use a definition from inside the module
> are the same.
>
> I was a little bit annoyed at the extra typing myself, but when I look
> into it, it's considered a "feature".  See PEP 0328 - Imports: Multi-Line
> and Absolute/Relative  and as
> far as I can tell the way we were doing things before was considered
> "wrong"  :(
>
> How much of a problem is this going to be on your side?  Is there an
> equally "good" solution that doesn't require so much fixup on your side?
>
> the only fixup I encountered was in individual test cases and test suites
> (i.e. files that are loaded by unittest2).  Does this account for all the
> test failures on your side as well, or is there something else going on I
> missed?
>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [lldb] r251886 - Tighten up sys.path, and use absolute imports everywhere.

2015-11-02 Thread Zachary Turner via lldb-commits

Also, one last thing.  The reason this is probably wreaking havoc on your
stuff internally is because I removed scriptDir from sys.path (diff the
changes of dotest.py to see).  I think it should stay removed upstream
(mucking with sys.path so you can import from a parent directory is a bad
thing to do), but if you have a fork it might be worth putting it back into
the fork temporarily to get things green?  Note that technically stuff will
still be "broken" the same way it was before (importing a second copy of a
module), but that only ever leads to an actual problem fi you rely on
global state from the module - which upstream anyway we were only ever
doing for lldbtest_config.

If worse comes to worse we can revert, but if so I think somehow we should
figure out a strategy for getting this back in, because it definitely seems
like "the right way"

On Mon, Nov 2, 2015 at 10:14 PM Zachary Turner  wrote:

> Also as far as I can tell, X has to be in the following set: [lldbutil,
> lldbtest, lldbinline, lldbbench].  In theory there are other possibilities
> (any .py file that is in packages/Python/lldbsuite/test is fair game) but I
> don't think I encountered any aside from those 4.
>
> On Mon, Nov 2, 2015 at 10:12 PM Zachary Turner  wrote:
>
>> On Mon, Nov 2, 2015 at 10:02 PM Todd Fiala  wrote:
>>
>>> Do you have a script you used to tweak these?
>>>
>>> (We have a ton of stuff broken internally on this that I need to fix up).
>>>
>>> We're starting to need to do quite a bit of extra typing for the package
>>> structure :-/
>>>
>>
>> No, I just used a recursive regex replacement.  I had to find a few
>> different patterns:
>>
>> from X import foo # from lldbsuite.test.X import foo
>> import X   # import lldbsuite.test.X as X
>> import foo, X   #import foo\nimport lldbsuite.test.X as X
>>
>> and I handled each one on a case-by-case basis.
>>
>> Luckily the extra typing only comes at the import site.  If you use the
>> syntax I suggested in #2 and #3 above (import lldbsuite.test.X as X) then
>> the syntax at any sites where you use a definition from inside the module
>> are the same.
>>
>> I was a little bit annoyed at the extra typing myself, but when I look
>> into it, it's considered a "feature".  See PEP 0328 - Imports:
>> Multi-Line and Absolute/Relative
>>  and as far as I can tell the
>> way we were doing things before was considered "wrong"  :(
>>
>> How much of a problem is this going to be on your side?  Is there an
>> equally "good" solution that doesn't require so much fixup on your side?
>>
>> the only fixup I encountered was in individual test cases and test suites
>> (i.e. files that are loaded by unittest2).  Does this account for all the
>> test failures on your side as well, or is there something else going on I
>> missed?
>>
>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [lldb] r251886 - Tighten up sys.path, and use absolute imports everywhere.

2015-11-02 Thread Todd Fiala via lldb-commits

On Mon, Nov 2, 2015 at 10:12 PM, Zachary Turner  wrote:

> On Mon, Nov 2, 2015 at 10:02 PM Todd Fiala  wrote:
>
>> Do you have a script you used to tweak these?
>>
>> (We have a ton of stuff broken internally on this that I need to fix up).
>>
>> We're starting to need to do quite a bit of extra typing for the package
>> structure :-/
>>
>
> No, I just used a recursive regex replacement.  I had to find a few
> different patterns:
>
> from X import foo # from lldbsuite.test.X import foo
> import X   # import lldbsuite.test.X as X
> import foo, X   #import foo\nimport lldbsuite.test.X as X
>
> and I handled each one on a case-by-case basis.
>
>
Okay, that sounds reasonable, thanks.


> Luckily the extra typing only comes at the import site.  If you use the
> syntax I suggested in #2 and #3 above (import lldbsuite.test.X as X) then
> the syntax at any sites where you use a definition from inside the module
> are the same.
>
> I was a little bit annoyed at the extra typing myself, but when I look
> into it, it's considered a "feature".  See PEP 0328 - Imports: Multi-Line
> and Absolute/Relative  and as
> far as I can tell the way we were doing things before was considered
> "wrong"  :(
>
>
Heh.  Well, coming out of the gate with broken backward compatibility from
2.x to 3.x was considered "right" ( :-P ), so I'm not sure how much weight
I'd put in the rulings from on high...


> How much of a problem is this going to be on your side?  Is there an
> equally "good" solution that doesn't require so much fixup on your side?
>
>
No big deal at all.  I just need to fix bits that don't adhere.  It took me
more work to figure out what changed than it probably will to fix it.


> the only fixup I encountered was in individual test cases and test suites
> (i.e. files that are loaded by unittest2).  Does this account for all the
> test failures on your side as well, or is there something else going on I
> missed?
>

Nah I think this is just it.

Thanks!

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

Re: [Lldb-commits] [lldb] r251886 - Tighten up sys.path, and use absolute imports everywhere.

2015-11-02 Thread Todd Fiala via lldb-commits

No, we won't need/want to revert.  I just wanted to see if you already had
a snazzy script I could whiz through a directory tree with.

-Todd

On Mon, Nov 2, 2015 at 10:26 PM, Zachary Turner  wrote:

> Also, one last thing.  The reason this is probably wreaking havoc on your
> stuff internally is because I removed scriptDir from sys.path (diff the
> changes of dotest.py to see).  I think it should stay removed upstream
> (mucking with sys.path so you can import from a parent directory is a bad
> thing to do), but if you have a fork it might be worth putting it back into
> the fork temporarily to get things green?  Note that technically stuff will
> still be "broken" the same way it was before (importing a second copy of a
> module), but that only ever leads to an actual problem fi you rely on
> global state from the module - which upstream anyway we were only ever
> doing for lldbtest_config.
>
> If worse comes to worse we can revert, but if so I think somehow we should
> figure out a strategy for getting this back in, because it definitely seems
> like "the right way"
>
> On Mon, Nov 2, 2015 at 10:14 PM Zachary Turner  wrote:
>
>> Also as far as I can tell, X has to be in the following set: [lldbutil,
>> lldbtest, lldbinline, lldbbench].  In theory there are other possibilities
>> (any .py file that is in packages/Python/lldbsuite/test is fair game) but I
>> don't think I encountered any aside from those 4.
>>
>> On Mon, Nov 2, 2015 at 10:12 PM Zachary Turner 
>> wrote:
>>
>>> On Mon, Nov 2, 2015 at 10:02 PM Todd Fiala  wrote:
>>>
 Do you have a script you used to tweak these?

 (We have a ton of stuff broken internally on this that I need to fix
 up).

 We're starting to need to do quite a bit of extra typing for the
 package structure :-/

>>>
>>> No, I just used a recursive regex replacement.  I had to find a few
>>> different patterns:
>>>
>>> from X import foo # from lldbsuite.test.X import foo
>>> import X   # import lldbsuite.test.X as X
>>> import foo, X   #import foo\nimport lldbsuite.test.X as X
>>>
>>> and I handled each one on a case-by-case basis.
>>>
>>> Luckily the extra typing only comes at the import site.  If you use the
>>> syntax I suggested in #2 and #3 above (import lldbsuite.test.X as X) then
>>> the syntax at any sites where you use a definition from inside the module
>>> are the same.
>>>
>>> I was a little bit annoyed at the extra typing myself, but when I look
>>> into it, it's considered a "feature".  See PEP 0328 - Imports:
>>> Multi-Line and Absolute/Relative
>>>  and as far as I can tell
>>> the way we were doing things before was considered "wrong"  :(
>>>
>>> How much of a problem is this going to be on your side?  Is there an
>>> equally "good" solution that doesn't require so much fixup on your side?
>>>
>>> the only fixup I encountered was in individual test cases and test
>>> suites (i.e. files that are loaded by unittest2).  Does this account for
>>> all the test failures on your side as well, or is there something else
>>> going on I missed?
>>>
>>


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

Re: [Lldb-commits] [lldb] r251886 - Tighten up sys.path, and use absolute imports everywhere.

2015-11-02 Thread Zachary Turner via lldb-commits

On Mon, Nov 2, 2015 at 10:27 PM Todd Fiala  wrote:

> On Mon, Nov 2, 2015 at 10:12 PM, Zachary Turner 
> wrote:
>
>>
>> Luckily the extra typing only comes at the import site.  If you use the
>> syntax I suggested in #2 and #3 above (import lldbsuite.test.X as X) then
>> the syntax at any sites where you use a definition from inside the module
>> are the same.
>>
>> I was a little bit annoyed at the extra typing myself, but when I look
>> into it, it's considered a "feature".  See PEP 0328 - Imports:
>> Multi-Line and Absolute/Relative
>>  and as far as I can tell the
>> way we were doing things before was considered "wrong"  :(
>>
>>
> Heh.  Well, coming out of the gate with broken backward compatibility from
> 2.x to 3.x was considered "right" ( :-P ), so I'm not sure how much weight
> I'd put in the rulings from on high...
>
But.. but.. as long as you get to 3, we'll never make this mistake again,
we promise!  Anyway, welcome to my hell for the past 3 weeks :-/

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

Re: [Lldb-commits] [lldb] r251886 - Tighten up sys.path, and use absolute imports everywhere.

2015-11-02 Thread Todd Fiala via lldb-commits

:-)

On Mon, Nov 2, 2015 at 10:30 PM, Zachary Turner  wrote:

>
>
> On Mon, Nov 2, 2015 at 10:27 PM Todd Fiala  wrote:
>
>> On Mon, Nov 2, 2015 at 10:12 PM, Zachary Turner 
>> wrote:
>>
>>>
>>> Luckily the extra typing only comes at the import site.  If you use the
>>> syntax I suggested in #2 and #3 above (import lldbsuite.test.X as X) then
>>> the syntax at any sites where you use a definition from inside the module
>>> are the same.
>>>
>>> I was a little bit annoyed at the extra typing myself, but when I look
>>> into it, it's considered a "feature".  See PEP 0328 - Imports:
>>> Multi-Line and Absolute/Relative
>>>  and as far as I can tell
>>> the way we were doing things before was considered "wrong"  :(
>>>
>>>
>> Heh.  Well, coming out of the gate with broken backward compatibility
>> from 2.x to 3.x was considered "right" ( :-P ), so I'm not sure how much
>> weight I'd put in the rulings from on high...
>>
> But.. but.. as long as you get to 3, we'll never make this mistake again,
> we promise!  Anyway, welcome to my hell for the past 3 weeks :-/
>
>>


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

59 matches

Mail list logo