[Lldb-commits] [lldb] r265524 - Fixup r265398
Author: labath Date: Wed Apr 6 03:55:31 2016 New Revision: 265524 URL: http://llvm.org/viewvc/llvm-project?rev=265524&view=rev Log: Fixup r265398 Modified: lldb/trunk/packages/Python/lldbsuite/test/lldbutil.py Modified: lldb/trunk/packages/Python/lldbsuite/test/lldbutil.py URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/lldbutil.py?rev=265524&r1=265523&r2=265524&view=diff == --- lldb/trunk/packages/Python/lldbsuite/test/lldbutil.py (original) +++ lldb/trunk/packages/Python/lldbsuite/test/lldbutil.py Wed Apr 6 03:55:31 2016 @@ -12,6 +12,7 @@ import collections import os import re import sys +import time # Third-party modules from six import StringIO as SixStringIO ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D18692: Fix a cornercase in breakpoint reporting
This revision was automatically updated to reflect the committed changes.
Closed by commit rL265525: Fix a cornercase in breakpoint reporting (authored
by labath).
Changed prior to commit:
http://reviews.llvm.org/D18692?vs=52357&id=52771#toc
Repository:
rL LLVM
http://reviews.llvm.org/D18692
Files:
lldb/trunk/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
Index: lldb/trunk/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
===
--- lldb/trunk/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
+++ lldb/trunk/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
@@ -2089,6 +2089,23 @@
handled = true;
}
}
+else if (!signo)
+{
+addr_t pc = thread_sp->GetRegisterContext()->GetPC();
+lldb::BreakpointSiteSP bp_site_sp =
+
thread_sp->GetProcess()->GetBreakpointSiteList().FindByAddress(pc);
+
+// If the current pc is a breakpoint site then the
StopInfo should be set to Breakpoint
+// even though the remote stub did not set it as such.
This can happen when
+// the thread is involuntarily interrupted (e.g. due
to stops on other
+// threads) just as it is about to execute the
breakpoint instruction.
+if (bp_site_sp &&
bp_site_sp->ValidForThisThread(thread_sp.get()))
+{
+thread_sp->SetStopInfo(
+
StopInfo::CreateStopReasonWithBreakpointSiteID(*thread_sp,
bp_site_sp->GetID()));
+handled = true;
+}
+}
if (!handled && signo && did_exec == false)
{
Index: lldb/trunk/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
===
--- lldb/trunk/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
+++ lldb/trunk/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
@@ -2089,6 +2089,23 @@
handled = true;
}
}
+else if (!signo)
+{
+addr_t pc = thread_sp->GetRegisterContext()->GetPC();
+lldb::BreakpointSiteSP bp_site_sp =
+thread_sp->GetProcess()->GetBreakpointSiteList().FindByAddress(pc);
+
+// If the current pc is a breakpoint site then the StopInfo should be set to Breakpoint
+// even though the remote stub did not set it as such. This can happen when
+// the thread is involuntarily interrupted (e.g. due to stops on other
+// threads) just as it is about to execute the breakpoint instruction.
+if (bp_site_sp && bp_site_sp->ValidForThisThread(thread_sp.get()))
+{
+thread_sp->SetStopInfo(
+StopInfo::CreateStopReasonWithBreakpointSiteID(*thread_sp, bp_site_sp->GetID()));
+handled = true;
+}
+}
if (!handled && signo && did_exec == false)
{
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r265525 - Fix a cornercase in breakpoint reporting
Author: labath
Date: Wed Apr 6 04:10:29 2016
New Revision: 265525
URL: http://llvm.org/viewvc/llvm-project?rev=265525&view=rev
Log:
Fix a cornercase in breakpoint reporting
Summary:
This resolves a similar problem as D16720 (which handled the case when we
single-step onto a
breakpoint), but this one deals with involutary stops: when we stop a thread
(e.g. because
another thread has hit a breakpont and we are doing a full stop), we can end up
stopping it right
before it executes a breakpoint instruction. In this case, the stop reason will
be empty, but we
will still step over the breakpoint when do the next resume, thereby missing a
breakpoint hit.
I have observed this happening in TestConcurrentEvents, but I have no idea how
to reproduce this
behavior more reliably.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D18692
Modified:
lldb/trunk/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
Modified: lldb/trunk/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp?rev=265525&r1=265524&r2=265525&view=diff
==
--- lldb/trunk/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp (original)
+++ lldb/trunk/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp Wed Apr
6 04:10:29 2016
@@ -2089,6 +2089,23 @@ ProcessGDBRemote::SetThreadStopInfo (lld
handled = true;
}
}
+else if (!signo)
+{
+addr_t pc = thread_sp->GetRegisterContext()->GetPC();
+lldb::BreakpointSiteSP bp_site_sp =
+
thread_sp->GetProcess()->GetBreakpointSiteList().FindByAddress(pc);
+
+// If the current pc is a breakpoint site then the
StopInfo should be set to Breakpoint
+// even though the remote stub did not set it as such.
This can happen when
+// the thread is involuntarily interrupted (e.g. due
to stops on other
+// threads) just as it is about to execute the
breakpoint instruction.
+if (bp_site_sp &&
bp_site_sp->ValidForThisThread(thread_sp.get()))
+{
+thread_sp->SetStopInfo(
+
StopInfo::CreateStopReasonWithBreakpointSiteID(*thread_sp,
bp_site_sp->GetID()));
+handled = true;
+}
+}
if (!handled && signo && did_exec == false)
{
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D18819: Reduce code duplication in ProcessGDBRemote
labath created this revision.
labath added a reviewer: clayborg.
labath added a subscriber: lldb-commits.
SetThreadStopInfo was checking for a breakpoint at the current PC several
times. This merges the
identical code into a separate function. I've left one breakpoint check alone,
as it was doing
more complicated stuff, and it did not see a way to merge that without making
the interface
complicated. NFC.
http://reviews.llvm.org/D18819
Files:
source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
source/Plugins/Process/gdb-remote/ProcessGDBRemote.h
Index: source/Plugins/Process/gdb-remote/ProcessGDBRemote.h
===
--- source/Plugins/Process/gdb-remote/ProcessGDBRemote.h
+++ source/Plugins/Process/gdb-remote/ProcessGDBRemote.h
@@ -481,6 +481,9 @@
lldb::user_id_t break_id,
lldb::user_id_t break_loc_id);
+bool
+SetThreadStopReasonIfAtBreakpoint(Thread &thread);
+
DISALLOW_COPY_AND_ASSIGN (ProcessGDBRemote);
};
Index: source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
===
--- source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
+++ source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
@@ -2009,40 +2009,15 @@
{
if (reason.compare("trace") == 0)
{
-addr_t pc = thread_sp->GetRegisterContext()->GetPC();
-lldb::BreakpointSiteSP bp_site_sp = thread_sp->GetProcess()->GetBreakpointSiteList().FindByAddress(pc);
-
-// If the current pc is a breakpoint site then the StopInfo should be set to Breakpoint
-// Otherwise, it will be set to Trace.
-if (bp_site_sp && bp_site_sp->ValidForThisThread(thread_sp.get()))
-{
-thread_sp->SetStopInfo(
-StopInfo::CreateStopReasonWithBreakpointSiteID(*thread_sp, bp_site_sp->GetID()));
-}
-else
- thread_sp->SetStopInfo (StopInfo::CreateStopReasonToTrace (*thread_sp));
+if (!SetThreadStopReasonIfAtBreakpoint(*thread_sp))
+thread_sp->SetStopInfo(StopInfo::CreateStopReasonToTrace(*thread_sp));
handled = true;
}
else if (reason.compare("breakpoint") == 0)
{
-addr_t pc = thread_sp->GetRegisterContext()->GetPC();
-lldb::BreakpointSiteSP bp_site_sp = thread_sp->GetProcess()->GetBreakpointSiteList().FindByAddress(pc);
-if (bp_site_sp)
-{
-// If the breakpoint is for this thread, then we'll report the hit, but if it is for another thread,
-// we can just report no reason. We don't need to worry about stepping over the breakpoint here, that
-// will be taken care of when the thread resumes and notices that there's a breakpoint under the pc.
-handled = true;
-if (bp_site_sp->ValidForThisThread (thread_sp.get()))
-{
-thread_sp->SetStopInfo (StopInfo::CreateStopReasonWithBreakpointSiteID (*thread_sp, bp_site_sp->GetID()));
-}
-else
-{
-StopInfoSP invalid_stop_info_sp;
-thread_sp->SetStopInfo (invalid_stop_info_sp);
-}
-}
+if (!SetThreadStopReasonIfAtBreakpoint(*thread_sp))
+thread_sp->SetStopInfo(StopInfoSP());
+handled = true;
}
else if (reason.compare("trap") == 0)
{
@@ -2091,20 +2066,12 @@
}
else if (!signo)
{
-addr_t pc = thread_sp->GetRegisterContext()->GetPC();
-lldb::BreakpointSiteSP bp_site_sp =
-thread_sp->GetProcess()->GetBreakpointSiteList().FindByAddress(pc);
-
// If the current pc is a breakpoint site then the StopInfo should be set to Breakpoint
// even though the remote stub did not set it as such. This can happen when
// the thread is involuntarily interrupted (e.g. due to stops on other
[Lldb-commits] [lldb] r265527 - Fix and xfail TestRegisterVariables after rL265498
Author: tberghammer Date: Wed Apr 6 05:34:29 2016 New Revision: 265527 URL: http://llvm.org/viewvc/llvm-project?rev=265527&view=rev Log: Fix and xfail TestRegisterVariables after rL265498 Modified: lldb/trunk/packages/Python/lldbsuite/test/lang/c/register_variables/Makefile lldb/trunk/packages/Python/lldbsuite/test/lang/c/register_variables/TestRegisterVariables.py Modified: lldb/trunk/packages/Python/lldbsuite/test/lang/c/register_variables/Makefile URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/lang/c/register_variables/Makefile?rev=265527&r1=265526&r2=265527&view=diff == --- lldb/trunk/packages/Python/lldbsuite/test/lang/c/register_variables/Makefile (original) +++ lldb/trunk/packages/Python/lldbsuite/test/lang/c/register_variables/Makefile Wed Apr 6 05:34:29 2016 @@ -2,12 +2,6 @@ LEVEL = ../../../make C_SOURCES := test.c -CFLAGS := -g -O1 - -$(info OS: $(OS)) -HOST_OS = $(shell uname -s) -ifeq "$(HOST_OS)" "Darwin" - FRAMEWORK_INCLUDES = -isysroot $(shell xcrun -show-sdk-path) -endif +CFLAGS_EXTRAS += -O1 include $(LEVEL)/Makefile.rules Modified: lldb/trunk/packages/Python/lldbsuite/test/lang/c/register_variables/TestRegisterVariables.py URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/lang/c/register_variables/TestRegisterVariables.py?rev=265527&r1=265526&r2=265527&view=diff == --- lldb/trunk/packages/Python/lldbsuite/test/lang/c/register_variables/TestRegisterVariables.py (original) +++ lldb/trunk/packages/Python/lldbsuite/test/lang/c/register_variables/TestRegisterVariables.py Wed Apr 6 05:34:29 2016 @@ -92,7 +92,8 @@ class RegisterVariableTestCase(TestBase) @expectedFailureAll(compiler="clang", compiler_version=['<', '3.5']) -@expectedFailureAll(compiler="gcc", compiler_version=['=', '4.8.2']) +@expectedFailureAll(compiler="gcc", compiler_version=['>=', '4.8.2']) +@expectedFailureAll(oslist="linux", archs="i386") def test_and_run_command(self): """Test expressions on register values.""" ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [Diffusion] rL265498: make TestRegisterVariables slightly more resilient
tberghammer added subscribers: lldb-commits, tberghammer. tberghammer added a comment. This CL caused a lot of breakage across various Linux/Android builders. I created a fix at http://reviews.llvm.org/rL265527 but please verify it is still working with OSX after that /lldb/trunk/packages/Python/lldbsuite/test/lang/c/register_variables/Makefile:7-11 This change breaks the test for remote debugging when running from OSX to anything else (e.g. android) as the cross compilers don't need this flag. Why you need this here and not in any of the other tests? Users: tfiala (Author) http://reviews.llvm.org/rL265498 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r265529 - Fixup TestLinuxCore on windows
Author: labath
Date: Wed Apr 6 06:05:30 2016
New Revision: 265529
URL: http://llvm.org/viewvc/llvm-project?rev=265529&view=rev
Log:
Fixup TestLinuxCore on windows
test_same_pid_running couldn't delete the temporary files, while we had them
open. Deleting the
target should make things work.
Modified:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/postmortem/linux-core/TestLinuxCore.py
Modified:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/postmortem/linux-core/TestLinuxCore.py
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/postmortem/linux-core/TestLinuxCore.py?rev=265529&r1=265528&r2=265529&view=diff
==
---
lldb/trunk/packages/Python/lldbsuite/test/functionalities/postmortem/linux-core/TestLinuxCore.py
(original)
+++
lldb/trunk/packages/Python/lldbsuite/test/functionalities/postmortem/linux-core/TestLinuxCore.py
Wed Apr 6 06:05:30 2016
@@ -92,3 +92,5 @@ class LinuxCoreTestCase(TestBase):
self.assertEqual(frame.GetLineEntry().GetLine(),
line_number("main.c", "Frame " + backtrace[i]))
self.assertEqual(frame.FindVariable("F").GetValueAsUnsigned(),
ord(backtrace[i][0]))
+
+self.dbg.DeleteTarget(target)
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [Diffusion] rL265498: make TestRegisterVariables slightly more resilient
I think it's the -O1 that is screwing it up. The test relies on setting the optimization level, and then screws up the compiler's ability to find the framework headers with more recent clangs on OS X (both in-tree built and Xcode-delivered). Ultimately OS X has been shifting where the /usr/include files have been delivered for a while, and this then requires telling clang where to find them one way or another. Thanks for fixing. I can dig into that more and make it cleaner, I had some code in the Makefile.rules that normally handles that but wasn't for some reason. I'll have to look at what failed. The change to the Makefile was instigated by OS X hitting an error on build when building with the in-tree clang. -Todd On Wed, Apr 6, 2016 at 3:41 AM, Tamas Berghammer wrote: > tberghammer added subscribers: lldb-commits, tberghammer. > tberghammer added a comment. > > This CL caused a lot of breakage across various Linux/Android builders. I > created a fix at http://reviews.llvm.org/rL265527 but please verify it is > still working with OSX after that > > > /lldb/trunk/packages/Python/lldbsuite/test/lang/c/register_variables/Makefile:7-11 > This change breaks the test for remote debugging when running from OSX to > anything else (e.g. android) as the cross compilers don't need this flag. > Why you need this here and not in any of the other tests? > > Users: > tfiala (Author) > > http://reviews.llvm.org/rL265498 > > > > -- -Todd ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [Diffusion] rL265498: make TestRegisterVariables slightly more resilient
tfiala added a subscriber: tfiala. tfiala added a comment. I think it's the -O1 that is screwing it up. The test relies on setting the optimization level, and then screws up the compiler's ability to find the framework headers with more recent clangs on OS X (both in-tree built and Xcode-delivered). Ultimately OS X has been shifting where the /usr/include files have been delivered for a while, and this then requires telling clang where to find them one way or another. Thanks for fixing. I can dig into that more and make it cleaner, I had some code in the Makefile.rules that normally handles that but wasn't for some reason. I'll have to look at what failed. The change to the Makefile was instigated by OS X hitting an error on build when building with the in-tree clang. -Todd Users: tfiala (Author) http://reviews.llvm.org/rL265498 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [Diffusion] rL265498: make TestRegisterVariables slightly more resilient
tberghammer added a comment. My guess is the root cause of the problem is that we are setting CFLAGS instead of appending to CLAFGS_EXTRA (I changed it in my followup CL) Users: tfiala (Author) http://reviews.llvm.org/rL265498 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [Diffusion] rL265498: make TestRegisterVariables slightly more resilient
CFLAGS_EXTRA didn't work because it then gets both -O0 and -O1 (for the majority of our tests, Makefile.rules correctly assumes optimizations are turned off for maximal debug info). If that was the fix, that is circumventing the check this test is doing. What we really need (and I'll go back and add) is an explicit optimization level variable for Makefile.rules that defaults to -O0 but allows overriding. That would most likely address this. I'll go back to that once I'm done with another task. Thanks! -Todd On Wed, Apr 6, 2016 at 7:27 AM, Tamas Berghammer wrote: > tberghammer added a comment. > > My guess is the root cause of the problem is that we are setting CFLAGS > instead of appending to CLAFGS_EXTRA (I changed it in my followup CL) > > > Users: > tfiala (Author) > > http://reviews.llvm.org/rL265498 > > > > -- -Todd ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [Diffusion] rL265498: make TestRegisterVariables slightly more resilient
tfiala added a comment. CFLAGS_EXTRA didn't work because it then gets both -O0 and -O1 (for the majority of our tests, Makefile.rules correctly assumes optimizations are turned off for maximal debug info). If that was the fix, that is circumventing the check this test is doing. What we really need (and I'll go back and add) is an explicit optimization level variable for Makefile.rules that defaults to -O0 but allows overriding. That would most likely address this. I'll go back to that once I'm done with another task. Thanks! -Todd Users: tfiala (Author) http://reviews.llvm.org/rL265498 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [Diffusion] rL265498: make TestRegisterVariables slightly more resilient
(And sorry for the breakage! I didn't see any nag mails). On Wed, Apr 6, 2016 at 7:34 AM, Todd Fiala wrote: > CFLAGS_EXTRA didn't work because it then gets both -O0 and -O1 (for the > majority of our tests, Makefile.rules correctly assumes optimizations are > turned off for maximal debug info). If that was the fix, that is > circumventing the check this test is doing. > > What we really need (and I'll go back and add) is an explicit optimization > level variable for Makefile.rules that defaults to -O0 but allows > overriding. That would most likely address this. I'll go back to that > once I'm done with another task. > > Thanks! > > -Todd > > On Wed, Apr 6, 2016 at 7:27 AM, Tamas Berghammer > wrote: > >> tberghammer added a comment. >> >> My guess is the root cause of the problem is that we are setting CFLAGS >> instead of appending to CLAFGS_EXTRA (I changed it in my followup CL) >> >> >> Users: >> tfiala (Author) >> >> http://reviews.llvm.org/rL265498 >> >> >> >> > > > -- > -Todd > -- -Todd ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [Diffusion] rL265498: make TestRegisterVariables slightly more resilient
tfiala added a comment. (And sorry for the breakage! I didn't see any nag mails). Users: tfiala (Author) http://reviews.llvm.org/rL265498 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [lldb] r265461 - XFail TestImport.py on Windows because Python 3 import rules don't work that way.
It will still be a bit of a trick to change the `command script import` handling to do `from foo import blah` in the general case, since foo can't really be an absolute file path. And does the `from __future__ import absolute_import` really belong in the script your importing? Or does it belong in the temp script that's written to do the import? I would have thought the latter from everything I read yesterday. On Tue, Apr 5, 2016 at 6:29 PM, Zachary Turner wrote: > Afaik there's no way to do from future imports with the c api, and > executing the statement with RunOneLine doesn't do it either, it has to be > in the script because it's treated specially by the interpreter. > > There might be a way to do it with some tricks that I didn't figure out > last time. > > If its any consolation, it would only be needed for shared/builtin > formatters. > > I guess it would help to get a better understanding of what the problem > is, if someone files a bug against me (or i can file it myself tomorrow) i > can investigate after I finish PDB stuff. > > In the meantime having it in seems like the best option imo > > On Tue, Apr 5, 2016 at 5:54 PM Jim Ingham wrote: > >> Will this be necessary for everybody who uses "command script import" >> with Python 3? If so, it would be really nice to do this work in "command >> script import" if possible. Otherwise everybody will have to put this goo >> at the top of every .py file they write for formatters & breakpoint >> commands and the like. >> >> Jim >> >> >> > On Apr 5, 2016, at 5:30 PM, Zachary Turner via lldb-commits < >> lldb-commits@lists.llvm.org> wrote: >> > >> > Yea I wasn't sure if the . would be necessary or not. If you write >> "from __future__ import absolute_import" at the top of each of these python >> files (foo.py and foo2.py or whatever they're called) then this should >> guarantee that the behavior is the same in both Python 2 and Python 3 >> > >> > On Tue, Apr 5, 2016 at 4:01 PM Adrian McCarthy >> wrote: >> > "error: module importing failed: Parent module '' not loaded, cannot >> perform relative import" >> > >> > If you omit the dot (i.e., `from foo import foo2`), it appears to work, >> but I'm not sure that does the right thing. I'll keep investigating. >> > >> > On Tue, Apr 5, 2016 at 3:40 PM, Zachary Turner >> wrote: >> > Without the modification to sys.path >> > >> > On Tue, Apr 5, 2016 at 3:39 PM Zachary Turner >> wrote: >> > Can you try to change "import foo2" to "from .foo import foo2" >> > On Tue, Apr 5, 2016 at 2:52 PM Adrian McCarthy >> wrote: >> > I've drilled down into the Python import statement. It's in >> ScriptInterpreterPython::LoadScriptingModule. The function inserts the >> diretory into sys.path and then issues a vanilla Python import statement. >> > >> > I spoke with one of our local Python experts who said that this >> technique to specify the directory is probably unreliable, as the rules for >> where Python looks for modules has evolved. The rules for both relative >> and absolute module paths changed from Python 2 to 3. >> > >> > I'll revert the xfail if you want. But this has been broken for quite >> a while (as has another test, which I'm looking into now). >> > >> > On Tue, Apr 5, 2016 at 2:29 PM, Zachary Turner >> wrote: >> > I think we need some more information before we xfail this. It would >> help to drill down to either the python import statement or the >> PyImport_ImportModule C api call that actually does the import. >> > >> > If you can get that, i can help come up with a fix. Just need to step >> through the execution of the command until you get to the python or c code >> that tries to do the import >> > >> > On Tue, Apr 5, 2016 at 1:54 PM Adrian McCarthy via lldb-commits < >> lldb-commits@lists.llvm.org> wrote: >> > Author: amccarth >> > Date: Tue Apr 5 15:49:09 2016 >> > New Revision: 265461 >> > >> > URL: http://llvm.org/viewvc/llvm-project?rev=265461&view=rev >> > Log: >> > XFail TestImport.py on Windows because Python 3 import rules don't work >> that way. >> > >> > Modified: >> > >> >> lldb/trunk/packages/Python/lldbsuite/test/functionalities/command_script/import/TestImport.py >> > >> > Modified: >> lldb/trunk/packages/Python/lldbsuite/test/functionalities/command_script/import/TestImport.py >> > URL: >> http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/command_script/import/TestImport.py?rev=265461&r1=265460&r2=265461&view=diff >> > >> == >> > --- >> lldb/trunk/packages/Python/lldbsuite/test/functionalities/command_script/import/TestImport.py >> (original) >> > +++ >> lldb/trunk/packages/Python/lldbsuite/test/functionalities/command_script/import/TestImport.py >> Tue Apr 5 15:49:09 2016 >> > @@ -16,6 +16,7 @@ class ImportTestCase(TestBase): >> > >> > @add_test_categories(['pyapi']) >> > @no_debug_info_test >> > +@expectedFailureAll(oslist=["windows"], bug
Re: [Lldb-commits] [lldb] r265461 - XFail TestImport.py on Windows because Python 3 import rules don't work that way.
Well, it would belong anywhere that does an import, so in theory it belongs
in every script. In the general case, for example if you are like this:
foo
|-- bar
| baz
|-- biz.py
And you are in foo and you want to import biz.py, you could do "from
bar.baz import biz". So you just get the relative path (bar/baz/biz.py),
split the filename / path and remove the extension {bar/baz, biz}, replace
/ with . and construct your import statement that way. That's if you're
generating a script to run. Which I still think is an odd thing to do,
since we could just run Python C API calls directly which do the right
things.
On Wed, Apr 6, 2016 at 7:53 AM Adrian McCarthy wrote:
> It will still be a bit of a trick to change the `command script import`
> handling to do `from foo import blah` in the general case, since foo can't
> really be an absolute file path.
>
> And does the `from __future__ import absolute_import` really belong in the
> script your importing? Or does it belong in the temp script that's written
> to do the import? I would have thought the latter from everything I read
> yesterday.
>
> On Tue, Apr 5, 2016 at 6:29 PM, Zachary Turner wrote:
>
>> Afaik there's no way to do from future imports with the c api, and
>> executing the statement with RunOneLine doesn't do it either, it has to be
>> in the script because it's treated specially by the interpreter.
>>
>> There might be a way to do it with some tricks that I didn't figure out
>> last time.
>>
>> If its any consolation, it would only be needed for shared/builtin
>> formatters.
>>
>> I guess it would help to get a better understanding of what the problem
>> is, if someone files a bug against me (or i can file it myself tomorrow) i
>> can investigate after I finish PDB stuff.
>>
>> In the meantime having it in seems like the best option imo
>>
>> On Tue, Apr 5, 2016 at 5:54 PM Jim Ingham wrote:
>>
>>> Will this be necessary for everybody who uses "command script import"
>>> with Python 3? If so, it would be really nice to do this work in "command
>>> script import" if possible. Otherwise everybody will have to put this goo
>>> at the top of every .py file they write for formatters & breakpoint
>>> commands and the like.
>>>
>>> Jim
>>>
>>>
>>> > On Apr 5, 2016, at 5:30 PM, Zachary Turner via lldb-commits <
>>> lldb-commits@lists.llvm.org> wrote:
>>> >
>>> > Yea I wasn't sure if the . would be necessary or not. If you write
>>> "from __future__ import absolute_import" at the top of each of these python
>>> files (foo.py and foo2.py or whatever they're called) then this should
>>> guarantee that the behavior is the same in both Python 2 and Python 3
>>> >
>>> > On Tue, Apr 5, 2016 at 4:01 PM Adrian McCarthy
>>> wrote:
>>> > "error: module importing failed: Parent module '' not loaded, cannot
>>> perform relative import"
>>> >
>>> > If you omit the dot (i.e., `from foo import foo2`), it appears to
>>> work, but I'm not sure that does the right thing. I'll keep investigating.
>>> >
>>> > On Tue, Apr 5, 2016 at 3:40 PM, Zachary Turner
>>> wrote:
>>> > Without the modification to sys.path
>>> >
>>> > On Tue, Apr 5, 2016 at 3:39 PM Zachary Turner
>>> wrote:
>>> > Can you try to change "import foo2" to "from .foo import foo2"
>>> > On Tue, Apr 5, 2016 at 2:52 PM Adrian McCarthy
>>> wrote:
>>> > I've drilled down into the Python import statement. It's in
>>> ScriptInterpreterPython::LoadScriptingModule. The function inserts the
>>> diretory into sys.path and then issues a vanilla Python import statement.
>>> >
>>> > I spoke with one of our local Python experts who said that this
>>> technique to specify the directory is probably unreliable, as the rules for
>>> where Python looks for modules has evolved. The rules for both relative
>>> and absolute module paths changed from Python 2 to 3.
>>> >
>>> > I'll revert the xfail if you want. But this has been broken for quite
>>> a while (as has another test, which I'm looking into now).
>>> >
>>> > On Tue, Apr 5, 2016 at 2:29 PM, Zachary Turner
>>> wrote:
>>> > I think we need some more information before we xfail this. It would
>>> help to drill down to either the python import statement or the
>>> PyImport_ImportModule C api call that actually does the import.
>>> >
>>> > If you can get that, i can help come up with a fix. Just need to step
>>> through the execution of the command until you get to the python or c code
>>> that tries to do the import
>>> >
>>> > On Tue, Apr 5, 2016 at 1:54 PM Adrian McCarthy via lldb-commits <
>>> lldb-commits@lists.llvm.org> wrote:
>>> > Author: amccarth
>>> > Date: Tue Apr 5 15:49:09 2016
>>> > New Revision: 265461
>>> >
>>> > URL: http://llvm.org/viewvc/llvm-project?rev=265461&view=rev
>>> > Log:
>>> > XFail TestImport.py on Windows because Python 3 import rules don't
>>> work that way.
>>> >
>>> > Modified:
>>> >
>>>
>>> lldb/trunk/packages/Python/lldbsuite/test/functionalities/command_script/import/TestImport.py
>>> >
>>> > Modified:
>>> lldb/t
Re: [Lldb-commits] [lldb] r265461 - XFail TestImport.py on Windows because Python 3 import rules don't work that way.
BTW, the same test fails on our windows->android buildbot (which still
uses python 2). I haven't investigated the issue yet, I'm writing it
just as an additional data point...
cheers,
pl
On 6 April 2016 at 16:19, Zachary Turner via lldb-commits
wrote:
> Well, it would belong anywhere that does an import, so in theory it belongs
> in every script. In the general case, for example if you are like this:
>
> foo
> |-- bar
> | baz
> |-- biz.py
>
> And you are in foo and you want to import biz.py, you could do "from bar.baz
> import biz". So you just get the relative path (bar/baz/biz.py), split the
> filename / path and remove the extension {bar/baz, biz}, replace / with .
> and construct your import statement that way. That's if you're generating a
> script to run. Which I still think is an odd thing to do, since we could
> just run Python C API calls directly which do the right things.
>
> On Wed, Apr 6, 2016 at 7:53 AM Adrian McCarthy wrote:
>>
>> It will still be a bit of a trick to change the `command script import`
>> handling to do `from foo import blah` in the general case, since foo can't
>> really be an absolute file path.
>>
>> And does the `from __future__ import absolute_import` really belong in the
>> script your importing? Or does it belong in the temp script that's written
>> to do the import? I would have thought the latter from everything I read
>> yesterday.
>>
>> On Tue, Apr 5, 2016 at 6:29 PM, Zachary Turner wrote:
>>>
>>> Afaik there's no way to do from future imports with the c api, and
>>> executing the statement with RunOneLine doesn't do it either, it has to be
>>> in the script because it's treated specially by the interpreter.
>>>
>>> There might be a way to do it with some tricks that I didn't figure out
>>> last time.
>>>
>>> If its any consolation, it would only be needed for shared/builtin
>>> formatters.
>>>
>>> I guess it would help to get a better understanding of what the problem
>>> is, if someone files a bug against me (or i can file it myself tomorrow) i
>>> can investigate after I finish PDB stuff.
>>>
>>> In the meantime having it in seems like the best option imo
>>>
>>> On Tue, Apr 5, 2016 at 5:54 PM Jim Ingham wrote:
Will this be necessary for everybody who uses "command script import"
with Python 3? If so, it would be really nice to do this work in "command
script import" if possible. Otherwise everybody will have to put this goo
at the top of every .py file they write for formatters & breakpoint
commands
and the like.
Jim
> On Apr 5, 2016, at 5:30 PM, Zachary Turner via lldb-commits
> wrote:
>
> Yea I wasn't sure if the . would be necessary or not. If you write
> "from __future__ import absolute_import" at the top of each of these
> python
> files (foo.py and foo2.py or whatever they're called) then this should
> guarantee that the behavior is the same in both Python 2 and Python 3
>
> On Tue, Apr 5, 2016 at 4:01 PM Adrian McCarthy
> wrote:
> "error: module importing failed: Parent module '' not loaded, cannot
> perform relative import"
>
> If you omit the dot (i.e., `from foo import foo2`), it appears to
> work, but I'm not sure that does the right thing. I'll keep
> investigating.
>
> On Tue, Apr 5, 2016 at 3:40 PM, Zachary Turner
> wrote:
> Without the modification to sys.path
>
> On Tue, Apr 5, 2016 at 3:39 PM Zachary Turner
> wrote:
> Can you try to change "import foo2" to "from .foo import foo2"
> On Tue, Apr 5, 2016 at 2:52 PM Adrian McCarthy
> wrote:
> I've drilled down into the Python import statement. It's in
> ScriptInterpreterPython::LoadScriptingModule. The function inserts the
> diretory into sys.path and then issues a vanilla Python import statement.
>
> I spoke with one of our local Python experts who said that this
> technique to specify the directory is probably unreliable, as the rules
> for
> where Python looks for modules has evolved. The rules for both relative
> and
> absolute module paths changed from Python 2 to 3.
>
> I'll revert the xfail if you want. But this has been broken for quite
> a while (as has another test, which I'm looking into now).
>
> On Tue, Apr 5, 2016 at 2:29 PM, Zachary Turner
> wrote:
> I think we need some more information before we xfail this. It would
> help to drill down to either the python import statement or the
> PyImport_ImportModule C api call that actually does the import.
>
> If you can get that, i can help come up with a fix. Just need to step
> through the execution of the command until you get to the python or c
> code
> that tries to do the import
>
> On Tue, Apr 5, 2016 at 1:54 PM Adrian McCarthy via lldb-commits
> wrote:
> Author: amccart
[Lldb-commits] [lldb] r265560 - Reduce code duplication in ProcessGDBRemote
Author: labath
Date: Wed Apr 6 11:49:13 2016
New Revision: 265560
URL: http://llvm.org/viewvc/llvm-project?rev=265560&view=rev
Log:
Reduce code duplication in ProcessGDBRemote
Summary:
SetThreadStopInfo was checking for a breakpoint at the current PC several
times. This merges the
identical code into a separate function. I've left one breakpoint check alone,
as it was doing
more complicated stuff, and it did not see a way to merge that without making
the interface
complicated. NFC.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D18819
Modified:
lldb/trunk/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
lldb/trunk/source/Plugins/Process/gdb-remote/ProcessGDBRemote.h
Modified: lldb/trunk/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp?rev=265560&r1=265559&r2=265560&view=diff
==
--- lldb/trunk/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp (original)
+++ lldb/trunk/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp Wed Apr
6 11:49:13 2016
@@ -2009,40 +2009,15 @@ ProcessGDBRemote::SetThreadStopInfo (lld
{
if (reason.compare("trace") == 0)
{
-addr_t pc =
thread_sp->GetRegisterContext()->GetPC();
-lldb::BreakpointSiteSP bp_site_sp =
thread_sp->GetProcess()->GetBreakpointSiteList().FindByAddress(pc);
-
-// If the current pc is a breakpoint site then the
StopInfo should be set to Breakpoint
-// Otherwise, it will be set to Trace.
-if (bp_site_sp &&
bp_site_sp->ValidForThisThread(thread_sp.get()))
-{
-thread_sp->SetStopInfo(
-
StopInfo::CreateStopReasonWithBreakpointSiteID(*thread_sp,
bp_site_sp->GetID()));
-}
-else
- thread_sp->SetStopInfo
(StopInfo::CreateStopReasonToTrace (*thread_sp));
+if (!SetThreadStopReasonIfAtBreakpoint(*thread_sp))
+
thread_sp->SetStopInfo(StopInfo::CreateStopReasonToTrace(*thread_sp));
handled = true;
}
else if (reason.compare("breakpoint") == 0)
{
-addr_t pc =
thread_sp->GetRegisterContext()->GetPC();
-lldb::BreakpointSiteSP bp_site_sp =
thread_sp->GetProcess()->GetBreakpointSiteList().FindByAddress(pc);
-if (bp_site_sp)
-{
-// If the breakpoint is for this thread, then
we'll report the hit, but if it is for another thread,
-// we can just report no reason. We don't
need to worry about stepping over the breakpoint here, that
-// will be taken care of when the thread
resumes and notices that there's a breakpoint under the pc.
-handled = true;
-if (bp_site_sp->ValidForThisThread
(thread_sp.get()))
-{
-thread_sp->SetStopInfo
(StopInfo::CreateStopReasonWithBreakpointSiteID (*thread_sp,
bp_site_sp->GetID()));
-}
-else
-{
-StopInfoSP invalid_stop_info_sp;
-thread_sp->SetStopInfo
(invalid_stop_info_sp);
-}
-}
+if (!SetThreadStopReasonIfAtBreakpoint(*thread_sp))
+thread_sp->SetStopInfo(StopInfoSP());
+handled = true;
}
else if (reason.compare("trap") == 0)
{
@@ -2091,20 +2066,12 @@ ProcessGDBRemote::SetThreadStopInfo (lld
}
else if (!signo)
{
-addr_t pc = thread_sp->GetRegisterContext()->GetPC();
-lldb::BreakpointSiteSP bp_site_sp =
-
thread_sp->GetProcess()->GetBreakpointSiteList().FindByAddress(pc);
-
// If the current pc is a breakpoint site then the
StopInfo should be set to Breakpoint
// even though the remote stub did not set it as such.
This can happen when
// the thread is involuntarily interrupted (e.g. due
to stops on othe
Re: [Lldb-commits] [PATCH] D18819: Reduce code duplication in ProcessGDBRemote
This revision was automatically updated to reflect the committed changes.
Closed by commit rL265560: Reduce code duplication in ProcessGDBRemote
(authored by labath).
Changed prior to commit:
http://reviews.llvm.org/D18819?vs=52773&id=52817#toc
Repository:
rL LLVM
http://reviews.llvm.org/D18819
Files:
lldb/trunk/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
lldb/trunk/source/Plugins/Process/gdb-remote/ProcessGDBRemote.h
Index: lldb/trunk/source/Plugins/Process/gdb-remote/ProcessGDBRemote.h
===
--- lldb/trunk/source/Plugins/Process/gdb-remote/ProcessGDBRemote.h
+++ lldb/trunk/source/Plugins/Process/gdb-remote/ProcessGDBRemote.h
@@ -481,6 +481,9 @@
lldb::user_id_t break_id,
lldb::user_id_t break_loc_id);
+bool
+SetThreadStopReasonIfAtBreakpoint(Thread &thread);
+
DISALLOW_COPY_AND_ASSIGN (ProcessGDBRemote);
};
Index: lldb/trunk/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
===
--- lldb/trunk/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
+++ lldb/trunk/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
@@ -2009,40 +2009,15 @@
{
if (reason.compare("trace") == 0)
{
-addr_t pc = thread_sp->GetRegisterContext()->GetPC();
-lldb::BreakpointSiteSP bp_site_sp = thread_sp->GetProcess()->GetBreakpointSiteList().FindByAddress(pc);
-
-// If the current pc is a breakpoint site then the StopInfo should be set to Breakpoint
-// Otherwise, it will be set to Trace.
-if (bp_site_sp && bp_site_sp->ValidForThisThread(thread_sp.get()))
-{
-thread_sp->SetStopInfo(
-StopInfo::CreateStopReasonWithBreakpointSiteID(*thread_sp, bp_site_sp->GetID()));
-}
-else
- thread_sp->SetStopInfo (StopInfo::CreateStopReasonToTrace (*thread_sp));
+if (!SetThreadStopReasonIfAtBreakpoint(*thread_sp))
+thread_sp->SetStopInfo(StopInfo::CreateStopReasonToTrace(*thread_sp));
handled = true;
}
else if (reason.compare("breakpoint") == 0)
{
-addr_t pc = thread_sp->GetRegisterContext()->GetPC();
-lldb::BreakpointSiteSP bp_site_sp = thread_sp->GetProcess()->GetBreakpointSiteList().FindByAddress(pc);
-if (bp_site_sp)
-{
-// If the breakpoint is for this thread, then we'll report the hit, but if it is for another thread,
-// we can just report no reason. We don't need to worry about stepping over the breakpoint here, that
-// will be taken care of when the thread resumes and notices that there's a breakpoint under the pc.
-handled = true;
-if (bp_site_sp->ValidForThisThread (thread_sp.get()))
-{
-thread_sp->SetStopInfo (StopInfo::CreateStopReasonWithBreakpointSiteID (*thread_sp, bp_site_sp->GetID()));
-}
-else
-{
-StopInfoSP invalid_stop_info_sp;
-thread_sp->SetStopInfo (invalid_stop_info_sp);
-}
-}
+if (!SetThreadStopReasonIfAtBreakpoint(*thread_sp))
+thread_sp->SetStopInfo(StopInfoSP());
+handled = true;
}
else if (reason.compare("trap") == 0)
{
@@ -2091,20 +2066,12 @@
}
else if (!signo)
{
-addr_t pc = thread_sp->GetRegisterContext()->GetPC();
-lldb::BreakpointSiteSP bp_site_sp =
-thread_sp->GetProcess()->GetBreakpointSiteList().FindByAddress(pc);
-
// If the current pc is a breakpoint site then the StopInfo should be set to Breakpoint
// even though the remote stub did not set it as such. This can happen when
// the thread is involuntarily interrupted (e.g. due to stops on other
// threads) just as it is about to execute th
Re: [Lldb-commits] [lldb] r265461 - XFail TestImport.py on Windows because Python 3 import rules don't work that way.
I think we actually came up with a better idea. the command script import
code is generating a temporary python file which actually does the import,
so we can generate the code so that it uses the imp module to do an import
by full pathname. An example of code that already does this is in
lldb/test/use_lldb_suite.py
On Wed, Apr 6, 2016 at 8:19 AM Zachary Turner wrote:
> Well, it would belong anywhere that does an import, so in theory it
> belongs in every script. In the general case, for example if you are like
> this:
>
> foo
> |-- bar
> | baz
> |-- biz.py
>
> And you are in foo and you want to import biz.py, you could do "from
> bar.baz import biz". So you just get the relative path (bar/baz/biz.py),
> split the filename / path and remove the extension {bar/baz, biz}, replace
> / with . and construct your import statement that way. That's if you're
> generating a script to run. Which I still think is an odd thing to do,
> since we could just run Python C API calls directly which do the right
> things.
>
> On Wed, Apr 6, 2016 at 7:53 AM Adrian McCarthy
> wrote:
>
>> It will still be a bit of a trick to change the `command script import`
>> handling to do `from foo import blah` in the general case, since foo can't
>> really be an absolute file path.
>>
>> And does the `from __future__ import absolute_import` really belong in
>> the script your importing? Or does it belong in the temp script that's
>> written to do the import? I would have thought the latter from everything
>> I read yesterday.
>>
>> On Tue, Apr 5, 2016 at 6:29 PM, Zachary Turner
>> wrote:
>>
>>> Afaik there's no way to do from future imports with the c api, and
>>> executing the statement with RunOneLine doesn't do it either, it has to be
>>> in the script because it's treated specially by the interpreter.
>>>
>>> There might be a way to do it with some tricks that I didn't figure out
>>> last time.
>>>
>>> If its any consolation, it would only be needed for shared/builtin
>>> formatters.
>>>
>>> I guess it would help to get a better understanding of what the problem
>>> is, if someone files a bug against me (or i can file it myself tomorrow) i
>>> can investigate after I finish PDB stuff.
>>>
>>> In the meantime having it in seems like the best option imo
>>>
>>> On Tue, Apr 5, 2016 at 5:54 PM Jim Ingham wrote:
>>>
Will this be necessary for everybody who uses "command script import"
with Python 3? If so, it would be really nice to do this work in "command
script import" if possible. Otherwise everybody will have to put this goo
at the top of every .py file they write for formatters & breakpoint
commands and the like.
Jim
> On Apr 5, 2016, at 5:30 PM, Zachary Turner via lldb-commits <
lldb-commits@lists.llvm.org> wrote:
>
> Yea I wasn't sure if the . would be necessary or not. If you write
"from __future__ import absolute_import" at the top of each of these python
files (foo.py and foo2.py or whatever they're called) then this should
guarantee that the behavior is the same in both Python 2 and Python 3
>
> On Tue, Apr 5, 2016 at 4:01 PM Adrian McCarthy
wrote:
> "error: module importing failed: Parent module '' not loaded, cannot
perform relative import"
>
> If you omit the dot (i.e., `from foo import foo2`), it appears to
work, but I'm not sure that does the right thing. I'll keep investigating.
>
> On Tue, Apr 5, 2016 at 3:40 PM, Zachary Turner
wrote:
> Without the modification to sys.path
>
> On Tue, Apr 5, 2016 at 3:39 PM Zachary Turner
wrote:
> Can you try to change "import foo2" to "from .foo import foo2"
> On Tue, Apr 5, 2016 at 2:52 PM Adrian McCarthy
wrote:
> I've drilled down into the Python import statement. It's in
ScriptInterpreterPython::LoadScriptingModule. The function inserts the
diretory into sys.path and then issues a vanilla Python import statement.
>
> I spoke with one of our local Python experts who said that this
technique to specify the directory is probably unreliable, as the rules for
where Python looks for modules has evolved. The rules for both relative
and absolute module paths changed from Python 2 to 3.
>
> I'll revert the xfail if you want. But this has been broken for
quite a while (as has another test, which I'm looking into now).
>
> On Tue, Apr 5, 2016 at 2:29 PM, Zachary Turner
wrote:
> I think we need some more information before we xfail this. It would
help to drill down to either the python import statement or the
PyImport_ImportModule C api call that actually does the import.
>
> If you can get that, i can help come up with a fix. Just need to step
through the execution of the command until you get to the python or c code
that tries to do the import
>
> On Tue, Apr 5, 2016 at 1:54 PM A
Re: [Lldb-commits] [PATCH] D18819: Reduce code duplication in ProcessGDBRemote
chying added a subscriber: chying. chying added a comment. TestRegisters.py and TestDebugBreak.py are broken after this change. Could you take a look? http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake/builds/13090 Repository: rL LLVM http://reviews.llvm.org/D18819 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] Buildbot numbers for the week of 3/27/2016 - 4/02/2016
Hello everyone, Below are some buildbot numbers for the last week of 3/27/2016 - 4/02/2016. Thanks Galina "Status change ratio" by active builder (percent of builds that changed the builder status from greed to red or from red to green): buildername| builds | changes | status change ratio ++-+- perf-x86_64-penryn-O3-polly| 52 | 44 |84.6 clang-ppc64le-linux-lnt| 79 | 31 |39.2 lldb-x86_64-darwin-13.4|127 | 44 |34.6 clang-cmake-mipsel | 14 | 4 |28.6 clang-cmake-thumbv7-a15-full-sh| 23 | 6 |26.1 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx14 | 4 | 1 |25.0 clang-x86-win2008-selfhost |127 | 30 |23.6 sanitizer-x86_64-linux | 76 | 16 |21.1 clang-x64-ninja-win7 |200 | 36 |18.0 clang-cmake-aarch64-full | 40 | 6 |15.0 lldb-windows7-android | 90 | 13 |14.4 perf-x86_64-penryn-O3-polly-before-vectorizer-detect-only | 14 | 2 |14.3 perf-x86_64-penryn-O3-polly-before-vectorizer | 16 | 2 |12.5 sanitizer-ppc64le-linux| 40 | 4 |10.0 sanitizer-x86_64-linux-bootstrap | 51 | 5 | 9.8 llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast |425 | 39 | 9.2 clang-atom-d525-fedora-rel | 69 | 6 | 8.7 clang-cmake-thumbv7-a15|161 | 14 | 8.7 clang-cmake-armv7-a15-selfhost-neon| 23 | 2 | 8.7 clang-ppc64be-linux-lnt|236 | 20 | 8.5 clang-cmake-armv7-a15 |154 | 12 | 7.8 clang-cmake-aarch64-42vma |163 | 12 | 7.4 clang-s390x-linux |298 | 22 | 7.4 lldb-x86_64-ubuntu-14.04-android |118 | 8 | 6.8 clang-ppc64be-linux|299 | 20 | 6.7 clang-bpf-build|330 | 22 | 6.7 clang-cmake-armv7-a15-selfhost | 30 | 2 | 6.7 llvm-mips-linux| 61 | 4 | 6.6 clang-cmake-aarch64-quick |162 | 10 | 6.2 clang-ppc64le-linux|193 | 12 | 6.2 clang-ppc64be-linux-multistage |132 | 8 | 6.1 clang-x86_64-debian-fast |140 | 8 | 5.7 llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast |425 | 24 | 5.6 llvm-clang-lld-x86_64-debian-fast |181 | 10 | 5.5 sanitizer-x86_64-linux-fast|183 | 9 | 4.9 clang-cmake-mips | 81 | 4 | 4.9 sanitizer-windows |383 | 18 | 4.7 llvm-hexagon-elf |257 | 12 | 4.7 clang-hexagon-elf |321 | 14 | 4.4 lldb-x86-windows-msvc2015 |182 | 8 | 4.4 lldb-x86_64-ubuntu-14.04-cmake |203 | 9 | 4.4 clang-cmake-armv7-a15-full | 94 | 4 | 4.3 sanitizer-ppc64be-linux| 98 | 4 | 4.1 perf-x86_64-penryn-O3 | 52 | 2 | 3.8 lld-x86_64-win7|330 | 11 | 3.3 perf-x86_64-penryn-O3-polly-unprofitable |212 | 6 | 2.8 lldb-amd64-ninja-net
[Lldb-commits] Buildbot numbers for the week of 3/20/2016 - 3/26/2016
Hello everyone, Below are some buildbot numbers for the week of 3/20/2016 - 3/26/2016. Thanks Galina "Status change ratio" by active builder (percent of builds that changed the builder status from greed to red or from red to green): buildername| builds | changes | status change ratio ++-+- perf-x86_64-penryn-O3-polly| 55 | 30 |54.5 libcxx-libcxxabi-x86_64-linux-debian-noexceptions | 2 | 1 |50.0 libcxx-libcxxabi-x86_64-linux-debian | 2 | 1 |50.0 clang-ppc64le-linux-lnt| 77 | 37 |48.1 perf-x86_64-penryn-O3-polly-parallel-fast |219 | 99 |45.2 lldb-x86_64-darwin-13.4|110 | 46 |41.8 clang-cmake-mipsel | 13 | 4 |30.8 clang-cmake-aarch64-full | 39 | 11 |28.2 clang-x86-win2008-selfhost |107 | 20 |18.7 clang-x64-ninja-win7 |168 | 30 |17.9 sanitizer-ppc64le-linux| 46 | 8 |17.4 llvm-mips-linux| 60 | 10 |16.7 clang-ppc64be-linux-multistage |120 | 20 |16.7 sanitizer-x86_64-linux-bootstrap | 53 | 8 |15.1 lldb-windows7-android | 88 | 13 |14.8 libomp-clang-x86_64-linux-debian | 7 | 1 |14.3 clang-cmake-mips | 88 | 12 |13.6 clang-cmake-armv7-a15-full | 96 | 13 |13.5 clang-atom-d525-fedora-rel | 85 | 10 |11.8 clang-cmake-thumbv7-a15|159 | 18 |11.3 sanitizer-x86_64-linux | 80 | 9 |11.3 clang-ppc64le-linux|183 | 20 |10.9 clang-cmake-aarch64-quick |133 | 14 |10.5 llvm-clang-lld-x86_64-debian-fast |165 | 17 |10.3 clang-cmake-armv7-a15 |142 | 14 | 9.9 clang-cmake-aarch64-42vma |147 | 14 | 9.5 clang-ppc64be-linux-lnt|217 | 20 | 9.2 llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast |370 | 34 | 9.2 clang-cmake-thumbv7-a15-full-sh| 22 | 2 | 9.1 sanitizer-x86_64-linux-fast|161 | 14 | 8.7 clang-s390x-linux |259 | 22 | 8.5 clang-bpf-build|294 | 24 | 8.2 clang-x86_64-debian-fast |126 | 10 | 7.9 clang-ppc64be-linux|262 | 20 | 7.6 llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast |369 | 28 | 7.6 lldb-x86_64-ubuntu-14.04-android |109 | 8 | 7.3 lldb-x86-windows-msvc2015 |153 | 11 | 7.2 sanitizer-ppc64be-linux| 92 | 6 | 6.5 clang-native-arm-lnt | 97 | 6 | 6.2 lldb-x86_64-ubuntu-14.04-cmake |191 | 11 | 5.8 lldb-amd64-ninja-netbsd7 |140 | 8 | 5.7 lld-x86_64-win7|111 | 6 | 5.4 llvm-hexagon-elf |214 | 10 | 4.7 lldb-x86_64-ubuntu-14.04-buildserver |132 | 6 | 4.5 sanitizer-windows |340 | 15 | 4.4 clang-cmake-armv7-a15-selfhost-neon| 25 | 1 | 4.0 perf-x86_64-penryn-O3 |
[Lldb-commits] Updated documentation for SBAddress
The patch is based off the latest code in the github mirror. It includes some documentation changes for other classes, but the primary change is for SBAddress. I intend to fill out the other classes in separate patches. I do not have committer access. Can somebody please merge this in? Thanks, John Lindal SBAddress-docs.patch Description: Binary data ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D18848: Add PDBASTParser and parse type information from PDB
zturner created this revision.
zturner added a reviewer: clayborg.
zturner added a subscriber: lldb-commits.
This code is still untested aside from that it compiles. I mostly want to put
an early work-in-progress up here to make sure I'm on the right path and am not
doing anything fundamentally wrong. Not all types are supported, and I don't
intend to support all types with this initial commit. Things like const /
volatile are not important for a first pass, and I'm only looking at getting
the most common basic types of types working.
One oddity of PDB is that the debug info does not maintain enough information
to accurately reconstruct the DeclContext hierarchy. If you have this:
```
namespace Foo
{
class Bar
{
class Baz
{
};
};
}
```
then that will appear in the PDB as a type with the name `Foo::Bar::Baz`, and
there's no information about whether `Foo` and `Bar` are namespaces or classes.
It is possible to give a best effort attempt, but it's going to be outside the
scope of this patch. So, for now, I intend to put every single type under the
master translation unit decl with fully scoped names. This isn't perfect, but
we can iterate on it in the future.
Again, this is a work in progress, mostly just want to make sure this looks
like the right approach.
http://reviews.llvm.org/D18848
Files:
include/lldb/Symbol/ClangASTContext.h
source/Plugins/SymbolFile/PDB/CMakeLists.txt
source/Plugins/SymbolFile/PDB/PDBASTParser.cpp
source/Plugins/SymbolFile/PDB/PDBASTParser.h
source/Plugins/SymbolFile/PDB/SymbolFilePDB.cpp
source/Plugins/SymbolFile/PDB/SymbolFilePDB.h
source/Symbol/ClangASTContext.cpp
Index: source/Symbol/ClangASTContext.cpp
===
--- source/Symbol/ClangASTContext.cpp
+++ source/Symbol/ClangASTContext.cpp
@@ -90,6 +90,7 @@
#include "lldb/Target/Target.h"
#include "Plugins/SymbolFile/DWARF/DWARFASTParserClang.h"
+#include "Plugins/SymbolFile/PDB/PDBASTParser.h"
#include
@@ -9435,6 +9436,13 @@
return m_dwarf_ast_parser_ap.get();
}
+PDBASTParser *
+ClangASTContext::GetPDBParser()
+{
+if (!m_pdb_ast_parser_ap)
+m_pdb_ast_parser_ap.reset(new PDBASTParser(*this));
+return m_pdb_ast_parser_ap.get();
+}
bool
ClangASTContext::LayoutRecordType(void *baton,
Index: source/Plugins/SymbolFile/PDB/SymbolFilePDB.h
===
--- source/Plugins/SymbolFile/PDB/SymbolFilePDB.h
+++ source/Plugins/SymbolFile/PDB/SymbolFilePDB.h
@@ -10,11 +10,10 @@
#ifndef lldb_Plugins_SymbolFile_PDB_SymbolFilePDB_h_
#define lldb_Plugins_SymbolFile_PDB_SymbolFilePDB_h_
-#include
-
#include "lldb/Core/UserID.h"
#include "lldb/Symbol/SymbolFile.h"
+#include "llvm/ADT/DenseMap.h"
#include "llvm/DebugInfo/PDB/IPDBSession.h"
#include "llvm/DebugInfo/PDB/PDB.h"
@@ -179,12 +178,14 @@
void
BuildSupportFileIdToSupportFileIndexMap(const llvm::PDBSymbolCompiland &cu,
-std::unordered_map &index_map) const;
+llvm::DenseMap &index_map) const;
-std::unordered_map m_comp_units;
+llvm::DenseMap m_comp_units;
+llvm::DenseMap m_types;
std::unique_ptr m_session_up;
uint32_t m_cached_compile_unit_count;
+std::unique_ptr m_tu_decl_ctx_up;
};
#endif // lldb_Plugins_SymbolFile_PDB_SymbolFilePDB_h_
Index: source/Plugins/SymbolFile/PDB/SymbolFilePDB.cpp
===
--- source/Plugins/SymbolFile/PDB/SymbolFilePDB.cpp
+++ source/Plugins/SymbolFile/PDB/SymbolFilePDB.cpp
@@ -11,10 +11,12 @@
#include "lldb/Core/Module.h"
#include "lldb/Core/PluginManager.h"
+#include "lldb/Symbol/ClangASTContext.h"
#include "lldb/Symbol/CompileUnit.h"
#include "lldb/Symbol/LineTable.h"
#include "lldb/Symbol/ObjectFile.h"
#include "lldb/Symbol/SymbolContext.h"
+#include "lldb/Symbol/TypeMap.h"
#include "llvm/DebugInfo/PDB/IPDBEnumChildren.h"
#include "llvm/DebugInfo/PDB/IPDBLineNumber.h"
@@ -27,6 +29,8 @@
#include "llvm/DebugInfo/PDB/PDBSymbolFuncDebugEnd.h"
#include "llvm/DebugInfo/PDB/PDBSymbolFuncDebugStart.h"
+#include "Plugins/SymbolFile/PDB/PDBASTParser.h"
+
using namespace lldb_private;
namespace
@@ -116,6 +120,10 @@
{
lldb::addr_t obj_load_address = m_obj_file->GetFileOffset();
m_session_up->setLoadAddress(obj_load_address);
+
+TypeSystem *type_system = GetTypeSystemForLanguage(lldb::eLanguageTypeC_plus_plus);
+ClangASTContext *clang_type_system = llvm::dyn_cast_or_null(type_system);
+m_tu_decl_ctx_up = llvm::make_unique(type_system, clang_type_system->GetTranslationUnitDecl());
}
uint32_t
@@ -245,7 +253,25 @@
lldb_private::Type *
SymbolFilePDB::ResolveTypeUID(lldb::user_id_t type_uid)
{
-return nullptr;
+auto find_result = m_types.find(type_uid);
+if (find_result != m_types.end())
+
Re: [Lldb-commits] [PATCH] D18638: [LLDB][MIPS] Provide ABI string to compiler for appropriate code generation for MIPS
nitesh.jain updated this revision to Diff 52886.
nitesh.jain added a comment.
The diff is updated as per suggestion
Repository:
rL LLVM
http://reviews.llvm.org/D18638
Files:
source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
source/Plugins/ExpressionParser/Clang/ClangExpressionParser.h
Index: source/Plugins/ExpressionParser/Clang/ClangExpressionParser.h
===
--- source/Plugins/ExpressionParser/Clang/ClangExpressionParser.h
+++ source/Plugins/ExpressionParser/Clang/ClangExpressionParser.h
@@ -137,7 +137,19 @@
Error
RunStaticInitializers (lldb::IRExecutionUnitSP &execution_unit_sp,
ExecutionContext &exe_ctx);
-
+
+//--
+/// Returns a string representing current ABI.
+///
+/// @param[in] target_arch
+/// The target architecture.
+///
+/// @return
+/// A string representing target ABI for the current architecture.
+//---
+std::string
+GetClangTargetABI (const ArchSpec &target_arch);
+
private:
std::unique_ptr m_llvm_context; ///< The
LLVM context to generate IR into
std::unique_ptr m_file_manager; ///< The
Clang file manager object used by the compiler
Index: source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
===
--- source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
+++ source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
@@ -268,6 +268,7 @@
bool overridden_target_opts = false;
lldb_private::LanguageRuntime *lang_rt = nullptr;
lldb::TargetSP target_sp;
+std::string abi;
if (exe_scope)
target_sp = exe_scope->CalculateTarget();
@@ -333,6 +334,11 @@
// This will be empty for any CPU that doesn't really need to make a
special CPU string.
m_compiler->getTargetOpts().CPU = target_arch.GetClangTargetCPU();
+// Set the target ABI
+abi = GetClangTargetABI(target_arch);
+if (!abi.empty())
+m_compiler->getTargetOpts().ABI = abi;
+
// 3. Now allow the runtime to provide custom configuration options for
the target.
// In this case, a specialized language runtime is available and we can
query it for extra options.
// For 99% of use cases, this will not be needed and should be provided
when basic platform detection is not enough.
@@ -645,6 +651,32 @@
return num_errors;
}
+std::string
+ClangExpressionParser::GetClangTargetABI (const ArchSpec &target_arch)
+{
+std::string abi;
+const llvm::Triple::ArchType machine = target_arch.GetMachine();
+
+if(machine == llvm::Triple::mips ||
+ machine == llvm::Triple::mipsel ||
+ machine == llvm::Triple::mips64 ||
+ machine == llvm::Triple::mips64el)
+{
+ switch (target_arch.GetFlags () & ArchSpec::eMIPSABI_mask)
+ {
+ case ArchSpec::eMIPSABI_N64:
+abi = "n64"; break;
+ case ArchSpec::eMIPSABI_N32:
+abi = "n32"; break;
+ case ArchSpec::eMIPSABI_O32:
+abi = "o32"; break;
+ default:
+ break;
+ }
+}
+return abi;
+}
+
bool
ClangExpressionParser::RewriteExpression(DiagnosticManager &diagnostic_manager)
{
Index: source/Plugins/ExpressionParser/Clang/ClangExpressionParser.h
===
--- source/Plugins/ExpressionParser/Clang/ClangExpressionParser.h
+++ source/Plugins/ExpressionParser/Clang/ClangExpressionParser.h
@@ -137,7 +137,19 @@
Error
RunStaticInitializers (lldb::IRExecutionUnitSP &execution_unit_sp,
ExecutionContext &exe_ctx);
-
+
+//--
+/// Returns a string representing current ABI.
+///
+/// @param[in] target_arch
+/// The target architecture.
+///
+/// @return
+/// A string representing target ABI for the current architecture.
+//---
+std::string
+GetClangTargetABI (const ArchSpec &target_arch);
+
private:
std::unique_ptr m_llvm_context; ///< The LLVM context to generate IR into
std::unique_ptr m_file_manager; ///< The Clang file manager object used by the compiler
Index: source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
===
--- source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
+++ source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
@@ -268,6 +268,7 @@
bool overridden_target_opts = false;
lldb_private::LanguageRuntime *lang_rt = nullptr;
lldb::TargetSP target_sp;
+std::
[Lldb-commits] [lldb] r265644 - Symbol: fix build
Author: compnerd
Date: Thu Apr 7 01:51:10 2016
New Revision: 265644
URL: http://llvm.org/viewvc/llvm-project?rev=265644&view=rev
Log:
Symbol: fix build
TargetOptions is ambiguous due to a definition in LLVM and in clang. This was
exposed by SVN r265640. Update to fix the build against the newer revision.
Modified:
lldb/trunk/source/Symbol/ClangASTContext.cpp
Modified: lldb/trunk/source/Symbol/ClangASTContext.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Symbol/ClangASTContext.cpp?rev=265644&r1=265643&r2=265644&view=diff
==
--- lldb/trunk/source/Symbol/ClangASTContext.cpp (original)
+++ lldb/trunk/source/Symbol/ClangASTContext.cpp Thu Apr 7 01:51:10 2016
@@ -717,11 +717,11 @@ ClangASTContext::getDiagnosticConsumer()
return m_diagnostic_consumer_ap.get();
}
-std::shared_ptr &
+std::shared_ptr &
ClangASTContext::getTargetOptions() {
if (m_target_options_rp.get() == nullptr && !m_target_triple.empty())
{
-m_target_options_rp = std::make_shared();
+m_target_options_rp = std::make_shared();
if (m_target_options_rp.get() != nullptr)
m_target_options_rp->Triple = m_target_triple;
}
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
