[lldb-dev] [Bug 25346] New: Python/C++ binding SBTarget.LaunchSimple does not disable ASLR

2015-10-29 Thread via lldb-dev
https://llvm.org/bugs/show_bug.cgi?id=25346

Bug ID: 25346
   Summary: Python/C++ binding SBTarget.LaunchSimple does not
disable ASLR
   Product: lldb
   Version: unspecified
  Hardware: Macintosh
OS: MacOS X
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: felber.jonas+l...@gmail.com
CC: llvm-b...@lists.llvm.org
Classification: Unclassified

more on
http://stackoverflow.com/questions/33394623/lldb-python-c-binding-set-breakpoint-at-pic-addr

[~]$ lldb --version
lldb-340.4.110

-- 
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] Compiling LLDB on Centos 5 (dont judge me)

2015-10-29 Thread Todd Fiala via lldb-dev
I fixed several RHEL-derived distribution-related issues in top of tree
LLDB a few weeks back.  It was for RHEL 7-derived builds, so quite a bit
newer.  If you are building your lldb off of top-of-tree, hopefully this
will mostly become an exercise of:

* Do you have a new-enough python.  (I believe at this point you really
want a 2.7, but with CentOS 5 you might be far back enough to be 2.4 or
2.6.  We probably limp along with 2.6 since that was our baseline for a
while).  Worst case here you can download a newer python and build from
source, then specify it to cmake via the right python cmake variables.

* Do you have a new-enough c++ compiler.  Since you're able to build a
clang, that should take care of that issue.

* Other libs you'll need.  I needed to install these:

yum install libedit-devel
yum install python-devel
yum install ncurses-devel
yum install swig
yum install libxml2-devel

* cmake - you'll need cmake 2.8.12.2 or later.  This one I'm pretty
sure you're going to need to build this from scratch.

* ninja - you're going to want to build the ninja build tool to
optimize your build speed and use -GNinja with your cmake command
line.

It'll be interesting to hear what else you find.


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

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


-- 
-Todd
___
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

2015-10-29 Thread Todd Fiala via lldb-dev
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.
>
>
Hey Zachary,

Sorry I missed this.  I *think* you have this all worked out, right?

I think the way to fix this is:

* top-level dotest.py just imports whatever is needed and calls it
(something from the package, that is basically the contents of the old
dotest.py).

* The new dotest.py (inside the package) does what it used to do, calling
dosep.py when it is a concurrent run.

* Dosep.py would call the top level dotest.py when execing, with the right
flags as before to indicate that the new run is a dotest.py inferior.

I think that would do it and still get your initialization.

-Todd


> 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

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

2015-10-29 Thread Mark Chandler via lldb-dev

For My Centos 5 build:

* Using python 2.7 (From devtoolset 2)

* Using gcc 4.8 (From devtoolset 2)

* disabled libedit and python bindings

* Built cmake from source

* Make is fine so didnt bother with ninja


Applying the patch then gives me a working liblldb.so.


Also want to say that its refreshing seeing such a good api. The interface is 
easy to understand and is standalone without pulling in a bunch of complex 
types from other libraries. Well done lldb team!


Mark



From: Todd Fiala 
Sent: Thursday, October 29, 2015 4:17 PM
To: Mark Chandler
Cc: Oleksiy Vyalov; lldb-dev@lists.llvm.org
Subject: Re: [lldb-dev] Compiling LLDB on Centos 5 (dont judge me)

I fixed several RHEL-derived distribution-related issues in top of tree LLDB a 
few weeks back.  It was for RHEL 7-derived builds, so quite a bit newer.  If 
you are building your lldb off of top-of-tree, hopefully this will mostly 
become an exercise of:

* Do you have a new-enough python.  (I believe at this point you really want a 
2.7, but with CentOS 5 you might be far back enough to be 2.4 or 2.6.  We 
probably limp along with 2.6 since that was our baseline for a while).  Worst 
case here you can download a newer python and build from source, then specify 
it to cmake via the right python cmake variables.

* Do you have a new-enough c++ compiler.  Since you're able to build a clang, 
that should take care of that issue.

* Other libs you'll need.  I needed to install these:

yum install libedit-devel
yum install python-devel
yum install ncurses-devel
yum install swig
yum install libxml2-devel

* cmake - you'll need cmake 2.8.12.2 or later.  This one I'm pretty sure you're 
going to need to build this from scratch.

* ninja - you're going to want to build the ninja build tool to optimize your 
build speed and use -GNinja with your cmake command line.

It'll be interesting to hear what else you find.

On Tue, Oct 27, 2015 at 8:37 PM, Mark Chandler via lldb-dev 
mailto:lldb-dev@lists.llvm.org>> wrote:
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




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