[lldb-dev] Two CLs requiring changes to the Xcode project

Hi all, I submitted r252993 and 252994. These changes will require a corresponding change in the Xcode workspace. Would anyone mind making those changes for me? It should be pretty simple, just need to add a .cpp and .h file to the gtest target for ScriptInterpreterPythonTests, and add PythonEx

Re: [lldb-dev] Two CLs requiring changes to the Xcode project

Hmm, can you ask Todd about it? He said he added one, but I'm not sure how it works. On Thu, Nov 12, 2015 at 5:46 PM Jason Molenda wrote: > Done in r252998. > > I didn't see anything in the xcode project file about a gtest target. > > J > > > On Nov 12, 20

Re: [lldb-dev] Two CLs requiring changes to the Xcode project

he xcode project file about a gtest target. > > > > J > > > > > On Nov 12, 2015, at 5:39 PM, Zachary Turner via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > > > > > Hi all, > > > > > > I submitted r252993 and 252994. These c

Re: [lldb-dev] swig generation

On Fri, Nov 13, 2015 at 9:02 AM Todd Fiala via lldb-dev < lldb-dev@lists.llvm.org> wrote: > Hi all, > > I'd like to do a few things with our swig generation and handling: > > * Create a maintainer-mode style setup where the swig Python bindings are > generated and checked into the repo (I'll call

Re: [lldb-dev] swig generation

On Fri, Nov 13, 2015 at 10:24 AM Todd Fiala wrote: > On Fri, Nov 13, 2015 at 9:43 AM, Zachary Turner > wrote: > >> On Fri, Nov 13, 2015 at 9:02 AM Todd Fiala via lldb-dev < >> lldb-dev@lists.llvm.org> wrote: >> >>> Hi all, >>> >>> I'd like to do a few things with our swig generation and handling

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: > >> Breaking out the binding generation into

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

On Tue, Nov 17, 2015 at 8:03 PM Todd Fiala wrote: > Nothing concrete at the moment; however, it could be interesting to look > at the clang community and see what could be done for llvm-based language > implementations. The angle that I think would be interesting would be if > we can generate bi

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 > precedent for this g

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: > > My intent here is to only provide the --allow-static-binding option on > cmake if it is explicitly turned on. And it will be off by default. > I know, but I don't really like adding options that nobody is going to use, because it makes maint

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 doesn't break other > items. And then it does

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 swig, I'll be happy to re

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 would make the binding no

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

LLDBWrapPython.cpp https://drive.google.com/file/d/0Bzpf8QJC6OGOc0RZNGY1dEhBZzQ/view?usp=sharing> lldb.py https://drive.google.com/file/d/0Bzpf8QJC6OGOaEVaNF9GY0tPXzg/view?usp=sharing> Double check the top of lldb.py to make sure swig_version = (3,0,x) On Wed, Nov 18, 2015 at 1:14 PM Todd Fiala

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 Turn

[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 this

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

Re: [lldb-dev] LLDB Windows Python Bindings

+lldb-dev since this could be useful to other people. I'm actively working on getting Python 3.5 support working. If you want to go this route, it will make your life much easier. But I don't have a fully passing test suite yet, there are still about 30 failing tests. So consider Python 3.5 exp

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 until

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 { Ba

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 > in a header file, it

Re: [lldb-dev] bindings as service idea

Doh! lol On Thu, Nov 19, 2015 at 10:57 AM Sean Callanan wrote: > I don’t think so, this was just an embedded link to your hard drive: > > file:///C:/tools/swigwin-3.0.7/Doc/Manual/Python.html#Python_builtin_types > > Sean > > On Nov 19, 2015, at 10:51 AM, Zachary Turner

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. http://www.swig.org/Doc3.

Re: [lldb-dev] bindings as service idea

On Thu, Nov 19, 2015 at 10:28 AM Todd Fiala wrote: > Some other points we need to consider on the bindings-as-service idea: > > * The service should be exposed via secure connection (https/ssl/etc.) > This might already be guaranteed on the Google end by virtue of the > endpoint, but we'll want

Re: [lldb-dev] LLDB Windows Python Bindings

comm Innovation Center, Inc. is a member of Code Aurora Forum, a >> Linux Foundation Collaborative Project >> >> >> >> *From:* lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] *On Behalf Of >> *Zachary >> Turner via lldb-dev >> *Sent:* Thursday, Novembe

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 upstream. > Right, and this is actua

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 won'

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] LLDB Windows Python Bindings

On Fri, Nov 20, 2015 at 10:05 AM Aidan Dodds wrote: > First off thanks for opening that up to the mailing list, it will be good > if discussion of this is useful to others. > > From the python 3.5 case: > I'm not using ninja.build, but instead just compiling from the visual > studio ide. However

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

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, > find out wh

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 that

[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

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 y

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

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, Todd Fiala wrote: > >>

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 mod

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: > Oh yea, I made up that

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 to

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

Yea I was messing around with it too. I don't have a fix yet but I think you will need to either encode the pickled data as utf8, or better yet, don't write this: "{}#{}".format(...) because pickled data is supposed to be binary data anyway. So use bytes.append() instead. Then on the other sid

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: > > import s

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

think I got something working, I'll upload a patch in a few. On Wed, Dec 2, 2015 at 2:10 PM Zachary Turner wrote: > 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

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 o

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?

dule. On Wed, Dec 2, 2015 at 3:15 PM Jim Ingham 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@lists.llvm.org

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 bun

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

In other words, instead of printing this: FAIL: TestDataFormatterPythonSynth.PythonSynthDataFormatterTestCase.test_rdar10960550_with_run_command_dwo (D:\src\llvm\tools\lldb\packages\Python\lldbsuite\test\functionalities\data-formatter\data-formatter-python-synth\TestDataFormatterPythonSynth.py) P

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 lead to the same class na

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 one class per file anyway, so the classname is just wasted

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: >> >>> >>> >>> On Wed, Dec 2, 2015 at 9:44 PM Todd Fiala wrot

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

It would also be nice if the summary statistics were printed after the list of failing / errored tests. The reason is that it involves a fixed number of lines to print the table, but the list of failures and errors is a variable number of lines which could potentially be very long and push the sta

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 to

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

to start working on this on Wednesday. On Fri, Nov 20, 2015 at 5:17 PM Todd Fiala 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

> 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 potentially delete anything th

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

bles will switch over to use the "g_options." instead. Then we > don't have to 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.ll

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

ions >> 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" and anyone that was using any global >> variables will switch over to

[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] swig generation and "six" module

What about requiring that the user has done "pip install six" on their machine? On Wed, Dec 9, 2015 at 1:40 PM Ted Woodward via lldb-dev < lldb-dev@lists.llvm.org> wrote: > r252764 changes finishSwigPythonLLDB.py to symlink the “six” module in > site-packages. six.py is a symlink to > /tools/lldb

Re: [lldb-dev] Benchmark tests

at 1:22 PM, Todd Fiala via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > Hey Jason, > > Are you the benchmark user? > > -Todd > > On Wed, Dec 9, 2015 at 12:32 PM, Zachary Turner via lldb-dev < > lldb-dev@lists.llvm.org>

Re: [lldb-dev] swig generation and "six" module

I don't mind it being a copy instead of a link, I had just been thinking about getting rid of that workflow anyway and requiring a pip install. But if you can't do that, then scratch that idea. Feel free to change it to a copy and upstream that if it makes your life easier. Just to be clear thou

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 the test function failing with the name of the

[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] Separating test runner and tests

the "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 mess

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

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" type of >>>>> questi

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

ld off on any significant change like >>>>>>> that >>>>>>> until this little bit is done as I'm sure we'll collide, particularly >>>>>>> since >>>>>>> this hits dosep.py pretty significantly. >>>>

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

shift a number of things >>>>>>>> around, >>>>>>>> you can do that. >>>>>>>> >>>>>>>> I'm just about done with the multi-pass running. I expect to get >>>>>>

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

as they'll >>>>>>>>>> be the >>>>>>>>>> things at the end of the chain. >>>>>>>>>> >>>>>>>>>> Minor detail, result_formatter.py should be results_formatter.py >>>>>>&g

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

>>>>>>>>>>>> >>>>>>>>>>>> FWIW the test events model will likely shift a bit, as it is >>>>>>>>>>>> currently a single sink, whereas I am likely to turn it into a >>>>

[lldb-dev] Problem with dotest_channels.py

Hi Todd, lately I've been seeing this sporadically when running the test suite. [TestNamespaceLookup.py FAILED] Command invoked: C:\Python27_LLDB\x86\python_d.exe D:\src\llvm\tools\lldb\test\dotest.pyc -q --arch=i686 --executable D:/src/llvmbuild/ninja/bin/lldb.exe -s D:/src/llvmbuild/ninja/lldb-t

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 wrote: > >> H

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

> 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] >> Command invoked: C:\Py

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. Thanks! > > On Mon, Dec 14,

Re: [lldb-dev] test rerun phase is in

I've checked in r255567 which fixes a problem pointed out by Siva. It doesn't sound related to in 255542, but looking at those logs I can't really tell how my CL would be related. If r255567 doesn't fix the bots, would someone mind helping me briefly? r255542 seems pretty straightforward, so I d

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

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, Dec 14, 2015 at 2:03 PM Todd Fiala >>>> wrote: &g

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, thi

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 m

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 blog post at some point

[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 l

Re: [lldb-dev] LLDB build at windows

Should look like this: llvm |__ tools |__ clang |__ lld |__ lldb You will need clang because lldb needs to link against it, and you will need lld because lldb on Windows doesn't (yet) understand PDB, so you have to compile your programs with clang.exe -fuse-ld=lld On Sat, Jan 9,

Re: [lldb-dev] LLDB build at windows

I have never built with -DLLVM_INCLUDE_TESTS=OFF -DCLANG_INCLUDE_EXAMPLES=OFF -DCLANG_INCLUDE_TESTS=OFF before, so that could be related. Can you try removing those options on CMake to see if that fixes it? The other thing I do differently is I use ninja generator. So I use -G Ninja instead of -

Re: [lldb-dev] LLDB build at windows

Yea, unfortunately the way things work is that the person who is affected by the problem and who needs it fixed is usually the one that needs to fix it. Right now we don't have any Windows people building inside Visual Studio, so nobody has fixed that. But you're welcome to submit a patch :) FWI

Re: [lldb-dev] LLDB build at windows

> without problems. > > > On 11/01/2016 18:48, Zachary Turner via lldb-dev wrote: > > Yea, unfortunately the way things work is that the person who is affected > by the problem and who needs it fixed is usually the one that needs to fix > it. Right now we don't hav

Re: [lldb-dev] LLDB build at windows

When we move to VS 2015 (which will be soon, btw) we will require Python 3.5+ on Windows. This already works for the most part, you can even try it out today. I've spent the better part of the past 6 months making LLDB's python bindings work with Python 3. The best part is that you don't need to

Re: [lldb-dev] lldb tests and tear down hooks

unneeded and you can just push "self.foo" --- that > cleanup hook pushed on most tests at the end of the file is a perfect > example of an unneeded level of lambda indirection). > > On Wed, Oct 21, 2015 at 12:04 PM, Zachary Turner via lldb-dev < > lldb-dev@lists.llvm.org&

Re: [lldb-dev] lldb tests and tear down hooks

There's no reason a finally block inside each test method wouldn't work, and that's probably the simplest solution. On Fri, Jan 15, 2016 at 12:59 AM Pavel Labath wrote: > On 14 January 2016 at 21:52, Zachary Turner via lldb-dev > wrote: > > So what if tests could

Re: [lldb-dev] Getting lldb tests working on Hexagon

If it should never run with x86_64 on Hexagon, then don't bother using command lines, just change dotest.py so that when the target is hexagon, the default archs doesn't include x86_64 On Wed, Jan 20, 2016 at 9:48 AM Ted Woodward via lldb-dev < lldb-dev@lists.llvm.org> wrote: > I’m trying to get

Re: [lldb-dev] Getting lldb tests working on Hexagon

Apparently I'm dumb, you actually should specify archs. For example, on Windows we use --arch=i686 If you don't specify a value for --arch, it uses the result of `platform.machine()`. If you do, it uses the list that you specify. So basically if you say --arch=i386 or something like, it will us

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

I'm not sure I agree. I don't think anything will be awkwardly formatted with regards to the rest of the file. The biggest thing this is going to fix are whitespace at the end of lines, line breakign conventions, and space between function name and parentheses. If we're not going to enforce a co

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

Also this is the same standard that applies to the rest of LLVM. clang-format your patches. Just because we haven't been consistently following the rules until now doesn't mean we should continue to not follow the rules going forward. This way eventually the codebase slowly converges towards a p

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

On Thu, Jan 21, 2016 at 11:18 AM Sean Callanan wrote: > I tend to agree with Zachary on the overall principle – and I would be > willing to clang-format functions when I modify them. I’m concerned about > a specific class of functions, though. Let’s say I have a function that > has had lots of

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

By the way, one place where you are guaranteed to get undesirable results is where you have a large array formatted so that the columns line up. Like in our options tables in the CommandObjects. If you're using git, one way to avoid having clang-format touch these files is to commit that file by i

Re: [lldb-dev] lldb status at windows

When you compile, you need to use -fuse-ld=lld. Most people miss this step. That said, it's not supposed to hang, but it is supposed to not work. What's the command line you used with clang? On Fri, Jan 22, 2016 at 11:08 AM Red Skotina wrote: > Look like I miss something , but i cant debug si

Re: [lldb-dev] lldb status at windows

Under llvm/tools also checkout lld. So your directories should look like this: llvm \-- tools \-- clang \-- lldb \-- lld Then re-run cmake to generate build files again, recompile, and then it should work. Right now the problem is that lld-link.exe hasn't been compiled yet. On Fri,

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

Oh neat, I didn't know about that. I'll play around with that when I have some time and see how the behavior works with respect to git clang-format (which formats diffs instead of entire files) On Fri, Jan 22, 2016 at 12:29 PM Pavel Labath wrote: > Apparently, you can also disable the formattin

Re: [lldb-dev] lldb status at windows

Ahh you probably need to add -g to clang, otherwise it's not generating debug info. I've never tried debugging a binary with no debug info. Obviously it shouldn't hang, but either way it's just not something we've tested on Windows. On Sat, Jan 23, 2016 at 12:51 AM Red Skotina wrote: > yes. i

Re: [lldb-dev] lldb status at windows

I'm out of office until Monday, but I'll try to reproduce this then and update. Never seen a hang before, so I wonder if there's something different about your machine that we haven't thought of or taken into account. Either way I'll update Monday. On Sat, Jan 23, 2016 at 12:57 AM Red Skotina w

Re: [lldb-dev] something just toasted the test suite on OS X

sorry, yea I stuck around for a while after that patch waiting for emails, but nothing came through. Please revert in the meantime, I'll work on a fix tomorrow. On Mon, Jan 25, 2016 at 8:52 PM Todd Fiala via lldb-dev < lldb-dev@lists.llvm.org> wrote: > I think I see what happened w/r/t why no em

Re: [lldb-dev] something just toasted the test suite on OS X

I'm also not sure why Linux isn't failing. Looking at the documentation for io.write https://docs.python.org/2/library/io.html#text-i-o> object, i see this: write(*s*) Write the unicode

Re: [lldb-dev] something just toasted the test suite on OS X

No worries, worst case scenario a sledgehammer solution is to change all the places where we write to the session file to convert to unicode first (which would be a trivial conversion, since everything is going to be ascii, which is already valid utf 8). The reason a problem arose at all is becaus

Re: [lldb-dev] something just toasted the test suite on OS X

Can one of you guys try out this patch and see if it works? If so I'll commit it. I don't know of a way to make this "elegant". i.e. a single syntax / paradigm that works in both versions without introducing any helper functions. On Tue, Jan 26, 2016 at 12:26 AM Zachary Turner wrote: > No wo

Re: [lldb-dev] something just toasted the test suite on OS X

Bump. Can I re-submit this? On Tue, Jan 26, 2016 at 10:54 AM Zachary Turner wrote: > Can one of you guys try out this patch and see if it works? If so I'll > commit it. > > I don't know of a way to make this "elegant". i.e. a single syntax / > paradigm that works in both versions without intr

  1   2   3   4   5   6   7   >