The Native PDB symbol file plugin I think is mostly complete. It's at
least almost as good as the old Windows-only PDB plugin in 90% of ways,
while actually being significantly better in other ways (for example, there
was a test that took over 2 minutes to run with the Windows-only PDB
plugin, whi
I own this one: lldb-x86-windows-msvc2015
It can be removed, especially now that Stella's is strictly better than
mine was even when it was working.
There will probably be an effort on our side to get the Linux bots up and
running again "soon", but I don't have an exact timeline right now.
On Fr
Can you try clang-cl.exe /Z7 main.cpp instead of a clang.exe command line?
On Wed, Jan 16, 2019 at 10:56 PM Christoph Baumann via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
> Hey,
>
> I wrote a simple hello-world program to test lldb on windows:
>
>
>
> #include
>
> in
This would be great. All of these tests have always been disabled on
Windows so converting them to lit tests would increase test coverage there
as well
On Wed, Jan 30, 2019 at 6:00 PM Alex Langford via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
> +1
>
> Thanks for bringing this up. I'd like to see
Was the test failing specifically in the keyboard handler for up arrow, or
was it failing in the command history searching code? Because if it's the
latter, then we could have a command which searches the command history.
On Thu, Jan 31, 2019 at 10:23 AM Davide Italiano via lldb-dev <
lldb-dev@li
FileCheck the ansi escape codes seems like one possibility.
In general I think you don't actually need to test true interactivity,
because the odds of there being a problem in the 2-3 lines of code that
convert the keyboard press to something else in LLDB are very unlikely to
be problematic, and t
It's worth mentioning that pexpect is basically unusable on Windows, so
there's still that.
On Thu, Jan 31, 2019 at 11:40 AM Pavel Labath wrote:
> On 31/01/2019 19:51, Zachary Turner wrote:
> > FileCheck the ansi escape codes seems like one possibility.
> >
> > In general I think you don't ac
Hi all,
We've got some internal efforts in progress, and one of those would benefit
from debug info parsing being out of process (independently of whether or
not the rest of LLDB is out of process).
There's a couple of advantages to this, which I'll enumerate here:
- It improves one source of
path and switch
everything to the out of process server, even if that server were running
on the same physical machine as the debugger client (which would be
functionally equivalent to what we have today).
On Tue, Feb 26, 2019 at 3:46 PM Frédéric Riss wrote:
>
> On Feb 25, 2019, at 10:21 AM, Zachar
On Tue, Feb 26, 2019 at 4:49 PM Frédéric Riss wrote:
>
> On Feb 26, 2019, at 4:03 PM, Zachary Turner wrote:
>
> I would probably build the server by using mostly code from LLVM. Since
> it would contain all of the low level debug info parsing libraries, i would
> expect that all knowledge of de
On Tue, Feb 26, 2019 at 5:39 PM Frédéric Riss wrote:
>
> On Feb 26, 2019, at 4:52 PM, Zachary Turner wrote:
>
>
>
> On Tue, Feb 26, 2019 at 4:49 PM Frédéric Riss wrote:
>
>>
>> On Feb 26, 2019, at 4:03 PM, Zachary Turner wrote:
>>
>> I would probably build the server by using mostly code from
GSYM, as I understand it, is basically just an evolution of Breakpad
symbols. It doesn't contain full fidelity debug information (type
information, function parameters, etc).
On Tue, Feb 26, 2019 at 5:56 PM wrote:
> When I see this "parsing DWARF and turning it into something else" it is
> very
On Wed, Feb 27, 2019 at 2:52 PM Frédéric Riss wrote:
> On Feb 27, 2019, at 10:12 AM, Zachary Turner wrote:
>
>
>
> For what it's worth, in an earlier message I mentioned that I would
> probably build the server by using mostly code from LLVM, and making sure
> that it supported the union of thin
On Wed, Feb 27, 2019 at 4:35 PM Frédéric Riss wrote:
>
> On Feb 27, 2019, at 3:14 PM, Zachary Turner wrote:
>
>
>
> On Wed, Feb 27, 2019 at 2:52 PM Frédéric Riss wrote:
>
>> On Feb 27, 2019, at 10:12 AM, Zachary Turner wrote:
>>
>>
>>
>> For what it's worth, in an earlier message I mentioned t
On Sat, Mar 2, 2019 at 2:56 PM Adrian Prantl wrote:
>
> On Feb 25, 2019, at 10:21 AM, Zachary Turner via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
> Hi all,
>
> We've got some internal efforts in progress, and one of those would
> benefit from debu
On Tue, Mar 5, 2019 at 1:47 PM Jonas Devlieghere via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
>
> I don't know much about the minidump format or code, but it sounds
> reasonable for me to have support for it in yaml2obj, which would be a
> sufficient motivation to have the code live there. As yo
Well, all of the actual yamlization code in obj2yaml and yaml2obj is
library-ized, so you could always add the real code there, then have
core2yaml just link against it
On Wed, Mar 6, 2019 at 5:11 AM Pavel Labath wrote:
> On 05/03/2019 22:52, Zachary Turner wrote:
> >
> >
> > On Tue, Mar 5, 2019
On Mon, Mar 4, 2019 at 10:32 AM Zachary Turner wrote:
> On Sat, Mar 2, 2019 at 2:56 PM Adrian Prantl wrote:
>
>>
>>- It becomes testable as an independent component, because you can
>>just send requests to it and dump the results and see if they make sense.
>>Currently there is almos
On Thu, Mar 7, 2019 at 11:03 AM Jim Ingham via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
> Even though you can just use debugserver/lldb-server and debug remotely,
> many people find it handy to be able to run a debugger directly on the
> device they are using. But requiring that you port Python
Does lldb-server for Android currently use this flag? I was under the
impression it just linked against Python anyway.
On Thu, Mar 7, 2019 at 11:50 AM Pavel Labath via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
> On 07/03/2019 20:29, Davide Italiano via lldb-dev wrote:
> > I'm in favor of this.
Yes, Pavel pointed out one specific case where it is used, and that case
definitely needs to be supported.
We've talked in the past about fixing the layering in such a way that all
Python related code is in ScriptInterpreterPython, but there's definitely a
non-trivial amount of work needed to make
It's been a long time coming and a lot of work to get here, but Host is now
dependency free. While this may not be enforced in the Xcode project
(unless someone changes it to not link against any other libraries /
targets), as of r355730 this is enforced in the CMake build, so if new
dependencies
I want to ask what the status of DWARF64 in LLDB is. I can tell there's
some support for it by reading the code, but it seems to have zero test
coverage so it's not clear to me that anyone depends on it. For example, I
know that clang and LLVM will not even generate DWARF64, so if anyone is
depen
in a local branch while waiting to see if
anyone else has any input.
On Mon, Mar 11, 2019 at 1:25 PM Jan Kratochvil
wrote:
> On Mon, 11 Mar 2019 20:45:48 +0100, Zachary Turner via lldb-dev wrote:
> > I want to ask what the status of DWARF64 in LLDB is.
>
> IMO there isn't as for
ay (which again, appears to not fully work).
If we can go this route, it makes merging the two DWARF parsing
implementations quite a bit simpler
On Mon, Mar 11, 2019 at 3:33 PM Adrian Prantl wrote:
>
>
> > On Mar 11, 2019, at 12:45 PM, Zachary Turner via lldb-dev <
> lldb-dev@list
This seems reasonable to me. It's worth pointing out though that in
regards to the last comment "IMO it's good to make this lldb-vscode more
general so that it can be used by other debugger frontends besides vscode",
despite the name lldb-vscode, there is actually nothing here that is
specific to
Apparently we have a macro called DEBUG_PRINTF() which, if you compile LLDB
with a special pre-processor setting enabled, will cause certain messages
to be printed to stdout while running LLDB.
Does anyone use this? This seems like a kind of hacky alternative to
tracepoints and/or pretty printers
Two things stand out to me as odd here.
1) -glldb. -g is supposed to specify the debug information format, either
dwarf, codeview, or whichever is the default. I've never heard of anyone
using -glldb (or for that matter -ggdb). Just -g, -gcodeview, or -gdwarf.
2) You're using clang instead of
te DWARF, "tuned" for LLDB. Clang
> understands three "debugger tunings" which are gdb, lldb, and sce. The
> distinctions are minor and not relevant here.
>
> --paulr
>
>
>
>
>
> *From:* lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] *On Behalf Of
On Tue, Mar 19, 2019 at 12:00 PM Tom Stellard via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
> Hi,
>
> I would like to follow up on the previous thread[1], where there was a
> consensus
> to disallow merge commits in the llvm github repository, and start a
> discussion
> about how we should enforc
It sounds like we need to get someone from the Foundation (chandlerc@,
lattner@, tanya@, someone else?) to reach out to them offline about this.
On Wed, Mar 20, 2019 at 11:23 AM Arthur O'Dwyer
wrote:
> On Wed, Mar 20, 2019 at 2:19 PM Tom Stellard via cfe-dev <
> cfe-...@lists.llvm.org> wrote:
>
Whew, I had checked in something yesterday that I was worried might have
broken something, so I was frantically doing a rebuild to see if it was me.
Side question: This isn't the first time I've seen you call it "detest".
Do you really hate it that much, or is it just a common typo? :)
On Tue, A
After the previous discussion I agree that evaluating the arguments is
unacceptable. But you are correct here that a macro would solve this. In
fact, most C++ log libraries use macros I guess for this very reason.
I decided to make some macros for the windows plugin which you can look at
it in P
There are a bunch of tests in the tree that are named after Rdars. As a
result, it's not clear to anyone outside of Apple what these are supposed
to be testing so it diminishes their usefulness and increases our
maintenance burden since it's impossible to know if it is an issue that we
should fix,
Can't comment on the failures for Linux, but I don't think we have a good
handle on the unexpected successes. I only added that information to the
output about a week ago, before that unexpected successes were actually
going unnoticed.
It's likely that someone could just go in there and remove th
It would be great (and not too difficult) to add skip counts to dosep. I
modified dotest so it formats the result summary in a nice single string
that you can regex match to get counts. It's already matched in dosep, but
we just aren't pulling out the skip counts. So it would be very easy to
add
While looking into a Windows-specific issue involving TestTargetAPI.py, I
noticed that we are building the exact same executable many times. Every
single test has a line such as self.buildDwarf() or self.buildDsym().
Those functions will first run make clean and then run make, essentially
rebuildi
On Tue, Aug 25, 2015 at 4:39 PM Todd Fiala wrote:
>
> Great, thanks Dawn!
>
> I'd like to get all the counts into dosep.py at least as an option, but
> having something to cross check it with is good (and getting a quick answer
> is nice as well, thanks.)
>
Personally I'd love to see LESS option
Another possibility is changing the arguments to buildDwarf and buildDsym.
Currently they take a clean argument with a default value of True. Does
this really need to be True? If this were False by default it could
drastically speed up the test suite. And I can't think of a reason why
make clean
on purpose - sadly
> I don't remember which ones. If we're lucky they would fail if you
> switched the default and you could go fix them, but if you are unlucky they
> would succeed without actually testing what they were supposed to test. So
> a little care would be needed to
Labath wrote:
> On 26 August 2015 at 06:14, Zachary Turner via lldb-dev
> wrote:
> >
> > I'll wait and see if anyone can remember which tests rebuild binaries on
> > purpose. Otherwise I will try to look through them and see if I can
> figure
> > it out.
&
e level) into a new directory. I don't think that would be inherently
> broken by a no-clean scenario but we'd want to make sure it doesn't break.
>
> -Todd
>
> On Wed, Aug 26, 2015 at 7:52 AM, Zachary Turner via lldb-dev <
> lldb-dev@lists.llvm.org> wrot
On Windows, when we attach to process, we basically invoke a system call
which tells the kernel to kick off the process necessary for a debugger to
be able to communicate with the process.
The end result of all this is that eventually the OS itself will generate a
breakpoint in the inferior by inj
Slightly related, but do other platforms have a way to check from an
inferior if a debugger is present?
We need to do this frequently from the test inferiors, and I see lots of
different approaches used in the test programs, none of which work
correctly on Windows.
On Wed, Aug 26, 2015 at 2:09 PM
et back says whether
> the process is being traced. sysctl's are a generic UNIX thing, but I
> don't know if the bit OS X uses is shared with other Unix's.
>
> Jim
>
> > On Aug 26, 2015, at 2:20 PM, Zachary Turner via lldb-dev <
> lldb-dev@lists.llvm.org>
It's not that it relies on a specific thread being selected, because as you
can see there are 2 threads in that trace. The problem is that the second
frame is not even yet in the main function, it's in the startup code
because of how early the attach process happens (which itsels is probably
actua
Well I'm xfailing it for now, but this other method seems kind of hackish
to me because it means the inferior and the debugger have to coordinate
with each other, which means the test has to know about the executable and
the executable has to know about the test. I'd rather remove one direction
of
to prever debug via launch instead of attach wouldn't
necessarily fix the problem, because you still need to write tests that
test attach sometimes.
On Thu, Aug 27, 2015 at 3:01 PM wrote:
> On Thu, Aug 27, 2015 at 05:05:23PM +0000, Zachary Turner via lldb-dev
> wrote:
> > Well I
We've been seeing races during shutdown of inferiors for months, and I
finally tracked it down to the fact that Process holds a Target&. When an
inferior is exiting on Windows, we will get a notification of this and we
try to do various cleanup related with the target. But there are times
where t
re is currently an
> invariant that Process should never outlive its Target (which would
> seem to be implied by the fact it holds a Target&), I would prefer if
> it can be preserved.
>
> pl
>
> On 28 August 2015 at 19:34, Zachary Turner via lldb-dev
> wrote:
> > We&#x
process via
> lldb::SBProcess have a weak pointer already, or SBThread or SBFrame both
> have a "lldb::ExecutionContextRefSP m_opaque_sp;" which points to a class
> that contains weak pointer to the process.
>
> > On Aug 28, 2015, at 2:18 PM, Zachary Turner via lldb-dev &
I think it's mostly a problem of tests. Basically we have tests which are
written in such a way that the inferior and the debugger need to reach a
synchronization point before the test can proceed to test what it wants to
test.
On Mon, Aug 31, 2015 at 4:08 PM Greg Clayton wrote:
> Or is this ju
Sounds good. I already have that working in a local patch, but I will wait
for the fix you described earlier to go in first, and handle the merge and
check in the weak_ptr change.
On Mon, Aug 31, 2015 at 2:53 PM Greg Clayton wrote:
>
> > On Aug 31, 2015, at 1:34 PM, Zachary Turner wrote:
> >
>
Historically the pattern for tests that need to test situations involving
threads has been to write the tests using pthreads, and then a common
pattern on the python side of the test is to assert that the actual number
of threads equals the expected number of threads.
To deal with the pthread port
t; 13
>
> or:
>
> ...
> frame #2: 0x7fff9c298a6a libdispatch.dylib _dispatch_mgr_thread +
> 52
>
>
> So it might be easy to add API to SBThread like:
>
> bool
> SBThread::IsUserCreated();
>
> Then we could teach the tests to filter out any thr
Can you change it to CMake instead of configure? I know that's not what
you want to hear, but the configure build is on its way out, so you're
going to have to do this at some point anyway.
On Thu, Sep 3, 2015 at 10:25 AM Todd Fiala via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
> I haven't seen
+Stephane because he just went through the pain of getting a working build
on Windows, so he might be able to point out some gotchas.
*About VS 2015*
VS 2015 does not work because of Python. Technically, it could
theoretically work but you won't be able to run the test suite at all. I
don't plan
There's actually not one yet. The past few weeks you might have seen me
checking in a ton of changes related to XFAILing a bunch of tests on
Windows and filing corresponding bugs. We are trying to get down to a
baseline of 0 failing tests exactly for this reason, so that we can enable
tests to ru
or 2 years now.
>
>
>
> --
>
> 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
The community's current plan of record is still to kill the autoconf build
but there is no definitive timeline on when it will be complete. But to
answer your question, yes it is across all projects.
>From the LLDB side, I don't know if anyone depends on having a working
autoconf build for produc
The past few weeks I've spent a lot of time xfailing the rest of the
failing tests on windows so we can enable tests to run on the bots.
One thing I ran into more frequently than I would have liked is that the
tests were failing not because the functionality is broken, but because the
substrings b
shouldn't write any new tests
> that way.
>
> Jim
>
>
> > On Sep 11, 2015, at 11:33 AM, Zachary Turner via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >
> > The past few weeks I've spent a lot of time xfailing the rest of the
> failing te
dy agreed
> with me at first, so we ended up with a bunch of tests that do complex
> things using HandleCommand where they really ought not to. I'm not sure it
> is worth the time to go rewrite all those tests, but we shouldn't write any
> new tests that way.
> >
> >
I agree that we should test the command interface, but
a) they should be explicitly marked as interface tests.
b) There should be MUCH fewer.
c) It should only verify that typing a particular command maps to the right
core sequence of public / private API calls. Not that the debugger
functionalit
On Thu, Sep 17, 2015 at 10:08 AM wrote:
> On Tue, Sep 15, 2015 at 11:36:00PM +, Zachary Turner wrote:
> > a) they should be explicitly marked as interface tests.
>
> What's the decorator for this?
>
There's not one currently.
>
> > d) Results of these interface tests should also not be *ver
On Thu, Sep 17, 2015 at 10:31 AM wrote:
> On Tue, Sep 15, 2015 at 04:46:41PM -0700, Jim Ingham wrote:
> > > In any case, there's a lot I never could figure out how to do in the SB
> > > API that I could only do via commands. For example, how do you test
> > > that a trailing space at the end of
On Thu, Sep 17, 2015 at 10:39 AM wrote:
> On Thu, Sep 17, 2015 at 05:20:14PM +, Zachary Turner wrote:
> > > > a) they should be explicitly marked as interface tests.
> > > What's the decorator for this?
> >
> > There's not one currently.
>
> Will there be?
>
Whenever someone adds one :) If y
After our last discussion, I thought about it some more and there are at
least some problems with this. The biggest problem is that with only a
single process, you are doing all tests from effectively a single instance
of LLDB. There's a TestMultipleDebuggers.py for example, and whether or
not th
t; > wrote:
>>
>>> One more point to Zachary's comment is that currently if LLDB crashes
>>> for a test we report the test failure somewhat correctly (not perfectly).
>>> With a multi threaded approach I would expect an LLDB crash to take down
>>> the
Resending since I sent to wrong list again.
On Tue, Sep 22, 2015 at 10:12 AM Zachary Turner wrote:
> In regards to this CL:
> http://llvm.org/viewvc/llvm-project?rev=247953&view=rev
>
> It has broken TestCppValueCast on Windows and fixed TestCxxWcharT on
> Windows as well. Although these appear
Thanks for the heads up, I'm familiar with the flag. I'll look into
whether it's appropriate when I get back from CppCon
On Tue, Sep 22, 2015 at 8:44 AM Todd Fiala wrote:
> Hey Zachary,
>
> There is a Windows-specific subprocess.CREATE_NEW_PROCESS_GROUP flag that
> you could potentially add to
Can you offer a hint about how you plan to implement this? When you say it
we should get the same behavior everywhere, I assume this means Windows
too, which currently does not support running with a timeout at all
(because timeout / gtimeout aren't present)
On Wed, Sep 23, 2015 at 2:22 PM Todd F
No obvious reason I see why that wouldn't work. You probably want to wrap
the "thread 1" code in a try: ... except: pass because p.terminate probably
will cause an exception on the other thread.
On Wed, Sep 23, 2015 at 2:40 PM Todd Fiala wrote:
> A nice bit here, also, is for those places where
We definitely want timeouts. I was planning to implement timeout /
gtimeout in C++ and checking it in and building it as part of the build
process. But this would be better for obvious reasons.
On Wed, Sep 23, 2015 at 2:56 PM Todd Fiala wrote:
> Yeah good idea.
>
> Anyways, that's what I'm goi
If I remember correctly the CMake stuff relating to LLDB_vers.c is kind of
confusing. I can have a look when I'm back in the office on Monday if
nobody else beats me.
On Fri, Sep 25, 2015 at 10:29 AM via lldb-dev
wrote:
> Due to recent changes, rebuilding with cmake and ninja in an existing
> b
Resending since the wrong list was CC'ed.
On Tue, Sep 29, 2015 at 3:39 PM Zachary Turner wrote:
> Hi Greg. I'm responding on this thread since you said lldb-dev is a
> better place for questions.
>
> I had a chance to look at this some more. It looks like the way we're
> constructing the clang:
I was able to track this down to a bug in Clang. I have a patch up for
review.
http://reviews.llvm.org/D13276
I'm not sure what part of the TypeSystem refactor caused this to finally be
exposed, but in any case I expect that patch will go through and this bug
will be fixed.
On Tue, Sep 29, 20
Are you using MSBuild or Ninja to build (i.e. are you clicking the Build
Solution button in Visual Studio or running ninja from command line)? I
don't know where it puts this stuff with a VS2013 build, but with a ninja
build, your directory will be organized like this:
build
|___bin
|___lldb
On Fri, Sep 11, 2015 at 11:42 AM Jim Ingham wrote:
> I have held from the beginning that the only tests that should be written
> using HandleCommand are those that explicitly test command behavior, and if
> it is possible to write a test using the SB API you should always do it
> that way for the
ts. (For those of you who are test-centric, this is not a surprising
> outcome, but I'm adding this for those who may be inclined to think of it
> as an afterthought).
>
> -Todd
>
> On Mon, Oct 5, 2015 at 11:24 AM, Zachary Turner via lldb-dev <
> lldb-dev@lists.llv
Are you using -DCMAKE_BUILD_TYPE=Debug when you generate CMake?
On Mon, Oct 5, 2015 at 1:14 PM kwadwo amankwa wrote:
> Thanks for the response , sorry for the delay. As a matter of fact I
> actually got rid of the system python and installed my custom version. I
> do suspect it is a linking pr
Can you try to regenerate CMake with that command line and see if that
helps?
On Mon, Oct 5, 2015 at 1:17 PM kwadwo amankwa wrote:
>
> No
>
> On 05/10/15 21:15, Zachary Turner wrote:
>
> Are you using -DCMAKE_BUILD_TYPE=Debug when you generate CMake?
>
> On Mon, Oct 5, 2015 at 1:14 PM kwadwo ama
Well my point is just that clang already has hundreds of tests for this
type of thing, but they don't test what happens in the presence of an
external record layout, which is what LLDB uses. And it tests far more
scenarios than we could ever think of. So I don't think we need to write
many tests
We should explicitly disallow it. You should be able to tell by looking at
a test's filename what it does. If two files have the same name, then you
wonder why they aren't the same test, and it leaves you with more questions
than answers. If two tests have the same name and they actually *should
est-centric, this is not a surprising
> outcome, but I'm adding this for those who may be inclined to think of it
> as an afterthought).
>
> -Todd
>
> On Mon, Oct 5, 2015 at 11:24 AM, Zachary Turner via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
>> On Fri, Sep
On Wed, Oct 7, 2015 at 10:17 AM Greg Clayton wrote:
>
>
> > On Oct 7, 2015, at 10:05 AM, Zachary Turner via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >
> > Jim, Greg,
> >
> > Can I get some feedback on this? I would like to start enforcing this
On Wed, Oct 7, 2015 at 10:37 AM Zachary Turner wrote:
> One more question: I mentioned earlier that we should enforce the
> distinction between HandleCommand tests and python api tests at an
> organizational level. In other words, all HandleCommand tests go in
> lldb/test/command-api, and all ne
On Wed, Oct 7, 2015 at 11:26 AM Jim Ingham wrote:
>
> > On Oct 7, 2015, at 11:16 AM, Jim Ingham wrote:
> >
> >>
> >> On Oct 7, 2015, at 10:37 AM, Zachary Turner via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >>
> >>
>
5, at 11:40 AM, Zachary Turner wrote:
> >
> >
> >
> > On Wed, Oct 7, 2015 at 11:26 AM Jim Ingham wrote:
> >
> > > On Oct 7, 2015, at 11:16 AM, Jim Ingham wrote:
> > >
> > >>
> > >> On Oct 7, 2015, at 10:37 AM, Zachary Turner via
When you built LLDB, did you specify a -DPYTHON_HOME= on your CMake
command line, and also run the install_custom_python.py script? There's a
lot of steps, so it seems like almost everybody misses at least one step
when doing this.
I'm actively working (as in, literally right now) on getting LLDB
I'm about 90% of the way there on the native code side. The last part is
tricky, but still mechanical. After I finish that the trick is going to be
getting the test suite running. I suspect that will be nasty, just because
there's a few thousand lines of code and it's going to be a pain to find
Moving this to the public list because it seems useful to see what other
members of the community have to say as well.
On Mon, Oct 12, 2015 at 4:22 PM Zachary Turner wrote:
> It's worth also pointing out that if we go the route of supporting both
> then everyone running the test suite will need
On Mon, Oct 12, 2015 at 7:31 PM Zachary Turner wrote:
> Moving this to the public list because it seems useful to see what other
> members of the community have to say as well.
>
BTW , I realized I didn't give any context here and it's hard to follow a
long quote thread. Mostly this is just to
On Tue, Oct 13, 2015 at 9:08 PM Todd Fiala wrote:
> On Tue, Oct 13, 2015 at 9:45 AM, Zachary Turner
> wrote:
>
>> On Mon, Oct 12, 2015 at 7:31 PM Zachary Turner
>> wrote:
>>
>>> Moving this to the public list because it seems useful to see what other
>>> members of the community have to say as
That wouldn't work in this case because it causes a failure from one test
to the next. So a single test suite has 5 tests, and the second one fails
because the first one didn't clean up correctly. You couldn't call
ScriptInterpreterpython::Clear here, because then you'd have to initialize
it agai
We actually do already to the self.dbg.DeleteTarget(target), and that's the
line that's failing. The reason it's failing is because the 'sc' reference
is still alive, which is holding an mmap, which causes a mandatory file
lock on Windows.
The diagnostics went pretty deep into python internals, b
To add more evidence for this, here's a small repro:
import sys
print "sys.exc_info() = ", "Empty" if sys.exc_info() == (None, None, None)
else "Valid"
try:
raise Exception
except Exception, e:
print "sys.exc_info() = ", "Empty" if sys.exc_info() == (None, None,
None) else "Valid"
pas
exception *currently being processed*, still
returns something after it is finished being processed.
On Thu, Oct 15, 2015 at 11:36 AM Ryan Brown wrote:
> Couldn't we just change DeleteTarget to make sure everything is unmapped?
>
> On Thu, Oct 15, 2015 at 11:34 AM Zachary Turner v
nge DeleteTarget to make sure everything is unmapped?
>>
>> On Thu, Oct 15, 2015 at 11:34 AM Zachary Turner via lldb-dev <
>> lldb-dev@lists.llvm.org> wrote:
>>
>>> To add more evidence for this, here's a small repro:
>>>
>>> import
AKA: Is Python 2.6 a supported configuration? I found this
`argparse_compat.py` file in tests, and it opens with this:
"""
Compatibility module to use the lldb test-suite with Python 2.6.
Warning: This may be buggy. It has not been extensively tested and should
only
be used when it is impossible
501 - 600 of 635 matches
Mail list logo
