Re: [lldb-dev] Using DYLD_LIBRARY_PATH and lldb

[Jason Molenda via lldb-dev]

If it's on Mac OS X 10.11, I saw this the other day.  e.g.

sh-3.2$ cat a.c
#include 
#include 
int main() 
{
printf("%s\n", getenv("DYLD_LIBRARY_PATH"));
}
sh-3.2$ clang a.c

sh-3.2$ lldb -x a.out
(lldb) target create "a.out"
Current executable set to 'a.out' (x86_64).
(lldb) pro lau -v DYLD_LIBRARY_PATH=/tmp 
Process 66509 launched: '/private/tmp/a.out' (x86_64)
/tmp
Process 66509 exited with status = 0 (0x) 
(lldb) q

sh-3.2$ DYLD_LIBRARY_PATH=/tmp lldb -x -- a.out
(lldb) target create "a.out"
Current executable set to 'a.out' (x86_64).
(lldb) r
Process 66776 launched: '/private/tmp/a.out' (x86_64)
(null)
Process 66776 exited with status = 0 (0x) 
(lldb) q


The DYLD_LIBRARY_PATH isn't being passed into lldb, it seems.  If I attach to 
that lldb with another lldb,

(lldb) pro att -n lldb
Executable module set to 
"/Applications/Xcode.app/Contents/Developer/usr/bin/lldb".
Architecture set to: x86_64-apple-macosx.
(lldb) p (char*)getenv("DYLD_LIBRARY_PATH")
(char *) $0 = 0x
(lldb) ^D

yep, it's not being passed through.




> On Oct 26, 2015, at 10:02 AM, Greg Clayton via lldb-dev 
>  wrote:
> 
> I am surprised that this doesn't work as we make an effort to pass the 
> current environment down to any processes that you spawn by default (at least 
> on MacOSX we do), but the solution is easy: use the --environment variable 
> with the "process launch" command:
> 
> (lldb) process launch --environment DYLD_LIBRARY_PATH= -- arg1 
> arg2 arg3
> 
> or using the short -v option:
> 
> (lldb) process launch -v DYLD_LIBRARY_PATH= -- arg1 arg2 arg3
> 
> r is an alias to "process launch --". Note that "process launch" can have 
> arguments and the arguments you want to pass to your program might have 
> options, so you can terminate your "process launch" arguments with "--" so 
> that you can add your program arguments:
> 
> (lldb) process launch --environment DYLD_LIBRARY_PATH= -- 
> --program-option=123 --environment BAR=BAZ
> 
> Note that I actually used an option "--environment BAR=BAZ" that I am passing 
> to the program to be debugged...
> 
> It is better to use --environment because then your current LLDB or any 
> processes that LLDB spawns won't have that environment variable set. Hope 
> this helps.
> 
> Greg Clayton
> 
> 
>> On Oct 23, 2015, at 1:11 AM, Haakon Sporsheim via lldb-dev 
>>  wrote:
>> 
>> Hi.
>> 
>> I'm fairly new to lldb, been using gdb most of my life.
>> 
>> I'm currently hacking on a small library which I'm building without
>> installing. Usually I'm running tests for the library also without
>> installing, but rather using DYLD_LIBRARY_PATH in this manner:
>> DYLD_LIBRARY_PATH= mytestbinary
>> 
>> On linux using gdb when I  want to debug an issue I usually just stick
>> gdb in there, which I can't do with lldb on darwin it seems:
>> DYLD_LIBRARY_PATH= lldb mytestbinary
>> 
>> lldb gives me this result:
>> (lldb) target create ""
>> Current executable set to '' (x86_64).
>> (lldb) r
>> Process 4904 launched: '' (x86_64)
>> dyld: Library not loaded: /usr/local/lib/
>> Referenced from: 
>> Reason: image not found
>> Process 4904 stopped
>> * thread #1: tid = 0xfe39, 0x7fff5fc01075 dyld`dyld_fatal_error +
>> 1, stop reason = EXC_BREAKPOINT (code=EXC_I386_BPT, subcode=0x0)
>>   frame #0: 0x7fff5fc01075 dyld`dyld_fatal_error + 1
>> dyld`dyld_fatal_error:
>> ->  0x7fff5fc01075 <+1>: nop
>> 
>> dyld`dyldbootstrap::start:
>>   0x7fff5fc01076 <+0>: pushq  %rbp
>>   0x7fff5fc01077 <+1>: movq   %rsp, %rbp
>>   0x7fff5fc0107a <+4>: pushq  %r15
>> (lldb)
>> 
>> so it's not picking up the dylib from DYLD_LIBRARY_PATH.
>> 
>> I guess my question is whether this is a bug or not? Am I doing
>> anything wrong, or should I not use DYLD_LIBRARY_PATH this way? Any
>> suggestions and/or education would be appreciated!
>> To work around this issue I've used 'install_name_tool -change old new
>> ' which obviously works.
>> 
>> Thanks, best regards
>> Haakon Sporsheim
>> ___
>> 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

[lldb-dev] Debugging lldb with lldb: infinite process interrupt?

[Ramkumar Ramachandra via lldb-dev]

Hi,

I'm using lldb to debug lldb, and I notice that I get this message in
the inner lldb:

(lldb) p F
error: Process is running.  Use 'process interrupt' to pause execution.

If I 'process interrupt', I go to the outer lldb (presumably), and if
I try to 'continue', the same message is displayed over and over
again.

This only happens _sometimes_, and I can't quite explain when.

Any clues?

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

Re: [lldb-dev] Debugging lldb with lldb: infinite process interrupt?

[Greg Clayton via lldb-dev]

> On Oct 27, 2015, at 11:18 AM, Ramkumar Ramachandra via lldb-dev 
>  wrote:
> 
> Hi,
> 
> I'm using lldb to debug lldb, and I notice that I get this message in
> the inner lldb:
> 
> (lldb) p F
> error: Process is running.  Use 'process interrupt' to pause execution.
> 
> If I 'process interrupt', I go to the outer lldb (presumably), and if
> I try to 'continue', the same message is displayed over and over
> again.
> 
> This only happens _sometimes_, and I can't quite explain when.
> 
> Any clues?

Sometimes processes that are in the same process group will forward signals to 
each other if it isn't handled. Interrupting the process usually sends a 
SIGSTOP or SIGINT to the process and that may be being forwarded up to the 
current LLDB somehow.

If you are debugging two LLDB binaries I would start one in one terminal and 
attach to it from another terminal running LLDB so you don't have to share the 
same terminal. This will ensure the two processes aren't in the same process 
group and no signals will be forwarded.

I sometimes do debug one LLDB with another and when I do this, I set my prompt 
to "(lldb-top) ":

(lldb) settings set prompt "(lldb-top) "
(lldb-top) 

Then I can tell the two apart. 
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] Refactoring dotest as a Python package

[Zachary Turner via lldb-dev]

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 with Python's
built-in code reuse mechanism, which is its package system.

The problem is, this patch is *big*.  Functionally there weren't many major
changes, but it renames the entire test directory.  To be clear, it still
leaves `test/dotest.py` in place, so nobody has to change their workflow or
do anything differently.  If you used to write "cd test && dotest.py" you
can still do that.  dotest.py is now just a 2 line wrapper around the
package, so it looks like:

import lldbsuite.test
lldbsuite.test.run_suite()

the advantage of this method is that lldbsuite can contain subpackages.  It
already contains one subpackage, which is lldbsuite.test, and I plan to
move some of the Python code in `lldb/scripts` there as well, so that we
have lldbsuite.scripts.  Then we can add a third submodule,
lldbsuite.shared, and now dotest can share code with scripts, and it gives
us a nice place to put stuff that previously had been copied all around.

It also gives us a nice way to perform module-wide initialization that we
don't have to repeat in every single test, such as writing "import
lldb_shared" at the top of every file, since that can be done as part of
lldbsuite/__init__.py.


In any case, I have this all working on my machine, but I would like to see
if someone can try my patch out on other platforms.  The size of the patch
presents a problem though - it's over 7MB since it renames a very large
directory.

As usual, comments / concerns also welcome.
___
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

[Zachary Turner via lldb-dev]

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 with Python's
> built-in code reuse mechanism, which is its package system.
>
> The problem is, this patch is *big*.  Functionally there weren't many
> major changes, but it renames the entire test directory.  To be clear, it
> still leaves `test/dotest.py` in place, so nobody has to change their
> workflow or do anything differently.  If you used to write "cd test &&
> dotest.py" you can still do that.  dotest.py is now just a 2 line wrapper
> around the package, so it looks like:
>
> import lldbsuite.test
> lldbsuite.test.run_suite()
>
> the advantage of this method is that lldbsuite can contain subpackages.
> It already contains one subpackage, which is lldbsuite.test, and I plan to
> move some of the Python code in `lldb/scripts` there as well, so that we
> have lldbsuite.scripts.  Then we can add a third submodule,
> lldbsuite.shared, and now dotest can share code with scripts, and it gives
> us a nice place to put stuff that previously had been copied all around.
>
> It also gives us a nice way to perform module-wide initialization that we
> don't have to repeat in every single test, such as writing "import
> lldb_shared" at the top of every file, since that can be done as part of
> lldbsuite/__init__.py.
>
>
> In any case, I have this all working on my machine, but I would like to
> see if someone can try my patch out on other platforms.  The size of the
> patch presents a problem though - it's over 7MB since it renames a very
> large directory.
>
> As usual, comments / concerns also welcome.
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Mark Chandler via lldb-dev]

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

[lldb-dev] [Bug 25039] Go tests need to check for minimum version of go needed to run the tests

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=25039

Todd Fiala  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #9 from Todd Fiala  ---
Fixed this a few weeks back.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
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

[Zachary Turner via lldb-dev]

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 with Python's
>> built-in code reuse mechanism, which is its package system.
>>
>> The problem is, this patch is *big*.  Functionally there weren't many
>> major changes, but it renames the entire test directory.  To be clear, it
>> still leaves `test/dotest.py` in place, so nobody has to change their
>> workflow or do anything differently.  If you used to write "cd test &&
>> dotest.py" you can still do that.  dotest.py is now just a 2 line wrapper
>> around the package, so it looks like:
>>
>> import lldbsuite.test
>> lldbsuite.test.run_suite()
>>
>> the advantage of this method is that lldbsuite can contain subpackages.
>> It already contains one subpackage, which is lldbsuite.test, and I plan to
>> move some of the Python code in `lldb/scripts` there as well, so that we
>> have lldbsuite.scripts.  Then we can add a third submodule,
>> lldbsuite.shared, and now dotest can share code with scripts, and it gives
>> us a nice place to put stuff that previously had been copied all around.
>>
>> It also gives us a nice way to perform module-wide initialization that we
>> don't have to repeat in every single test, such as writing "import
>> lldb_shared" at the top of every file, since that can be done as part of
>> lldbsuite/__init__.py.
>>
>>
>> In any case, I have this all working on my machine, but I would like to
>> see if someone can try my patch out on other platforms.  The size of the
>> patch presents a problem though - it's over 7MB since it renames a very
>> large directory.
>>
>> As usual, comments / concerns also welcome.
>>
>
___
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

[Jim Ingham via lldb-dev]

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 
>  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 with Python's built-in 
> code reuse mechanism, which is its package system.
> 
> The problem is, this patch is *big*.  Functionally there weren't many major 
> changes, but it renames the entire test directory.  To be clear, it still 
> leaves `test/dotest.py` in place, so nobody has to change their workflow or 
> do anything differently.  If you used to write "cd test && dotest.py" you can 
> still do that.  dotest.py is now just a 2 line wrapper around the package, so 
> it looks like:
> 
> import lldbsuite.test
> lldbsuite.test.run_suite()
> 
> the advantage of this method is that lldbsuite can contain subpackages.  It 
> already contains one subpackage, which is lldbsuite.test, and I plan to move 
> some of the Python code in `lldb/scripts` there as well, so that we have 
> lldbsuite.scripts.  Then we can add a third submodule, lldbsuite.shared, and 
> now dotest can share code with scripts, and it gives us a nice place to put 
> stuff that previously had been copied all around.
> 
> It also gives us a nice way to perform module-wide initialization that we 
> don't have to repeat in every single test, such as writing "import 
> lldb_shared" at the top of every file, since that can be done as part of 
> lldbsuite/__init__.py.
> 
> 
> In any case, I have this all working on my machine, but I would like to see 
> if someone can try my patch out on other platforms.  The size of the patch 
> presents a problem though - it's over 7MB since it renames a very large 
> directory.
> 
> As usual, comments / concerns also welcome.
> ___
> 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

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

[Zachary Turner via lldb-dev]

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 with Python's
> built-in code reuse mechanism, which is its package system.
> >
> > The problem is, this patch is *big*.  Functionally there weren't many
> major changes, but it renames the entire test directory.  To be clear, it
> still leaves `test/dotest.py` in place, so nobody has to change their
> workflow or do anything differently.  If you used to write "cd test &&
> dotest.py" you can still do that.  dotest.py is now just a 2 line wrapper
> around the package, so it looks like:
> >
> > import lldbsuite.test
> > lldbsuite.test.run_suite()
> >
> > the advantage of this method is that lldbsuite can contain subpackages.
> It already contains one subpackage, which is lldbsuite.test, and I plan to
> move some of the Python code in `lldb/scripts` there as well, so that we
> have lldbsuite.scripts.  Then we can add a third submodule,
> lldbsuite.shared, and now dotest can share code with scripts, and it gives
> us a nice place to put stuff that previously had been copied all around.
> >
> > It also gives us a nice way to perform module-wide initialization that
> we don't have to repeat in every single test, such as writing "import
> lldb_shared" at the top of every file, since that can be done as part of
> lldbsuite/__init__.py.
> >
> >
> > In any case, I have this all working on my machine, but I would like to
> see if someone can try my patch out on other platforms.  The size of the
> patch presents a problem though - it's over 7MB since it renames a very
> large directory.
> >
> > As usual, comments / concerns also welcome.
> > ___
> > 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

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

[Zachary Turner via lldb-dev]

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 with Python's
>> built-in code reuse mechanism, which is its package system.
>> >
>> > The problem is, this patch is *big*.  Functionally there weren't many
>> major changes, but it renames the entire test directory.  To be clear, it
>> still leaves `test/dotest.py` in place, so nobody has to change their
>> workflow or do anything differently.  If you used to write "cd test &&
>> dotest.py" you can still do that.  dotest.py is now just a 2 line wrapper
>> around the package, so it looks like:
>> >
>> > import lldbsuite.test
>> > lldbsuite.test.run_suite()
>> >
>> > the advantage of this method is that lldbsuite can contain
>> subpackages.  It already contains one subpackage, which is lldbsuite.test,
>> and I plan to move some of the Python code in `lldb/scripts` there as well,
>> so that we have lldbsuite.scripts.  Then we can add a third submodule,
>> lldbsuite.shared, and now dotest can share code with scripts, and it gives
>> us a nice place to put stuff that previously had been copied all around.
>> >
>> > It also gives us a nice way to perform module-wide initialization that
>> we don't have to repeat in every single test, such as writing "import
>> lldb_shared" at the top of every file, since that can be done as part of
>> lldbsuite/__init__.py.
>> >
>> >
>> > In any case, I have this all working on my machine, but I would like to
>> see if someone can try my patch out on other platforms.  The size of the
>> patch presents a problem though - it's over 7MB since it renames a very
>> large directory.
>> >
>> > As usual, comments / concerns also welcome.
>> > ___
>> > lldb-dev mailing list

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

[Mark Chandler via lldb-dev]

Using gcc 4.8 from devtoolset2. Clang builds fine so might try building with 
that tomorrow.

Sent from my iPhone

On Oct 27, 2015, at 7:46 PM, Oleksiy Vyalov 
mailto:ovya...@google.com>> wrote:

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 
mailto: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