Re: [lldb-dev] test results look typical?

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

[lldb-dev] PSA: Python "print" statement disabled in trunk

If you sync to tip, you will pull in r251121, which disables the use of the print statement in Python. This is because in Python 3, the print statement has been removed in favor of the print function. You will see that that the top of every file, the line "from __future__ import print_function"

Re: [lldb-dev] Moving pexpect and unittest2 to lldb/third_party

;>> >>>>> The unittest2 stuff looks like it was a vestige of being incorporated >>>>> before unittest2 was stock (unitest) on Python 2.[6,7]?. Everyone should >>>>> have a unitest included that is effectively what we use as unittest2. >>&g

Re: [lldb-dev] Help with MSVC build issues

The classes appear to be all forward declared intentionally, so you'd need to include a lot of missing files. Just moving the destructor to cpp file should be pretty easy and still allow to keep the header footprint down, which speeds up build times. On Thu, Oct 22, 2015 at 11:22 AM Eugene

Re: [lldb-dev] Help with MSVC build issues

For the disassembler patch, the problem is you've defaulted the destructor but you've got a unique_ptr to a forward declared class. MSVC is actually correct in failing to compile this, and I'm not sure why other compilers are accepting it. My guess is something to do with the order of includes

Re: [lldb-dev] Moving pexpect and unittest2 to lldb/third_party

test) on Python 2.[6,7]?. Everyone should >>> have a unitest included that is effectively what we use as unittest2. >>> >>> -Todd >>> >>> On Thu, Oct 22, 2015 at 10:05 AM, Zachary Turner via lldb-dev < >>> lldb-dev@lists.llvm.org> wrote: &

Re: [lldb-dev] Refactoring dotest as a Python package

I think I have a way to split this into two smaller CLs. I'm testing this at the moment, if so it will allow the first CL to be most of the preparation for the rename without the rename, and then the second CL should literally just be a straight move with only 1-2 line code change. So I'll try to

Re: [lldb-dev] Refactoring dotest as a Python package

I have the first part of the patch in, and the second part of the patch (which is essentially just a whole-folder rename with a couple of fixups) ready to go. What's the best way to have this reviewed? Uploading a 7MB patch to Phabricator probably isn't going to work out very well. On Tue, Oct

Re: [lldb-dev] Refactoring dotest as a Python package

a review of the details of this stage. If you think there's >>> anything tricky call it out in words, otherwise I say just commit it. >>> >>> Jim >>> >>> >>> > On Oct 27, 2015, at 4:30 PM, Zachary Turner via lldb-dev < >>> l

Re: [lldb-dev] Refactoring dotest as a Python package

in with your path to your lldb root. >> >> It is unable to find lldb because lldbtest_config.lldbExec isn't set >> correctly... >> >> >> > On Oct 28, 2015, at 12:21 PM, Zachary Turner via lldb-dev < >> lldb-dev@lists.llvm.org> wrote: >> > >> > Commit

Re: [lldb-dev] Refactoring dotest as a Python package

-C clang -v -t > /.../packages/Python/lldbsuite/test/functionalities/completion > > fill "..." in with your path to your lldb root. > > It is unable to find lldb because lldbtest_config.lldbExec isn't set > correctly... > > > > On Oct 28, 2015, at 12:21 PM,

Re: [lldb-dev] lldb-gtest scheme and target added to Xcode project

Nice! Out of curiosity, do all the unittests pass? (I expect they do, as they do everywhere else, just wondering) On Sun, Oct 25, 2015 at 2:57 PM Todd Fiala via lldb-dev < lldb-dev@lists.llvm.org> wrote: > This should be fixed with: > $ svn commit > unittests/Editline/CMakeLists.txt >

Re: [lldb-dev] command line for running the format checker?

git clang-format should do it. There are two things it doesn't handle: 1) It puts constructor initializer list separators (comma and colon) at the beginning of each line instead of at the end of each line. 2) It doesn't put return type on a separate line for declarations (but it does for

Re: [lldb-dev] Help with MSVC build issues

I'm taking a look now. In the future please revert changes that break a buildbot. If you think you might know what the fix is (i.e. you guess that including a header will fix it), then you can just check it in as a test. If after a few attempts you still can't figure it out, then revert the

Re: [lldb-dev] Moving pexpect and unittest2 to lldb/third_party

erence to unittest2 from them for simplicity if > nobody have an objection against it. > > Tamas > > On Wed, Oct 21, 2015 at 8:57 PM Zachary Turner via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > >> *TL;DR - Nobody has to do anything, this is just a heads up that a 4

Re: [lldb-dev] Moving pexpect and unittest2 to lldb/third_party

wrote: > >> I believe it would import lldb correctly. I don't tend to run the tests >> individually, but if it did work, I would use it more. >> >> > On Oct 22, 2015, at 9:26 AM, Zachary Turner via lldb-dev < >> lldb-dev@lists.llvm.org> wrote: >>

Re: [lldb-dev] Help with MSVC build issues

It looks like you're generating these diffs from an SVN repo, so I'm seeing lldb/trunk in the paths. Because of that, I can't apply it on my git repo which doesn't have the "trunk" folder. Can you generate the diffs for the 2 aforementioned CLs by cding into the trunk directory and generating

[lldb-dev] Does anyone depend on using LLDB with Python 2.6?

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

Re: [lldb-dev] proposal for reworked flaky test category

Don't get me wrong, I like the idea of running flakey tests a couple of times and seeing if one passes (Chromium does this too as well, so it's not without precedent). If I sounded harsh, it's because I *want* to be harsh on flaky tests. Flaky tests indicate literally the *worst* kind of bugs

[lldb-dev] RFC: Making unit tests run by default on ninja check-lldb

Right now there are two ninja check targets: "ninja check-lldb", which runs dotest and all of the SB API tests, and "ninja check-lldb-unit" which runs the gtest unit test suite. I would like to make unit tests run by default. This entails two things, which could be done independently of each

Re: [lldb-dev] Python object lifetimes affect the reliability of tests

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,

Re: [lldb-dev] Python object lifetimes affect the reliability of tests

*currently being processed*, still returns something after it is finished being processed. On Thu, Oct 15, 2015 at 11:36 AM Ryan Brown <rib...@google.com> wrote: > Couldn't we just change DeleteTarget to make sure everything is unmapped? > > On Thu, Oct 15, 2015 at 11:34 AM Zachary Turn

Re: [lldb-dev] Python object lifetimes affect the reliability of tests

e: > >> Couldn't we just change 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: >>>

Re: [lldb-dev] Python object lifetimes affect the reliability of tests

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"

Re: [lldb-dev] Testing through api vs. commands

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

Re: [lldb-dev] " Import error: No module named embedded_interpreter" on windows

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

Re: [lldb-dev] Python 3 and dotest

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.

Re: [lldb-dev] [Lldb-commits] [lldb] r253317 - Add Pythonic language binding wrapper generation script.

On Wed, Nov 18, 2015 at 10:00 AM Todd Fiala wrote: > Checking in the static bindings is no different than projects checking in > autoconf config baked scripts so that the vast majority of people don't > need to run autoconf just to get a setup that rarely changes. There is

Re: [lldb-dev] [Lldb-commits] [lldb] r253317 - Add Pythonic language binding wrapper generation script.

Moving this back over to the list since I'm sure others have some input here. Also +lldb-dev since it has more visibility than lldb-commits. On Tue, Nov 17, 2015 at 11:25 AM Zachary Turner wrote: > On Tue, Nov 17, 2015 at 8:18 AM Todd Fiala wrote: >

Re: [lldb-dev] [Lldb-commits] [lldb] r253317 - Add Pythonic language binding wrapper generation script.

On Wed, Nov 18, 2015 at 11:15 AM Todd Fiala wrote: > On Wed, Nov 18, 2015 at 10:34 AM, Zachary Turner > wrote: > >> Because even if it isn't perfect for everyone, it works for everyone. >> > > Unless you can't get swig on your system in a way that

Re: [lldb-dev] [Lldb-commits] [lldb] r253317 - Add Pythonic language binding wrapper generation script.

(This is originally from a thread on lldb-commits, but it seems more appropriate here, so I'm responding here. On Wed, Nov 18, 2015 at 12:47 PM Todd Fiala wrote: > BTW if you cook up something on the swig-as-a-service end that ends up > working to eliminate the need for

[lldb-dev] How does attach work on non-Windows?

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

Re: [lldb-dev] How does attach work on non-Windows?

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

Re: [lldb-dev] Can Process hold a TargetSP instead of a Target&?

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

Re: [lldb-dev] top-of-tree build failure when using configure on Linux?

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

Re: [lldb-dev] Windows build questions

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

[lldb-dev] Test suite rebuilding test executables many times

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

Re: [lldb-dev] Windows build questions

+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

Re: [lldb-dev] Testing through api vs. commands

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

[lldb-dev] Testing through api vs. commands

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

Re: [lldb-dev] Testing through api vs. commands

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

Re: [lldb-dev] Testing through api vs. commands

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

Re: [lldb-dev] r247953 - TypeSystem is now a plugin interface

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 >

Re: [lldb-dev] r247953 - TypeSystem is now a plugin interface

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,

Re: [lldb-dev] top-of-tree build failure when using configure on Linux?

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

Re: [lldb-dev] changing default test runner from multiprocessing-based to threading-based

, Sep 22, 2015 at 2:32 AM, Tamas Berghammer <tbergham...@google.com >> > 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 thread

Re: [lldb-dev] r247953 - TypeSystem is now a plugin interface

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=rev > > It has broken TestCppValueCast on Windows and fixed TestCxxWcharT on > Windows as well.

Re: [lldb-dev] cmake question and [PATCH] for Undefined symbol "_liblldb_coreVersionString"

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

Re: [lldb-dev] changing default test runner from multiprocessing-based to threading-based

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

Re: [lldb-dev] Moving test runner timeout logic into Python

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

Re: [lldb-dev] Moving test runner timeout logic into Python

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

Re: [lldb-dev] Moving test runner timeout logic into Python

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

Re: [lldb-dev] Auditing dotest's command line options

on this on Wednesday. On Fri, Nov 20, 2015 at 5:17 PM Todd Fiala <todd.fi...@gmail.com> wrote: > Yeah that would be awesome, and also would be a lot of work. Good luck! > > > On Fri, Nov 20, 2015 at 10:37 AM, Zachary Turner via lldb-dev < > lldb-dev@lists.llvm.org> wrote

Re: [lldb-dev] Auditing dotest's command line options

ettings that are > required. > > > On Nov 18, 2015, at 2:32 PM, Zachary Turner via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > > > I would like to do a complete audit of dotest's command line options, > find out who's using what, and then potenti

Re: [lldb-dev] Auditing dotest's command line options

t;> use a python library to parse the options, but we mostly copied the options >> from the options dictionary over into the globals and still use the globals >> all over the code. It would be great if we had at most one global variable >> that is something like "g_options&qu

Re: [lldb-dev] New test summary results formatter

Can --results-file=stdout be the default so that we don't have to specify that? On Wed, Dec 2, 2015 at 11:02 AM Todd Fiala via lldb-dev < lldb-dev@lists.llvm.org> wrote: > Also, all the text in the summary is fixed-width lined up nicely, which > may not show in the commit message description if

Re: [lldb-dev] New test summary results formatter

Also another stylistic suggestion. I've been thinking about how to more logically organize all the source files now that we have a package. So it makes sense conceptually to group all of the different result formatters under a subpackage called formatters. So right now you've got

Re: [lldb-dev] static swig bindings and xcode workspace

Ahh, that's a bummer if true. Because `contrib` is a nice way to group together all the things that all the things that have specific maintainers and so everyone else is allowed to break. On Wed, Dec 2, 2015 at 11:04 AM Todd Fiala wrote: > On Wed, Dec 2, 2015 at 8:28 AM,

Re: [lldb-dev] New test summary results formatter

Oh yea, I made up that decorator idea because I didn't know all the formatters were derived from a common base. But your idea is better if everything is derived from a common base. To be honest you could even just generate an error if there are two ResultsFormatter derived classes in the same

Re: [lldb-dev] New test summary results formatter

When I run this under Python 3 I get "A bytes object is used like a string" on Line 1033 of test_results.py. I'm going to dig into it a little bit, but maybe you know off the top of your head the right way to fix it. On Wed, Dec 2, 2015 at 11:32 AM Zachary Turner wrote: >

Re: [lldb-dev] New test summary results formatter

Is there any way to force the single process test runner to use this same system? I'm trying to debug the problem, but this codepath doesn't execute in the single process test runner, and it executes in the child process in the multiprocess test runner. Basically I need the following callstack

Re: [lldb-dev] New test summary results formatter

I think the best solution is going to be to use struct.pack. Like this on the writing side: import struct msg = cPickle.dumps(test_event) packet = struct.pack("!I%ds" % len(msg), len(msg), msg) self.out_file.send(packet) and like this on the reading side:

Re: [lldb-dev] New test summary results formatter

BTW, this is what I do in the swig service, and I think it's the idiomatic way of sending variable length data over a socket. On Wed, Dec 2, 2015 at 2:08 PM Zachary Turner wrote: > I think the best solution is going to be to use struct.pack. Like this on > the writing side:

Re: [lldb-dev] Running lldb tests?

You shouldn't have to point it anywhere. Just run lldb/test/dotest.py the same way you're currently running it and it should work if you use the right script. That use_lldb_suite also adds the location of the test folder to sys.path so it can find it. The reason all this happened and everything

Re: [lldb-dev] Running lldb tests?

Couple things: 1) Python 2.7.10 is still the officially supported way to run tests for all platforms 2) Python 3 is only supported for Windows and it's experimental. 3) At some point I will drop support for 2.x on Windows, but 2.x will always be the officially supported way to run tests on every

Re: [lldb-dev] New test summary results formatter

On Wed, Dec 2, 2015 at 9:44 PM Todd Fiala wrote: > > >> and the classname could be dropped (there's only one class per file >> anyway, so the classname is just wasted space) >> > > Part of the reason I included that is I've hit several times where copy > and paste errors

Re: [lldb-dev] Running lldb tests?

Wed, Dec 2, 2015 at 3:15 PM Jim Ingham <jing...@apple.com> wrote: > Should we change the name of lldb/packages/Python/lldbsuite/dotest.py to > something else to avoid this confusion? > > Jim > > > On Dec 2, 2015, at 2:48 PM, Zachary Turner via lldb-dev < > lldb-dev@l

Re: [lldb-dev] New test summary results formatter

Now that it's working in Python 3 and I've had a chance to see the output, I think I like it much better. These are the things I noticed (good and bad): 1) Output of each test is printed on the fly as the test is run. Much better than staring at a black screen for 5 minutes and then seeing a

Re: [lldb-dev] Windows Buildbot binaries

We don't have anything set up like this at the moment unfortunately. It could happen in the future, but we've been spending our limited amount of Windows resources making new debugging scenarios work, and just haven't gotten to this. I'd be happy to help diagnose build errors if you're willing

Re: [lldb-dev] New test summary results formatter

On Wed, Dec 2, 2015 at 10:20 PM Todd Fiala wrote: > On Wed, Dec 2, 2015 at 9:48 PM, Zachary Turner wrote: > >> >> >> On Wed, Dec 2, 2015 at 9:44 PM Todd Fiala wrote: >> >>> >>> and the classname could be dropped (there's only

Re: [lldb-dev] New test summary results formatter

Ahh I read further and see this was already mentioned by Pavel. On Thu, Dec 3, 2015 at 10:06 AM Zachary Turner wrote: > On Wed, Dec 2, 2015 at 10:20 PM Todd Fiala wrote: > >> On Wed, Dec 2, 2015 at 9:48 PM, Zachary Turner >> wrote:

[lldb-dev] Benchmark tests

Is anyone using the benchmark tests? None of the command line options related to the benchmark tests were claimed as being used by anyone. Which makes me wonder if the tests are even being used

Re: [lldb-dev] BasicResultsFormatter - new test results summary

On Thu, Dec 10, 2015 at 12:54 PM Todd Fiala wrote: > Hi Tamas, > > > > On Thu, Dec 10, 2015 at 2:52 AM, Tamas Berghammer > wrote: > >> HI Todd, >> >> You changed the way the test failure list is printed in a way that now we >> only print the name of

Re: [lldb-dev] Separating test runner and tests

"which dotest should I run" type of >> questions... >> - there is nothing that makes it obvious that "engine" is actually a >> "test running engine", as it sits in a sibling folder. OTOH, >> "test_engine" might be too verbose, and messes up

Re: [lldb-dev] Problem with dotest_channels.py

gt;>>> If nothing else, maybe we can print out a more useful exception >>>> backtrace. What kind of exception, what line, and what was the message? >>>> That might help give us a better idea of what's causing it. >>>> >>>> On Mon, De

[lldb-dev] Separating test runner and tests

Currently our folder structure looks like this: lldbsuite |-- test |-- dotest.py |-- dosep.py |-- lldbtest.py |-- ... |-- functionalities |-- lang |-- expression_command |-- ... etc I've been thinking about organizing it like this instead: lldbsuite |-- test

Re: [lldb-dev] Problem with dotest_channels.py

i Zachary! > > > > > > On Mon, Dec 14, 2015 at 1:28 PM, Zachary Turner via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > >> Hi Todd, lately I've been seeing this sporadically when running the test >> suite. >> >> [TestNamespaceLookup.py FAILED] >> Co

Re: [lldb-dev] debug info test failures

Yea I think r255542 fixes it, or at least it was supposed to. Let me know On Mon, Dec 14, 2015 at 2:04 PM Todd Fiala wrote: > Okay. I appeared to be up to date when hitting it, but we may have > crossed on it. > > I'll take out the skip if I am not hitting it now.

Re: [lldb-dev] debug info test failures

I believe I already fixed this issue On Mon, Dec 14, 2015 at 1:53 PM Todd Fiala via lldb-dev < lldb-dev@lists.llvm.org> wrote: > I temporarily skipped these tests on Darwin and Linux here: > r255549 > > I'll file a bug in a moment... > > On Mon, Dec 14, 2015 at 1:42 PM, Todd Fiala

Re: [lldb-dev] Separating test runner and tests

.org> wrote: >>>> >>>>> Sounds like a reasonable thing to do. A couple of tiny remarks: >>>>> - when you do the move, you might as well rename dotest into something >>>>> else, just to avoid the "which dotest should I run&quo

Re: [lldb-dev] Patch for addressing format warnings on 32-bit

Incidentally, once we can start requiring VS 2015 %z will be supported there. Not sure if MSVC is the only supported platform that currently doesn't support %z On Mon, Jan 4, 2016 at 11:24 AM Greg Clayton via lldb-dev < lldb-dev@lists.llvm.org> wrote: > Please do cast to 64 bit and user PRI*64

Re: [lldb-dev] lldb status at windows

Feel free to file bugs or post your feedback here after you use about what worked, what didn't work, what's missing, etc. Anything that doesn't work is a bug that I would like to fix. On Thu, Jan 7, 2016 at 10:02 AM Zachary Turner wrote: > Hi, I guess I should make a new

[lldb-dev] clang-format now supports return type on separate line

As far as I'm aware, this is the last major incompatibility between LLDB's style and clang-format's feature set. I would appreciate it if more people could try it out with a few of their patches, and let me know if any LLDB style incompatibilities arise in the formatted code. I would eventually

Re: [lldb-dev] building on mac

Are the Xcode scripts using the llvm configure build? If so they will need to be changed to the CMake build sooner or later, because the configure build is going away in the near future. On Thu, Dec 17, 2015 at 3:18 PM Todd Fiala via lldb-dev < lldb-dev@lists.llvm.org> wrote: > Ah. > > Okay,

[lldb-dev] static swig bindings and xcode workspace

Has the xcode build been changed to use static bindings yet? I got to thinking that maybe it would make sense to put them alongside the xcode workspace folders, just to emphasize that the static bindings were an artifact of how the xcode build works. This way we just say "Xcode build uses static

[lldb-dev] Auditing dotest's command line options

I would like to do a complete audit of dotest's command line options, find out who's using what, and then potentially delete anything that isn't being used. There's a mess of command line options in use, to the point that it's often hard to find free letters to use for new options. I created

Re: [lldb-dev] reply： lldb debug jit-compiled code with llvm on windows

Can you also try clang-cl and see if it works? On Fri, Nov 20, 2015 at 3:02 AM Tamas Berghammer via lldb-dev < lldb-dev@lists.llvm.org> wrote: > I don't know how JIT debugging should work on WIndows with MSVC but I > don't think LLDB support it in any way. What I wrote should be true on > Linux

Re: [lldb-dev] Auditing dotest's command line options

gt; make copies and we can let the g_options contain all settings that are > required. > > > On Nov 18, 2015, at 2:32 PM, Zachary Turner via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > > > I would like to do a complete audit of dotest's command line options,

Re: [lldb-dev] bindings as service idea

On Thu, Nov 19, 2015 at 10:50 AM Zachary Turner wrote: > Well some of the bugfixes are actually worth mentioning, because we > actually have bugs on the C++ side that we can't fix because then SWIG > won't be able to process the header files. For example, if SWIG sees this >

Re: [lldb-dev] bindings as service idea

Well some of the bugfixes are actually worth mentioning, because we actually have bugs on the C++ side that we can't fix because then SWIG won't be able to process the header files. For example, if SWIG sees this in a header file, it errors out and can't even proceed. enum Foo : unsigned {

Re: [lldb-dev] bindings as service idea

I wasn't planning on working on this immediately, but given the outcome of the recent static bindings work, I can re-prioritize. I don't know how long it will take, because honestly writing this kind of thing in Python is new to me.. to make an understatement. But I'll get it done. Give me

Re: [lldb-dev] bindings as service idea

at 10:51 AM, Zachary Turner via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > > > On Thu, Nov 19, 2015 at 10:50 AM Zachary Turner <ztur...@google.com> > wrote: > >> Well some of the bugfixes are actually worth mentioning, because we >> actually have b

Re: [lldb-dev] bindings as service idea

Derp, I forgot C++11 support. Some of it is not useful to us given the limited nature of the SB API, but certain things could be useful. Being able to transition to enum classes is nice, for example. Anyway, there's a lot here, so feel free to read through the document.

Re: [lldb-dev] FW: LLDB Windows Python Bindings

On Thu, Nov 19, 2015 at 1:39 PM Ted Woodward via lldb-dev < lldb-dev@lists.llvm.org> wrote: > Why can’t we use VS 2015 with Python 2.7? > Python 2.7 literally does not even compile with VS 2015, you would have to fork it and fix the compilation errors. I've tried to upstream fixes and they

Re: [lldb-dev] bindings as service idea

On Thu, Nov 19, 2015 at 1:38 PM Ted Woodward wrote: > For our builds at QUIC, we're not interested in hitting an external server > to get code. So we'd either hit the server when needed and check in the > resultant bindings, or (preferably) use bindings from

Re: [lldb-dev] if you look at binding-generation-as-service element...

Can I send you a sample set of bindings generated by 3.x as a fail-fast test? Try them out, see if anything breaks, etc? On Wed, Nov 18, 2015 at 1:07 PM Todd Fiala wrote: > Hey Zachary, > > Please make sure to ping Greg Clayton, particularly if it does anything > that

Re: [lldb-dev] if you look at binding-generation-as-service element...

LLDBWrapPython.cpp lldb.py Double check the top of lldb.py to make sure swig_version = (3,0,x) On Wed, Nov 18,

Re: [lldb-dev] if you look at binding-generation-as-service element...

Err, links aren't showing up for me. Gonna try this again. lldb.py - https://drive.google.com/file/d/0Bzpf8QJC6OGOaEVaNF9GY0tPXzg/view?usp=sharing LLDBWrapPython.cpp- https://drive.google.com/file/d/0Bzpf8QJC6OGOaEVaNF9GY0tPXzg/view?usp=sharing On Wed, Nov 18, 2015 at 1:19 PM Zachary

Re: [lldb-dev] Exclusively build and install LLDB?

LLDB links against clang and llvm. How would an lldb-only target work? i.e. how would you build lldb without first building clang and llvm? Unless I'm misunderstanding the purpose of your question: As for the install, are you saying that running "ninja install" does not install lldb? If so

Re: [lldb-dev] bindings as service idea

Just to re-iterate, if we use the bindings as a service, then I envision checking the bindings in. This addresses a lot of the potential pitfalls you point out, such as the "oops, you can't hit the network, no build for you" and the issue of production build flows not wanting to hit a third party

  1   2   3   4   5   >