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_L
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 ov
> 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'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
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
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
https://llvm.org/bugs/show_bug.cgi?id=25039
Todd Fiala changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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 2
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
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
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=..."
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 i
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 DCMAK
13 matches
Mail list logo