[lldb-dev] [Bug 32920] Potentially premature destroying of the locker in Python interpreter
https://bugs.llvm.org/show_bug.cgi?id=32920 Tatyana Krasnukha changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|lldb-dev@lists.llvm.org |ztur...@google.com -- 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
[lldb-dev] Python scripting in Windows LLDB
Hi! I've just noticed that LLDB from the most recent LLVM Windows snapshot build has Python scripting disabled. Was this done on purpose and for what reason if so? ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] LLVM.org (SVN, web) DOWNTIME May 20th (7AM CDT -> 1PM CDT)
FYI, The llvm.org server will be down May 20th from 7AM CDT to 1PM CDT. SVN and llvm.org webpages will be unavailable. Please note that some websites and services (Mailing lists, Clang and other sub-projects, APT, releases, Bugzilla) are hosted by other servers and are not impacted. I apologize for the short notice as we had hoped to have the SVN move completed before this but even the best plans have speed bumps. -Tanya ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Python scripting in Windows LLDB
Update: looks like Python detection in CMake now requires debug binaries to be there as well (e.g. python35_d.dll), otherwise Python support gets disabled. I am wondering if Python the build machine was installed without the debug stuff. On Fri, May 19, 2017 at 10:52 AM, Vadim Chugunov wrote: > Hi! > > I've just noticed that LLDB from the most recent LLVM Windows snapshot > build has Python scripting disabled. > Was this done on purpose and for what reason if so? > ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Python scripting in Windows LLDB
Hmm, I believe it's only supposed to do that if you're doing a debug build. It should only require the Python libraries that match your current build. Is it not doing this? On Fri, May 19, 2017 at 1:15 PM Vadim Chugunov via lldb-dev < lldb-dev@lists.llvm.org> wrote: > Update: looks like Python detection in CMake now requires debug binaries > to be there as well (e.g. python35_d.dll), otherwise Python support gets > disabled. I am wondering if Python the build machine was installed without > the debug stuff. > > On Fri, May 19, 2017 at 10:52 AM, Vadim Chugunov > wrote: > >> Hi! >> >> I've just noticed that LLDB from the most recent LLVM Windows snapshot >> build has Python scripting disabled. >> Was this done on purpose and for what reason if so? >> > > ___ > 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] Python scripting in Windows LLDB
Yes, my machine doesn't have the _d.dll files. On Fri, May 19, 2017 at 1:14 PM, Vadim Chugunov wrote: > Update: looks like Python detection in CMake now requires debug binaries to > be there as well (e.g. python35_d.dll), otherwise Python support gets > disabled. I am wondering if Python the build machine was installed without > the debug stuff. > > On Fri, May 19, 2017 at 10:52 AM, Vadim Chugunov wrote: >> >> Hi! >> >> I've just noticed that LLDB from the most recent LLVM Windows snapshot >> build has Python scripting disabled. >> Was this done on purpose and for what reason if so? > > ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Python scripting in Windows LLDB
LLDBConfig.cmake has this:
if (NOT (PYTHON_DEBUG_EXE AND PYTHON_RELEASE_EXE AND PYTHON_DEBUG_LIB AND
PYTHON_RELEASE_LIB AND PYTHON_DEBUG_DLL AND PYTHON_RELEASE_DLL))
message("Python installation is corrupt. Python support will be disabled
for this build.")
set(LLDB_DISABLE_PYTHON 1 PARENT_SCOPE)
return()
endif()
Internally I’ve changed it to:
if (CMAKE_BUILD_TYPE STREQUAL "Debug")
if (NOT (PYTHON_DEBUG_EXE AND PYTHON_DEBUG_LIB AND PYTHON_DEBUG_DLL))
message("Python installation is corrupt. Python support will be disabled
for this build.")
set(LLDB_DISABLE_PYTHON 1 PARENT_SCOPE)
return()
endif()
else()
if (NOT (PYTHON_RELEASE_EXE AND PYTHON_RELEASE_LIB))
message("Python installation is corrupt. Python support will be disabled
for this build.")
set(LLDB_DISABLE_PYTHON 1 PARENT_SCOPE)
return()
endif()
endif()
That works with our buildbots building release.
Note the release check doesn’t check for the DLL – our installations don’t have
the release DLL, so I didn’t put that in.
I can push this change upstream if you’d like, Zach.
--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project
From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Zachary
Turner via lldb-dev
Sent: Friday, May 19, 2017 3:18 PM
To: Vadim Chugunov ; Hans Wennborg ; LLDB
Subject: Re: [lldb-dev] Python scripting in Windows LLDB
Hmm, I believe it's only supposed to do that if you're doing a debug build. It
should only require the Python libraries that match your current build. Is it
not doing this?
On Fri, May 19, 2017 at 1:15 PM Vadim Chugunov via lldb-dev
mailto:lldb-dev@lists.llvm.org> > wrote:
Update: looks like Python detection in CMake now requires debug binaries to be
there as well (e.g. python35_d.dll), otherwise Python support gets disabled. I
am wondering if Python the build machine was installed without the debug stuff.
On Fri, May 19, 2017 at 10:52 AM, Vadim Chugunov mailto:vadi...@gmail.com> > wrote:
Hi!
I've just noticed that LLDB from the most recent LLVM Windows snapshot build
has Python scripting disabled.
Was this done on purpose and for what reason if so?
___
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] How to prolong or duplicate a backstop breakpoint
I adapted the AppleObjcTrampolineHandler to my runtime. It works in as much as that the debugger steps over my intermediate C functions and breaks in the targetted method. Unfortunately when I step out of the method, I am not back at the ObjC call (0x00010ebf) but instead in my intermediate function. I think this is, because I am not using trampolines (jumps) but plain C functions. When I turn on `log enabled lldb step` and watch what is hapenning when lldb steps through to -[foo class] (0x00010df0) I can see this at one point in time on the thread plan stack: ``` thread #1: tid = 0x8c74: Active plan stack: Element 0: Base thread plan. Element 1: Stepping in through line class.m:44 using ranges:[0x00010ea6-0x00010ebf). Element 2: Stepping through trampoline code from: 0x00010f42 with backstop breakpoint ID: -5 at address: 0x00010ebf Element 3: Stepping to implementation of ObjC method - obj: 0x11158, isa: 0x11130, sel: 0x7fff91f58a12 Element 4: Run to address: 0x00010df0 using breakpoint: -9 - ``` There is a backstop breakpoint -5 at the address 0x00010ebf. Fine. But then, when the start of my method -[foo class] is reached, the trampoline handler is popped and the breakpoint vanishes!. I need to somehow "prolong" this backstop breakpoint. If I were to add a breakpoint to the return address (0x00010f42), I would lose the functionality, that "continue" just continues w/o breaking on the backstop. So maybe I need to push something ahead of the "step through" on the ThreadPlan stack but what ? Ciao Nat! ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Python scripting in Windows LLDB
It would be better if the build fails hard if some dependency isn't
available. I'll never notice a message about Python support being
disabled since there's so much noise in the build anyway.
On Fri, May 19, 2017 at 1:42 PM, Ted Woodward
wrote:
> LLDBConfig.cmake has this:
>
>
>
> if (NOT (PYTHON_DEBUG_EXE AND PYTHON_RELEASE_EXE AND PYTHON_DEBUG_LIB AND
> PYTHON_RELEASE_LIB AND PYTHON_DEBUG_DLL AND PYTHON_RELEASE_DLL))
>
> message("Python installation is corrupt. Python support will be disabled
> for this build.")
>
> set(LLDB_DISABLE_PYTHON 1 PARENT_SCOPE)
>
> return()
>
> endif()
>
>
>
> Internally I’ve changed it to:
>
>
>
> if (CMAKE_BUILD_TYPE STREQUAL "Debug")
>
> if (NOT (PYTHON_DEBUG_EXE AND PYTHON_DEBUG_LIB AND PYTHON_DEBUG_DLL))
>
> message("Python installation is corrupt. Python support will be
> disabled for this build.")
>
> set(LLDB_DISABLE_PYTHON 1 PARENT_SCOPE)
>
> return()
>
> endif()
>
> else()
>
> if (NOT (PYTHON_RELEASE_EXE AND PYTHON_RELEASE_LIB))
>
> message("Python installation is corrupt. Python support will be
> disabled for this build.")
>
> set(LLDB_DISABLE_PYTHON 1 PARENT_SCOPE)
>
> return()
>
> endif()
>
> endif()
>
>
>
> That works with our buildbots building release.
>
>
>
> Note the release check doesn’t check for the DLL – our installations don’t
> have the release DLL, so I didn’t put that in.
>
>
>
> I can push this change upstream if you’d like, Zach.
>
>
>
> --
>
> Qualcomm Innovation Center, Inc.
>
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
> Linux Foundation Collaborative Project
>
>
>
> From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Zachary
> Turner via lldb-dev
> Sent: Friday, May 19, 2017 3:18 PM
> To: Vadim Chugunov ; Hans Wennborg ;
> LLDB
> Subject: Re: [lldb-dev] Python scripting in Windows LLDB
>
>
>
> Hmm, I believe it's only supposed to do that if you're doing a debug build.
> It should only require the Python libraries that match your current build.
> Is it not doing this?
>
>
>
> On Fri, May 19, 2017 at 1:15 PM Vadim Chugunov via lldb-dev
> wrote:
>
> Update: looks like Python detection in CMake now requires debug binaries to
> be there as well (e.g. python35_d.dll), otherwise Python support gets
> disabled. I am wondering if Python the build machine was installed without
> the debug stuff.
>
>
>
> On Fri, May 19, 2017 at 10:52 AM, Vadim Chugunov wrote:
>
> Hi!
>
>
>
> I've just noticed that LLDB from the most recent LLVM Windows snapshot build
> has Python scripting disabled.
>
> Was this done on purpose and for what reason if so?
>
>
>
> ___
> 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] How to prolong or duplicate a backstop breakpoint
This is really an orthogonal problem to the thread plans. They are about
answering the question "how do I get from A to B?". But you want to get the
right answer to "If I land in B, do I want to stop there?" This sort of
question is answered with the "ShouldStopHere" mechanism (see
source/Target/ThreadPlanShouldStopHere.cpp). Then the Thread Plans will invoke
this mechanism whenever they are about to stop and return control to the user,
and the should stop here will decide whether to stop, and if you aren't going
to stop, how to get out of the "bad" place.
I had to solve pretty much your problem for Swift thunks, which are much like
your ObjC dispatch functions. Apparently that's a bit of code I missed when we
were moving the generic changes for swift back to llvm.org.
If you look at the Swift version of lldb:
https://github.com/apple/swift-lldb/blob/stable/source/Target/ThreadPlanShouldStopHere.cpp
You will see I added this bit to the DefaultShouldStopHereCallback (around line
88):
// Check whether the frame we are in is a language runtime thunk, only for
// step out:
if (operation == eFrameCompareOlder) {
Symbol *symbol = frame->GetSymbolContext(eSymbolContextSymbol).symbol;
if (symbol) {
LanguageRuntime *language_runtime;
bool is_thunk = false;
ProcessSP process_sp(current_plan->GetThread().GetProcess());
enum LanguageType languages_to_try[] = {
eLanguageTypeSwift, eLanguageTypeObjC, eLanguageTypeC_plus_plus};
for (enum LanguageType language : languages_to_try) {
language_runtime = process_sp->GetLanguageRuntime(language);
if (language_runtime)
is_thunk = language_runtime->IsSymbolARuntimeThunk(*symbol);
if (is_thunk) {
should_stop_here = false;
break;
}
}
}
}
I am pretty sure you should just be able to add this directly to the llvm.org
lldb, and then have your LanguageRuntime reply true to the
IsSymbolARuntimeThunk when the symbol is your dispatch function. Then the rest
of the machinery will take care of getting you out of there.
Jim
> On May 19, 2017, at 2:40 PM, Nat! via lldb-dev
> wrote:
>
> I adapted the AppleObjcTrampolineHandler to my runtime. It works in as
> much as that the debugger steps over my intermediate C functions and
> breaks in the targetted method.
>
> Unfortunately when I step out of the method, I am not back at the ObjC
> call (0x00010ebf) but instead in my intermediate function. I
> think this is, because I am not using trampolines (jumps) but plain C
> functions.
>
> When I turn on `log enabled lldb step` and watch what is hapenning when
> lldb steps through to -[foo class] (0x00010df0)
> I can see this at one point in time on the thread plan stack:
>
> ```
> thread #1: tid = 0x8c74:
>Active plan stack:
> Element 0: Base thread plan.
> Element 1: Stepping in through line class.m:44 using
> ranges:[0x00010ea6-0x00010ebf).
>
> Element 2: Stepping through trampoline code from:
> 0x00010f42 with backstop breakpoint ID: -5 at address:
> 0x00010ebf
>
> Element 3: Stepping to implementation of ObjC method - obj:
> 0x11158, isa: 0x11130, sel: 0x7fff91f58a12
> Element 4: Run to address: 0x00010df0 using breakpoint: -9 -
> ```
>
> There is a backstop breakpoint -5 at the address 0x00010ebf.
> Fine. But then, when the start of my method -[foo class] is reached,
> the trampoline handler is popped and the breakpoint vanishes!. I need to
> somehow "prolong" this backstop breakpoint.
>
> If I were to add a breakpoint to the return address
> (0x00010f42), I would lose the functionality, that "continue"
> just continues w/o breaking on the backstop. So maybe I need to push
> something ahead of the "step through" on the ThreadPlan stack but what ?
>
> Ciao
> Nat!
>
> ___
> 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] How to prolong or duplicate a backstop breakpoint
Hi Jim, Thanks! I didn't know about ThreadPlanShouldStopHere. And your swift-lldb code does exactly, what I am looking for. Ciao Nat! ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
