Re: [lldb-dev] reply: reply： lldb debug jit-compiled code with llvm on windows

[Oleksiy Vyalov via lldb-dev]

Could you re-build lldb with http://reviews.llvm.org/D15172 and try to hit
a breakpoint in jit code?

I'm using following setup to compile and run JIT code:
./build_release/bin/clang -c -O0 -g -emit-llvm ./jit_test.cpp
./build_release/bin/lli -debugger-tune=lldb -jit-kind=mcjit
~/projects/lldb/test/jit_test.bc

On Mon, Nov 30, 2015 at 3:47 AM, Tamas Berghammer via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

>
>
> On Mon, Nov 30, 2015 at 10:18 AM haifeng_q  wrote:
>
>> Question 1:
>> On the windows, I use the code implements a function (see
>> debug_target.cpp) of JIT (see debug_target_process.cpp), but when
>> generating debug information, no production .symtab section for information
>> that leads LLDB get JIT debugging information .symtab failure , and then
>> set a breakpoint to fail.
>>  LLDB command: lldb_result.txt
>>  JIT compilation results: debug_target.ll
>>
>>  Question 2:
>>  How JIT debugging supported on Linux?
>>
>
> I theory when a new function is JIT-ed then __jit_debug_register_code
> function is called where LLDB have a breakpoint set. When that breakpoint
> is hit then LLDB reads the JIT-ed elf file based on the information in 
> __it_debug_descriptor
> and processes all debug info in it.
>
> In practice when I last tried JIT debugging with lldb and lli (few weeks
> ago) it get the notification for the new JIT-ed elf file but it processed
> only the eh_frame from it even though symtab and full debug info was also
> provided. Most likely there is some issue around the JIT breakpoint
> handling or around the elf file parsing code in LLDB what needs
> some investigation.
>
>>
>> thanks!
>>
>> -- The original message --
>> *From:* "Zachary Turner";;
>> *Data:* 2015年11月21日 AM 0:10
>> *Receive:* "Tamas Berghammer"; " "<
>> haifen...@foxmail.com>; "lldb-dev";
>> *Title:* Re: [lldb-dev] reply： lldb debug jit-compiled code with llvm on
>> windows
>>
>> Can you also try clang-cl and see if it works?
>>
>> On Fri, Nov 20, 2015 at 3:02 AM Tamas Berghammer via lldb-dev <
>> lldb-dev@lists.llvm.org> wrote:
>>
>>> I don't know how JIT debugging should work on WIndows with MSVC but I
>>> don't think LLDB support it in any way. What I wrote should be true on
>>> Linux (and on some related) systems. You might be able to get the same
>>> results on Windows if you use lli (LLVM based JIT runner) but I have no
>>> knowledge if it will work or not.
>>>
>>> On Fri, Nov 20, 2015 at 8:56 AM haifeng_q  wrote:
>>>
 My analysis of the code, the reasons are:

 Since the debugging process is MSVC compiler, there is no DWARF debugging
 information. So lldb get __jit_debug_register_code and
 __it_debug_descriptor symbol debugging process fails, and
 __jit_debug_register_code not support MSVC.
 I do not know whether correct?

 -- original message--
 *From:*"Tamas Berghammer";tbergham...@google.com;
 Date*:*2015年11月19日 PM 8:37
 *receive:* " "; "lldb-dev"<
 lldb-dev@lists.llvm.org>;
 *Subject:* Re: [lldb-dev] lldb debug jit-compiled code with llvm on
 windows

 In theory you don't have to do anything special to debug some JIT-ed
 code as everything should just work (based on the gdb jit interface). In
 practice I tried it out a few days ago and it wasn't working at all even in
 the case when the application is launched under LLDB (not with attach).
 LLDB was understanding the eh_frame for the JIT-ed code but didn't found
 the debug info for unknown reason. We should investigate it and try to fix
 it sometime. We (lldb for android developers) plan to do it sometime but if
 you are interested in it then please feel free to take a look and let us
 know if you have any question.

 Tamas

 On Thu, Nov 19, 2015 at 8:40 AM haifeng_q via lldb-dev <
 lldb-dev@lists.llvm.org> wrote:

> hi,
> process A generate function Func1 code with llvm jit compiler, and calls
> Func1. modeled on "Kaleidoscope: Adding Debug Information" add debug
> information. how to use LLDB to attach process A to debug this
> function, add a breakpoint in the function?
>
> thanks!
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
 ___
>>> lldb-dev mailing list
>>> lldb-dev@lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>>
>>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>


-- 
Oleksiy Vyalov | Software Engineer | ovya...@google.com
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Module Cache improvements - RFC

[Oleksiy Vyalov via lldb-dev]

For progress purposes in Android Studio we listen on
eBroadcastBitModulesLoaded coming from the target so we can report about
every loaded SO.

On Tue, Feb 23, 2016 at 10:00 AM, Greg Clayton via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> I believe this is already done.
>
> I am guessing the main issue is this happens on the first time you debug
> to a device you and up with a 30 second delay with no feedback as to what
> is going on. So you say "launch" and then 35 seconds later you hit your
> breakpoint at main. In Xcode we solve this by downloading all of the files
> when we attach to a device for the first time and we show progress as we
> download all shared libraries. Sounds like it would be good for Android
> Studio to do the same thing?
>
> Greg
> > On Feb 22, 2016, at 5:27 PM, Zachary Turner  wrote:
> >
> > Can't you just cache the modules locally on the disk, so that you only
> take that 26 second hit the first time you try to download that module, and
> then it indexes it by some sort of hash.  Then instead of just downloading
> it, you check the local cache first and only download if it's not there.
> >
> > If you already do all this, then disregard.
> >
> > On Mon, Feb 22, 2016 at 4:39 PM Greg Clayton via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >
> > > On Jan 28, 2016, at 4:21 AM, Pavel Labath  wrote:
> > >
> > > Hello all,
> > >
> > > we are running into limitations of the current module download/caching
> > > system. A simple android application can link to about 46 megabytes
> > > worth of modules, and downloading that with our current transfer rates
> > > takes about 25 seconds. Much of the data we download this way is never
> > > actually accessed, and yet we download everything immediately upon
> > > starting the debug session, which makes the first session extremely
> > > laggy.
> > >
> > > We could speed up a lot by only downloading the portions of the module
> > > that we really need (in my case this turns out to be about 8
> > > megabytes). Also, further speedups could be made by increasing the
> > > throughput of the gdb-remote protocol used for downloading these files
> > > by using pipelining.
> > >
> > > I made a proof-of-concept hack  of these things, put it into lldb and
> > > I was able to get the time for the startup-attach-detach-exit cycle
> > > down to 5.4 seconds (for comparison, the current time for the cycle is
> > > about 3.6 seconds with a hot module cache, and 28(!) seconds with an
> > > empty cache).
> > >
> > > Now, I would like to properly implement these things in lldb properly,
> > > so this is a request for comments on my plan. What I would like to do
> > > is:
> > > - Replace ModuleCache with a SectionCache (actually, more like a cache
> > > of arbitrary file chunks). When a the cache gets a request for a file
> > > and the file is not in the cache already, it returns a special kind of
> > > a Module, whose fragments will be downloaded as we are trying to
> > > access them. These fragments will be cached on disk, so that
> > > subsequent requests for the file do not need to re-download them. We
> > > can also have the option to short-circuit this logic and download the
> > > whole file immediately (e.g., when the file is small, or we have a
> > > super-fast way of obtaining the whole file via rsync, etc...)
> > > - Add pipelining support to GDBRemoteCommunicationClient for
> > > communicating with the platform. This actually does not require any
> > > changes to the wire protocol. The only change is in adding the ability
> > > to send an additional request to the server while waiting for the
> > > response to the previous one. Since the protocol is request-response
> > > based and we are communication over a reliable transport stream, each
> > > response can be correctly matched to a request even though we have
> > > multiple packets in flight. Any packets which need to maintain more
> > > complex state (like downloading a single entity using continuation
> > > packets) can still lock the stream to get exclusive access, but I am
> > > not sure if we actually even have any such packets in the platform
> > > flavour of the protocol.
> > > - Paralelize downloading of multiple files in parallel, utilizing
> > > request pipelining. Currently we get the biggest delay when first
> > > attaching to a process (we download file headers and some basic
> > > informative sections) and when we try to set the first symbol-level
> > > breakpoint (we download symbol tables and string sections). Both of
> > > these actions operate on all modules in bulk, which makes them easy
> > > paralelization targets. This will provide a big speed boost, as we
> > > will be eliminating communication latency. Furthermore, in case of
> > > lots of files, we will be overlapping file download  (io) with parsing
> > > (cpu), for an even bigger boost.
> > >
> > > What do you think?
> > >
> >
> > Feel free to implement this in PlatformAndroid and allow others to opt
> into this. I won't w

Re: [lldb-dev] TestAttachDenied - timing out

[Oleksiy Vyalov via lldb-dev]

Test used to be flaky from time to time but in
http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake/builds/6802
it failed consistently for all configurations - that's pretty suspicious.
Test inferior writes some output to stdout and stderr - I don't have a lot
of context about http://reviews.llvm.org/D13124 but as I can see all
standard streams are set to subprocess.PIPE, as a guess
maybe inferior tries to write sth in stdout/stderr but nobody is reading
this data on python side.


On Tue, Sep 29, 2015 at 4:17 PM, Todd Fiala via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> I killed build 6803 on the Linux buildbot since the tests would have taken
> 25+ minutes to run through the timeout on the theory that getting the
> results net faster would be better.  6804+ should have the test disabled
> that was timing out.
>
> On Tue, Sep 29, 2015 at 4:09 PM, Todd Fiala  wrote:
>
>> I disabled it on Linux with this:
>> svn commit
>> Sending
>>  functionalities/process_attach/attach_denied/TestAttachDenied.py
>> Transmitting file data .
>> Committed revision 248846.
>>
>>
>>
>> On Tue, Sep 29, 2015 at 4:02 PM, Todd Fiala  wrote:
>>
>>> That said, I'm going to disable the test and look into why it is timing
>>> out so our poor Google test runner doesn't take forever to go through the
>>> tests.
>>>
>>> I'll file a ticket and look into it.
>>>
>>> On Tue, Sep 29, 2015 at 3:54 PM, Todd Fiala 
>>> wrote:
>>>
 Hi all,

 I've been running the test suite for quite some time on the Linux
 side.  I pretty consistently see this test case file:

 TestAttachDenied.py

 time out on my Linux setup (prior to any of my test runner changes).
 I'm noticing it is now showing up on the Google Linux buildbot (here -
 build 6802
 
 ).

 I just wanted to throw out there that this isn't a new phenomenon on my
 end (Ubuntu 14.04 x86_64 built with clang 3.6 and tested with inferiors
 built with clang 3.6).

 --
 -Todd

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


-- 
Oleksiy Vyalov | Software Engineer | ovya...@google.com
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Python object lifetimes affect the reliability of tests

[Oleksiy Vyalov via lldb-dev]

I stumbled upon similar problem when was looking into why SBDebugger wasn't
unloaded upon app's exit.
The problem was in Python global objects like lldb.debugger, lldb.target
sitting around.
So, my guess is to try to call ScriptInterpreterPython::Clear  within
test's tearDown call - e.g., expose Clear method as part of
SBCommandInterpreter and call it via SBDebugger::GetCommandInterpreter

On Thu, Oct 15, 2015 at 8:50 AM, Adrian McCarthy via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> I've tracked down a source of flakiness in tests on Windows to Python
> object lifetimes and the SB interface, and I'm wondering how best to handle
> it.
>
> Consider this portion of a test from TestTargetAPI:
>
> def find_functions(self, exe_name):
> """Exercise SBTaget.FindFunctions() API."""
> exe = os.path.join(os.getcwd(), exe_name)
>
> # Create a target by the debugger.
> target = self.dbg.CreateTarget(exe)
> self.assertTrue(target, VALID_TARGET)
> list = target.FindFunctions('c', lldb.eFunctionNameTypeAuto)
> self.assertTrue(list.GetSize() == 1)
>
> for sc in list:
> self.assertTrue(sc.GetModule().GetFileSpec().GetFilename() ==
> exe_name)
> self.assertTrue(sc.GetSymbol().GetName() == 'c')
>
> The local variables go out of scope when the function exits, but the SB
> (C++) objects they represent aren't (always) immediately destroyed.  At
> least some of these objects keep references to the executable module in the
> shared module list, so when the test framework cleans up and calls
> `SBDebugger::DeleteTarget`, the module isn't orphaned, so LLDB maintains an
> open handle to the executable.
>
> The result of the lingering handle is that, when the next test case in the
> test suite tries to re-build the executable, it fails because the file is
> not writable.  (This is problematic on Windows because the file system
> works differently in this regard than Unix derivatives.)  Every subsequent
> case in the test suite fails.
>
> I managed to make the test work reliably by rewriting it like this:
>
> def find_functions(self, exe_name):
> """Exercise SBTaget.FindFunctions() API."""
> exe = os.path.join(os.getcwd(), exe_name)
>
> # Create a target by the debugger.
> target = self.dbg.CreateTarget(exe)
> self.assertTrue(target, VALID_TARGET)
>
> try:
> list = target.FindFunctions('c', lldb.eFunctionNameTypeAuto)
> self.assertTrue(list.GetSize() == 1)
>
> for sc in list:
> try:
>
> self.assertTrue(sc.GetModule().GetFileSpec().GetFilename() == exe_name)
> self.assertTrue(sc.GetSymbol().GetName() == 'c')
> finally:
> del sc
>
> finally:
> del list
>
> The finally blocks ensure that the corresponding C++ objects are
> destroyed, even if the function exits as a result of a Python exception
> (e.g., if one of the assertion expressions is false and the code throws an
> exception).  Since the objects are destroyed, the reference counts are back
> to where they should be, and the orphaned module is closed when the target
> is deleted.
>
> But this is ugly and maintaining it would be error prone.  Is there a
> better way to address this?
>
> In general, it seems bad that our tests aren't well-isolated.  I
> sympathize with the concern that re-starting LLDB for each test case would
> slow down testing, but I'm also concerned that the state of LLDB for any
> given test case can depend on what happened in the earlier cases.
>
> Adrian.
>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>


-- 
Oleksiy Vyalov | Software Engineer | ovya...@google.com
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Compiling LLDB on Centos 5 (dont judge me)

[Oleksiy Vyalov via lldb-dev]

Hi Mark,

what compiler do you use? Could you try to build LLDB with clang 3.5
specifying it via DCMAKE_C_COMPILER and DCMAKE_CXX_COMPILER flags?
It might be a problem with sysroot setup since some headers are not found -
you can try to pass a custom sysroot with -DCMAKE_CXX_FLAGS="--sysroot=..."

On Tue, Oct 27, 2015 at 2:05 PM, Mark Chandler via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> Hi All,
>
>
>
> Trying to get LLDB to compile on centos 5 to help reduce the size of cores
> of programs crashing on some servers however im running into some compile
> issues with it. Looks like some features are used from newer kernel
> versions and was wondering what the procedure is to get this fixed and
> updated into lldb.
>
>
>
> These are the errors so far:
>
>
> https://gist.githubusercontent.com/lodle/47493c8ea2a51eff5322/raw/ce158e1d10d1df363bdd3a77b11ff3d8661e8144/lldb_make.txt
>
> Some of them are using O_CLOEXEC flag and headers that don’t exist and was
> easy enough to add works around. The ones at the end im not sure about.
>
>
>
>
>
> Build Script:
>
> https://gist.github.com/lodle/e24a80907bbf7a7b72f6
>
>
>
>
>
> Thanks for the help.
>
>
>
>
>
> *Mark Chandler*
>
> Battle.Net Infrastructure | Blizzard Entertainment
>
> *(P) *949-955-1380 x15353
>
>
>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>


-- 
Oleksiy Vyalov | Software Engineer | ovya...@google.com
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Refactoring dotest as a Python package

[Oleksiy Vyalov via lldb-dev]

Linux build bot is failing
http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake/builds/7895
:

/lldb-buildbot/lldbSlave/buildWorkingDir/scripts/../llvm/tools/lldb/test/dotest.py
--executable
/lldb-buildbot/lldbSlave/buildWorkingDir/scripts/../build/bin/lldb -A i386
-C clang-3.5 -s logs-clang-3.5-i386 -u CXXFLAGS -u CFLAGS --channel
"gdb-remote packets" --channel "lldb all"
/lldb-buildbot/lldbSlave/buildWorkingDir/scripts/../llvm/tools/lldb/test/dotest.py:
line 1: import: command not found
/lldb-buildbot/lldbSlave/buildWorkingDir/scripts/../llvm/tools/lldb/test/dotest.py:
line 3: import: command not found
/lldb-buildbot/lldbSlave/buildWorkingDir/scripts/../llvm/tools/lldb/test/dotest.py:
line 5: syntax error: unexpected end of file

Should we run packages/Python/lldbsuite/test/dotest.py instead of
test/dotest.py?
If yes, can we set executable permissions on
 packages/Python/lldbsuite/test/dotest.py?

On Wed, Oct 28, 2015 at 10:54 AM, Zachary Turner via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> This is in right now (without my proposed change from previous email,
> although I can make that as a followup since it's just cleanup)
>
> In any case, let me know if anything blows up.  It took 35 minutes just to
> commit, so hopefully any problems that arise can be fixed with localized
> patches instead of revert.  Although I'm still open to that if it's really
> the only way to get things fixed.
>
> On Tue, Oct 27, 2015 at 8:12 PM Zachary Turner  wrote:
>
>> Todd, I have one question.  If I understand correctly, we currently run
>> dotest.py as a script, which imports dosep and calls some method in dosep,
>> and dosep then again exec's dotest.
>>
>> Can you think of a pythonic way to make this work under the new layout?
>> To be clear, I have it working, just not in a pythonic way.  The problem is
>> that if we put code in lldbsuite's __init__.py, then this code won't be
>> run when we exec dotest, because we'll be running it as a script instead of
>> importing it as a package.  __init__.py is a very handy way to run some
>> per-package initialization, so I'd like to be able to take advantage of it.
>>
>> The way I currently have it working is just write `import lldbsuite` at
>> the top of dotest.py, but that seems a little arbitrary that a file can't
>> be exec'ed unless it imports the package that it's supposed to be contained
>> in.
>>
>> So to re-iterate: the problem is that under the new layout the user will
>> run lldb/test/dotest.py, but dosep will try to exec
>> lldb/packages/Python/lldbsuite/test/dotest.py, which is intended to be
>> imported as a package.
>>
>> What if we have dosep instead do this:
>>
>> # Execute the same script that the user originall ran from the command
>> line,
>> # which under this new system will be lldb/test/dotest.py, even though
>> dosep
>> # and the *real* dotest now reside in lldb/packages/Python/lldbsuite/test
>> import __main__ as main
>> exec main.__file__
>>
>> Can you think of any problem with this?  Another option is to use
>> sys.argv[0].  Not sure if there's any practical difference between the two
>> methods.
>>
>> On Tue, Oct 27, 2015 at 7:29 PM Zachary Turner 
>> wrote:
>>
>>> Ok, I'll do it tomorrow.  Since it's a big code move I was a little
>>> worried it would break someone's bot or the Xcode build, but I guess we can
>>> deal with issues that pop up afterwards.
>>>
>>> On Tue, Oct 27, 2015 at 5:14 PM Jim Ingham  wrote:
>>>
 It seems like everybody is okay with the idea of this, so I don't see
 the need for a review of the details of this stage.  If you think there's
 anything tricky call it out in words, otherwise I say just commit it.

 Jim


 > On Oct 27, 2015, at 4:30 PM, Zachary Turner via lldb-dev <
 lldb-dev@lists.llvm.org> wrote:
 >
 > I have the first part of the patch in, and the second part of the
 patch (which is essentially just a whole-folder rename with a couple of
 fixups) ready to go.  What's the best way to have this reviewed?  Uploading
 a 7MB patch to Phabricator probably isn't going to work out very well.
 >
 > On Tue, Oct 27, 2015 at 1:40 PM Zachary Turner 
 wrote:
 > I think I have a way to split this into two smaller CLs.  I'm testing
 this at the moment, if so it will allow the first CL to be most of the
 preparation for the rename without the rename, and then the second CL
 should literally just be a straight move with only 1-2 line code change.
 So I'll try to put this first CL up for review shortly.
 >
 > On Tue, Oct 27, 2015 at 12:49 PM Zachary Turner 
 wrote:
 > I've got a patch locally to make all of our Python stuff part of an
 lldb package called `lldbsuite`.  Currently we've got a bunch of standalone
 scripts that live in various directories such as `lldb/test`, or
 `lldb/scripts`, and possibly some  other locations, and this organization
 makes it hard to share code because it is incompatible

Re: [lldb-dev] Refactoring dotest as a Python package

[Oleksiy Vyalov via lldb-dev]

The fix seems to work -
http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake/builds/7900
.
Thank you.

On Wed, Oct 28, 2015 at 12:21 PM, Zachary Turner  wrote:

> Committed r251544 to try to fix this.
>
> On Wed, Oct 28, 2015 at 12:18 PM Zachary Turner 
> wrote:
>
>> It's saying "import: command not found".  Do I need to put a
>> `#!/usr/bin/env python` or something at the top?  I thought by virtue of
>> having a .py extension this would be handled, but maybe not.
>>
>> On Wed, Oct 28, 2015 at 12:16 PM Zachary Turner 
>> wrote:
>>
>>> We can set executable permissions
>>> on packages/Python/lldbsuite/test/dotest.py for now.  I suppose that's
>>> actually necessary for now since it does tget executed indirectly by dosep.
>>>
>>> I plan to remove the need for this, and at the same time make it fail if
>>> you try to run that file directly.  Will that fix this problem?  It's not
>>> clear to me from looking at this log if that is the problem
>>>
>>> On Wed, Oct 28, 2015 at 11:50 AM Oleksiy Vyalov 
>>> wrote:
>>>
 Linux build bot is failing
 http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake/builds/7895
 :

 /lldb-buildbot/lldbSlave/buildWorkingDir/scripts/../llvm/tools/lldb/test/dotest.py
 --executable
 /lldb-buildbot/lldbSlave/buildWorkingDir/scripts/../build/bin/lldb -A i386
 -C clang-3.5 -s logs-clang-3.5-i386 -u CXXFLAGS -u CFLAGS --channel
 "gdb-remote packets" --channel "lldb all"
 /lldb-buildbot/lldbSlave/buildWorkingDir/scripts/../llvm/tools/lldb/test/dotest.py:
 line 1: import: command not found
 /lldb-buildbot/lldbSlave/buildWorkingDir/scripts/../llvm/tools/lldb/test/dotest.py:
 line 3: import: command not found
 /lldb-buildbot/lldbSlave/buildWorkingDir/scripts/../llvm/tools/lldb/test/dotest.py:
 line 5: syntax error: unexpected end of file

 Should we run packages/Python/lldbsuite/test/dotest.py instead of
 test/dotest.py?
 If yes, can we set executable permissions on
  packages/Python/lldbsuite/test/dotest.py?

 On Wed, Oct 28, 2015 at 10:54 AM, Zachary Turner via lldb-dev <
 lldb-dev@lists.llvm.org> wrote:

> This is in right now (without my proposed change from previous email,
> although I can make that as a followup since it's just cleanup)
>
> In any case, let me know if anything blows up.  It took 35 minutes
> just to commit, so hopefully any problems that arise can be fixed with
> localized patches instead of revert.  Although I'm still open to that if
> it's really the only way to get things fixed.
>
> On Tue, Oct 27, 2015 at 8:12 PM Zachary Turner 
> wrote:
>
>> Todd, I have one question.  If I understand correctly, we currently
>> run dotest.py as a script, which imports dosep and calls some method in
>> dosep, and dosep then again exec's dotest.
>>
>> Can you think of a pythonic way to make this work under the new
>> layout?  To be clear, I have it working, just not in a pythonic way.  The
>> problem is that if we put code in lldbsuite's __init__.py, then this
>> code won't be run when we exec dotest, because we'll be running it as a
>> script instead of importing it as a package.  __init__.py is a very handy
>> way to run some per-package initialization, so I'd like to be able to 
>> take
>> advantage of it.
>>
>> The way I currently have it working is just write `import lldbsuite`
>> at the top of dotest.py, but that seems a little arbitrary that a file
>> can't be exec'ed unless it imports the package that it's supposed to be
>> contained in.
>>
>> So to re-iterate: the problem is that under the new layout the user
>> will run lldb/test/dotest.py, but dosep will try to exec
>> lldb/packages/Python/lldbsuite/test/dotest.py, which is intended to be
>> imported as a package.
>>
>> What if we have dosep instead do this:
>>
>> # Execute the same script that the user originall ran from the
>> command line,
>> # which under this new system will be lldb/test/dotest.py, even
>> though dosep
>> # and the *real* dotest now reside in
>> lldb/packages/Python/lldbsuite/test
>> import __main__ as main
>> exec main.__file__
>>
>> Can you think of any problem with this?  Another option is to use
>> sys.argv[0].  Not sure if there's any practical difference between the 
>> two
>> methods.
>>
>> On Tue, Oct 27, 2015 at 7:29 PM Zachary Turner 
>> wrote:
>>
>>> Ok, I'll do it tomorrow.  Since it's a big code move I was a little
>>> worried it would break someone's bot or the Xcode build, but I guess we 
>>> can
>>> deal with issues that pop up afterwards.
>>>
>>> On Tue, Oct 27, 2015 at 5:14 PM Jim Ingham 
>>> wrote:
>>>
 It seems like everybody is okay with the idea of this, so I don't
 see the need for a review of the details of