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

On Fri, Dec 11, 2015 at 11:17 AM, Zachary Turner wrote: > Not sure I follow. Are you trying to test the execution engine itself > (dotest.py, lldbtest.py, etc) > This. Test the lldb highly-specialized test runner internals. > or are you trying to have another alternative to running individua

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

I think we can do this, and I'd like us to do this unless it's proven to break something we're not aware of. I think you did some research on this after we discussed last, but something (maybe in the decorators) didn't just work. Was that right? On Fri, Dec 11, 2015 at 11:18 AM, Zachary Turner

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

Okay. Sounds like something we can work around one way or another, either by introducing the correct exception name for unittest, or introducing our own if we need to do so. On Fri, Dec 11, 2015 at 11:22 AM, Zachary Turner wrote: > If I remember correctly it was in the way we had implemented on

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

Seems reasonable. On Fri, Dec 11, 2015 at 11:46 AM, Zachary Turner wrote: > I think the correct fix is to just not throw the exception, and do it the > right way. unittest doesn't even use an exception for that anymore, but > has some kind of method to tag the test as xfail or skip, whereas our

Re: [lldb-dev] marking new summary output for expected timeouts

I went ahead and added the expected timeout support in r255363. I'm going to turn back on the new BasicResultsFormatter as the default. We can flip this back off if it is still not doing everything we need, but I *think* we cover the issue you saw now. -Todd On Fri, Dec 11, 2015 at 10:14 AM, To

Re: [lldb-dev] marking new summary output for expected timeouts

Hey Pavel and/or Tamas, Let me know when we're definitely all clear on the expected timeout support I added to the (now once again) newer default test results. As soon as we don't need the legacy summary results anymore, I'm going to strip out the code that manages it. It is quite messy and dupl

Re: [lldb-dev] marking new summary output for expected timeouts

Oh yeah, that's fine. I won't take that code out. Hmm at least some of the builds went through this weekend, I made a number of changes Saturday morning (US Pacific time) that I saw go through the Ubuntu 14.04 cmake bot. On Mon, Dec 14, 2015 at 6:29 AM, Pavel Labath wrote: > Hi, > > we've had

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

On Mon, Dec 14, 2015 at 6:58 AM, Pavel Labath wrote: > Hi, > > thanks a lot for fixing the timeout issue on such a short notice. Sure thing. I didn't mind at all once I understood the context in which they were being used. > I > didn't think I'd find myself defending them, as I remember bein

[lldb-dev] test rerun phase is in

Hi all, I just put in the single-worker, low-load, follow-up test run pass in r255543. Most of the work for it went in late last week, this just mostly flips it on. The feature works like this: * First test phase works as before: run all tests using whatever level of concurrency is normally use

[lldb-dev] debug info test failures

Hi all, I'm seeing locally on OS X the same build failures that I'm seeing on the ubuntu 14.04 cmake builedbot: ERROR: TestWithLimitDebugInfo.TestWithLimitDebugInfo.test_limit_debug_info_dwarf (lang/cpp/limit-debug-info/TestWithLimitDebugInfo.py) ERROR: TestWithLimitDebugInfo.TestWithLimitDebugIn

Re: [lldb-dev] debug info test failures

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: > Hi all, > > I'm seeing locally on OS X the same build failures that I'm seeing on the > ubuntu 14.04 cmake builedbot: > > ERROR: > TestWithLi

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

Hi 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] > Command invoked: C:\Python27_LLDB\x86\python_d.exe > D:\src\llvm

Re: [lldb-dev] debug info test failures

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, 2015 at 2:01 PM, Zachary Turner wrote: > I believe I already fixed this issue > > On Mon, Dec 14, 2015 at 1:53 PM Todd

Re: [lldb-dev] debug info test failures

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

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

Yeah that's a messed up exception scenario that is hard to read. I'll figure something out when I repro it. One side is closing before the other is expecting it, but likely in a way we need to expect. I think it is ugly-ified because it is coming from some kind of worker thread within async-core

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

I am seeing several failures on the Ubuntu 14.04 testbot, but unfortunately there are a number of changes that went in at the same time on that build. The failures I'm seeing are not appearing at all related to the test running infrastructure. Anybody with a fast Linux system able to take a look t

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

Ah yes I see. Thanks, Ying (and Siva! Saw your comments too). On Mon, Dec 14, 2015 at 2:34 PM, Ying Chen wrote: > Seems this is the first build that fails, and it only has one CL 255542 > . > > http://lab.llvm.org:8011/builders/lld

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

Hey Zachary, I just put in: r255581 which should hopefully: (1) catch the exception you see there, (2) handle it gracefully in the common and to-be-expected case of the test inferior going down hard, and (3) print out an error if anything else unexpected is happening here. Let me know if you get

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

I'm having some of these blow up. In the case of test/lang/c/typedef/Testtypedef.py, it looks like some of the @expected decorators were changed a bit, and perhaps they are not pound for pound the same. For example, this test used to really be marked XFAIL (via an expectedFailureClang directive),

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

The full set that are blowing up are: = Issue Details = FAIL: test_expr_stripped_dwarf (lang/objc/hidden-ivars/TestHiddenIvars.py) FAIL: test_frame_variable_stripped_dwarf (lang/objc/hidden-ivars/TestHiddenIvars.py) FAIL: test_typedef_dsym (lang/c/typedef/Testtypedef.py) FA

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

Yep, will try now... (I was just looking at the condition testing logic since it looks like something isn't quite right there). On Mon, Dec 14, 2015 at 4:39 PM, Siva Chandra wrote: > Can you try again after taking my change at r255584? > > On Mon, Dec 14, 2015 at 4:31 PM, Todd

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

right there). > > On Mon, Dec 14, 2015 at 4:39 PM, Siva Chandra > wrote: > >> Can you try again after taking my change at r255584? >> >> On Mon, Dec 14, 2015 at 4:31 PM, Todd Fiala via lldb-dev >> wrote: >> > I'm having some of these blow up. >> >

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

t;> Yep, will try now... (I was just looking at the condition testing logic >> since it looks like something isn't quite right there). >> >> On Mon, Dec 14, 2015 at 4:39 PM, Siva Chandra >> wrote: >> >>> Can you try again after taking my change at r

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

Mon, Dec 14, 2015 at 4:39 PM, Siva Chandra >>> wrote: >>> >>>> Can you try again after taking my change at r255584? >>>> >>>> On Mon, Dec 14, 2015 at 4:31 PM, Todd Fiala via lldb-dev >>>> wrote: >>>> > I'm having some

[lldb-dev] expected timeouts and reruns

Hi all, If you happen to use --rerun-all-issues to turn on test rerunning (via single worker thread) for any failed issue, one thing to be aware of is that expected timeouts that do time out will not be rerun. They are not eligible for rerun (at least as of r255641) since they wouldn't cause the

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

ilds/4305/steps/test7/logs/stdio > > Thanks, > Ying > > On Mon, Dec 14, 2015 at 4:52 PM, Todd Fiala via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > >> And, btw, this shows the rerun logic working (via the --rerun-all-issues >> flag): >> >> time test

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

ubuntu-14.04-android/builds/4305/steps/test3/logs/stdio >> >> http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-android/builds/4305/steps/test7/logs/stdio >> >> Thanks, >> Ying >> >> On Mon, Dec 14, 2015 at 4:52 PM, Todd Fiala via lldb-dev < &

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

;>>>> Testing: 2 test suites, 1 thread >>>>> 2 out of 2 test suites processed - TestMultithreaded.py >>>>> Test rerun complete >>>>> >>>>> >>>>> = >>>>> Issue Details >>

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

st_runner didn't >>>>>> exit after rerun, which caused buildbot timeout since the process was >>>>>> hanging for over 20 minutes. >>>>>> Could you please take a look if that's related to your change? >>>>>> >>>>>> Pl

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

t;> >>>>>> Yep, I'll have a look! >>>>>> >>>>>> On Tue, Dec 15, 2015 at 12:43 PM, Ying Chen >>>>>> wrote: >>>>>> >>>>>>> Hi Todd, >>>>>>> >>>

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

t;>>> -Todd >>>>>> >>>>>> On Tue, Dec 15, 2015 at 1:38 PM, Todd Fiala >>>>>> wrote: >>>>>> >>>>>>> Yep, I'll have a look! >>>>>>> >>>>>>> On Tue, Dec 15, 2

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

>>>>>>> >>>>>>> -Todd >>>>>>> >>>>>>> On Tue, Dec 15, 2015 at 1:38 PM, Todd Fiala >>>>>>> wrote: >>>>>>> >>>>>>>> Yep, I'll have a look! >>>

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

t;>>>>>>> expected >>>>>>>>> to see that with the basic results output that this builder here is >>>>>>>>> using >>>>>>>>> when I was testing earlier, it's possible somehow that we're h

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

;> [D:\Python_for_lldb\x86\lib\asyncore.py|read|83] >> [D:\Python_for_lldb\x86\lib\asyncore.py|handle_read_event|449] >> [D:\src\llvm\llvm\tools\lldb\packages\Python\lldbsuite\test\dotest_channels.py|handle_read|137] >> [D:\Python_for_lldb\x86\lib\asyncore.py|recv|387]) >>

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

after r255676 goes through this builder. >>>>>>>>>> I hit a hang in the curses output display due to the recursive >>>>>>>>>> taking of a >>>>>>>>>> lock on a lock that was not recursive-enabled. Whil

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

; Hmm, yeah it looks like it did the rerun and then after >>>>>>>>>>> finishing the rerun, it's just hanging. >>>>>>>>>>> >>>>>>>>>>> Let's have a look right after r255676 goe

[lldb-dev] mind if I try allowing reruns on arm/aarch64?

Hi Ying, I am speculating that the rerun logic issue where we saw the hang may be more of a serial test runner issue. Would you mind if I re-enabled the arm/aarch64 inclusion in the rerun logic now that I made a change based on this speculation? It would be a relatively quick way to check if the

Re: [lldb-dev] mind if I try allowing reruns on arm/aarch64?

(And, as an aside, I may just nuke the serial test runner anyway, since we can do it with a multi-worker runner with a single worker just fine, and reduce the code size --- I really don't see a good reason to keep the serial test runner strategy anymore except for a purely theoretical sense). On T

Re: [lldb-dev] mind if I try allowing reruns on arm/aarch64?

Excellent. I'll try this in the afternoon. I need to run out now but I'll check in what we discussed later on when I get back. Thanks! On Thu, Dec 17, 2015 at 10:51 AM, Ying Chen wrote: > Yes, you could use android builder to run that experiment. > Please watch test 7 of this builder >

Re: [lldb-dev] mind if I try allowing reruns on arm/aarch64?

Hi Ying, I just put this change in that reverted the aarch64 and arm removal from test-rerun eligibility: r255935. I'll watch this builder now and see what happens. If it hangs on reruns, I'll revert r255935. Thanks! -Todd

Re: [lldb-dev] building on mac

We definitely should not be requiring ocaml :-) Are you using a configure-based build? If so, can you switch over to using cmake and see if you see that same issue? We pretty much don't maintain the configure build, and it is getting stripped from llvm and clang in the next version of them after

Re: [lldb-dev] building on mac

Ah. Okay, this might be the llvm/clang build script that Xcode uses as an llvm/clang build step. That's going to need to be updated if it is using configure (for the reasons I mentioned above). So it sounds like some part of llvm or clang may be sniffing and finding some part of ocaml, and decid

Re: [lldb-dev] mind if I try allowing reruns on arm/aarch64?

Great, thanks! Yes I was just checking after dinner and saw that it looks to be rerunning just fine. Okay I am likely to just strip out the serial test runner strategy at this point. One less thing to keep running. Thanks! -Todd On Thu, Dec 17, 2015 at 5:41 PM, Ying Chen wrote: > Hi Todd, >

[lldb-dev] r255887 - TestGlobalVariables.py

Hi Ewan! r255887 has broken the tests on OS X for the dwarf version of that test. Can you please either fix it to work on OS X, or revert the change? I'm not interested in disabling that test on OS X since it covers important functionality. Thank you! Now that the test rerun support is in, I'll

Re: [lldb-dev] r255887 - TestGlobalVariables.py

Hi Ewan, Scratch that. I started poking at it with Greg and we're going to try to fix this over here. I will temporarily mark as XFAIL on Darwin. You have no action to take here. Thanks! -Todd On Fri, Dec 18, 2015 at 9:47 AM, Todd Fiala wrote: > Hi Ewan! > > r255887 has broken the tests on

Re: [lldb-dev] building on mac

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

[lldb-dev] turning on tests for OS X llvm.org Green Dragon builder

Hi all, I'm working on turning this on soon here (sometime this afternoon). It is possible that we'll see a bit of noise as I get it going. If we get erroneous output from the builder while I get this settled, I'll be sure to post on that email thread. I'll send out a "it's really on" email onc

Re: [lldb-dev] building on mac

lvm 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&

Re: [lldb-dev] turning on tests for OS X llvm.org Green Dragon builder

Still in progress. I've got the tests running, but I've still got some configuration issues to work out to get them running cleanly. On Fri, Dec 18, 2015 at 12:48 PM, Todd Fiala wrote: > Hi all, > > I'm working on turning this on soon here (sometime this afternoon). It is > possible that we'll

Re: [lldb-dev] turning on tests for OS X llvm.org Green Dragon builder

Hi all, This is complete. We now have OS X running the tests (both gtest and Python tests) at the end of the build phase on the LLVM Green Dragon OS X build. This build: http://lab.llvm.org:8080/green/view/LLDB/job/LLDB/15459/ is the first build where I got everything working. It already sends

Re: [lldb-dev] [Bug 25896] New: Hide stack frames from specific source files

Sounds like you almost want the ability to do a backtrace projection. At one point I wanted this for cross C++/Java frames, but I haven't worked on that problem in some time. Android folks - did we ever add anything to support hiding some of the trampolines or other call sites involved in the C++

Re: [lldb-dev] [Bug 25896] New: Hide stack frames from specific source files

lvm.org/bugs/show_bug.cgi?id=25896#c1 > > On Sun, Dec 20, 2015 at 9:01 PM Todd Fiala via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > >> Sounds like you almost want the ability to do a backtrace projection. At >> one point I wanted this for cross C++/Java frames, but I

[lldb-dev] Holiday time

Hi all, I just wanted to send out a note on behalf of the Apple LLDB team noting that we'll be off for the holidays, coming back the week of Jan 04. Please keep that in mind when looking for responses from us. Happy Holidays! -- -Todd ___ lldb-dev mai

Re: [lldb-dev] lldb 340.4.119 unable to attach (El Capitan)

Hi Andre, On Sat, Dec 26, 2015 at 3:53 AM, Andre Vergison via lldb-dev < lldb-dev@lists.llvm.org> wrote: > Hi, > > I tried Jason Molenda’s test code on El Capitan, lldb-340.4.119 (Jason > Molenda via lldb-dev | 3 Oct 02:59 2015). > > I’m connected to a remote VM using ssh. > > > > tst$ echo 'int

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

Hi William, It looks like just the PRIx64/PRIu64 bits are needed from a visual inspection. The source variables that are printed from already are 64-bit always, aren't they? If they're not but they should be, that seems like the real underlying problem rather than needing to cast. What kind of

Re: [lldb-dev] marking new summary output for expected timeouts

Great. Actually there is a latent bug in there we hit yesterday, when there is a platform set but it doesn't start with "remote-" (we assume the match result has a first matched group and blow up). I'll submit a patch that both fixes that up and strips out the darwin ones. I think the rerun logi

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

Glad to see clang-format getting some improvements. On Thu, Jan 7, 2016 at 10:30 AM, Zachary Turner wrote: > 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 o

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

Jim, I think you and I have talked about this in the past. Care to comment? 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 c

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

Okay, sounds like a reasonable thing to try. We can always review it if it causes any real issues. On Thu, Jan 21, 2016 at 11:34 AM, Zachary Turner wrote: > > > 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 >

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

edge that there may be cases >> where this produces undesirable results. Manual formatting to correct >> these issues is acceptable and should lead to discussions about concrete >> examples where the automated approach is imperfect. >> >> Kate Stone k8st...@apple.com

Re: [lldb-dev] LLDB test questions

Hi Ted! I hope you don't mind - I'm going to CC lldb-dev since there is some useful general info in here for others who are getting started with the test system. (And others can fact-check anything I may gloss over here). On Thu, Jan 21, 2016 at 2:00 PM, Ted Woodward wrote: > Hi Todd, > > > >

[lldb-dev] Ubuntu version-based fail/skip

Hey all, What do you think about having some kind of way of marking the (in this case, specifically) Ubuntu distribution for fail/skip test decorators? I've had a few cases where I've needed to mark tests failing on for Ubuntu where it really was only a particular release of an Ubuntu distribution

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

a delimited range. The code between a comment // clang-format off > > or /* clang-format off */ up to a comment // clang-format on or /* > > clang-format on */ will not be formatted. The comments themselves will > > be formatted (aligned) normally. > > - > > >

[lldb-dev] LLDB OS X buildbot/testbot details

Hi all, The llvm.org Green Dragon (i.e. Jenkins-based) LLDB OS X buildbot/testbot has received some improvements today. The Jenkins build now uses the xUnit plugin to process xUnit-based test suite results, which are displayed more usefully on the "build and test" page here

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

Not sure exactly what it is, but all the tests are failing due to some bad assumptions of unicode vs. str on Python 2 vs. 3 if I had to guess. I am not going to be able to look at details on that, but here's a link to the log on the OS X builder: http://lab.llvm.org:8080/green/job/lldb_build_test

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

Well our whole test suite just stopped running, so yes. On Mon, Jan 25, 2016 at 6:58 PM, Enrico Granata wrote: > > On Jan 25, 2016, at 6:48 PM, Todd Fiala via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > Not sure exactly what it is, but all the tests are fa

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

, Jan 25, 2016 at 8:25 PM, Todd Fiala wrote: > Well our whole test suite just stopped running, so yes. > > On Mon, Jan 25, 2016 at 6:58 PM, Enrico Granata > wrote: > >> >> On Jan 25, 2016, at 6:48 PM, Todd Fiala via lldb-dev < >> lldb-dev@lists.llvm.org>

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

est output, I switched email over to the builder step, which >> doesn't know anything about who made which changes. So it didn't know who >> to put on the blame list for the broken build. Drats, I'll have to figure >> that out. >> >> I'd rea

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

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 emails when out when the build >> went heavy red. (Well they went out internally, but n

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

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 t

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

ll to print. >> >> On Mon, Jan 25, 2016 at 8:54 PM Zachary Turner >> wrote: >> >>> 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 tom

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

gt; >>>>>> Write the unicode >>>>>> <https://docs.python.org/2/library/functions.html#unicode> string *s* to >>>>>> the stream and return the number of characters written. >>>>>> So clearly it does have to be a unicode

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

king at the >>>>>>> documentation for io.write object, i see this: >>>>>>> >>>>>>> write(*s*) >>>>>>> <https://docs.python.org/2/library/io.html#io.TextIOBase.write> >>>>>>> >>>>&

[lldb-dev] Fixing OS X Xcode build

Hi all, At the current moment the OS X Xcode build is broken. I'll be working on fixing it today. As has been discussed in the past, post llvm/clang-3.8 the configure/automake system was getting stripped out of LLVM and clang. The OS X Xcode build has a legacy step in it that still uses the conf

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

icode or byte style strings, for both Python 2 and Python 3. >>>>>>>> Essentially you figure out what you want it to be in, and you write a >>>>>>>> couple helper routes to go in either the "to unicode" or the "to bytes" >>&

Re: [lldb-dev] Patch to fix REPL for ARMv7 & ARMv6 on linux

Hi Pavel, Will is trying to get this working downstream of here IIRC. Greg, can you have a look and see what you think of the patch? (Also see Pavel's comments). Thanks! -Todd On Wed, Jan 27, 2016 at 1:28 AM, Omair Javaid via lldb-dev < lldb-dev@lists.llvm.org> wrote: > Hi Will, > > I dont u

Re: [lldb-dev] Fixing OS X Xcode build

This is all fixed up by r259028. Change comments for r259027 contain some changes to the build requirements for Xcode OS X builds. These boil down to essentially: * OS X 10.9 is the minimum deployment version now, up from 10.8. This is driven by the LLVM/clang cmake-based build. * Cmake is now

Re: [lldb-dev] Fixing OS X Xcode build

AM, Todd Fiala via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > >> This is all fixed up by r259028. Change comments for r259027 contain >> some changes to the build requirements for Xcode OS X builds. >> >> These boil down to essentially: >> * OS X 10.9 i

Re: [lldb-dev] Fixing OS X Xcode build

t of 10.9, it passes. (It finds the > header). This is using Xcode 7.2 and 7.3 beta1 compilers, our latest > publicly available options. > > > On Thu, Jan 28, 2016 at 7:16 AM, Nico Weber wrote: > >> On Thu, Jan 28, 2016 at 9:28 AM, Todd Fiala via lldb-dev < >&g

Re: [lldb-dev] Ubuntu version-based fail/skip

That could be a reasonable way to do it. Now that I think about it, unittest2 already gives us a generic skip where we can put the logic in that we want. Not sure why that didn't occur to me earlier as I've done that very thing in the past. (I think I've conditioned myself to use our custom decor

[lldb-dev] more Green Dragon OS X buildbot/testbot tweaks

Hi all, I don't have this perfectly configured yet. It is happily running builds and running test suites. However, while it reports test failures just fine, it doesn't fail the build on a test failure. I'm tracking down why now. I have just adjusted something so that we get an email on test fa

Re: [lldb-dev] more Green Dragon OS X buildbot/testbot tweaks

I have the OS X testbot fail nag emails going out properly now. Thanks! -Todd On Tue, Feb 2, 2016 at 7:58 AM, Todd Fiala wrote: > Hi all, > > I don't have this perfectly configured yet. It is happily running builds > and running test suites. However, while it reports test failures just > fin

Re: [lldb-dev] Problem running the test suite on Linux.

We've occasionally discussed the concept of unexpected successes being an issue. Last time we landed on this being the best we can do for now as we want the code to be executed, even if it fails occasionally and/or under load. The alternative (aside from fixing it) is to skip it, which then preve

Re: [lldb-dev] Problem running the test suite on Linux.

Hmm I wonder if your lldb-server is able to attach to processes? Siva, we used to have some kind of kernel flag or something that would allow attaching to a process that was launched by something else. I don't recall exactly what it was off the top of my head, but I wonder if Zachary needs that?

Re: [lldb-dev] Problem running the test suite on Linux.

(Security around ptrace). On Wed, Feb 3, 2016 at 3:04 PM, Todd Fiala wrote: > Hmm I wonder if your lldb-server is able to attach to processes? Siva, we > used to have some kind of kernel flag or something that would allow > attaching to a process that was launched by something else. I don't re

Re: [lldb-dev] Problem running the test suite on Linux.

Hey Zachary, For the test listed above, it is failing trying to match output from the inferior process being debugged by lldb-server. First, it is trying to get a hello, world string to be printed. Then, it is expecting the process to exit without failure. If you go in that directory and make/r

Re: [lldb-dev] Problem running the test suite on Linux.

You also need to pass "hello, world" as a launch arg (in quotes). That is what will make it get echoed back. On Wed, Feb 3, 2016 at 8:05 PM, Todd Fiala wrote: > Hey Zachary, > > For the test listed above, it is failing trying to match output from the > inferior process being debugged by lldb-se

Re: [lldb-dev] Problem running the test suite on Linux.

> I don't recall exactly what it was off the top of my head, but I wonder if Zachary needs that? That is the lldb_enable_attach() call that I make in the beginning of the inferior test driver, defined in packages/Python/lldbsuite/test/make/test_common.h. This is already called, so shouldn't be t

[lldb-dev] Green Dragon LLDB Xcode build update: TSAN support

Hi all, I've made a minor change to the Green Dragon LLDB OS X Xcode build located here: http://lab.llvm.org:8080/green/job/LLDB/ 1. Previously, the python test run used the default C/C++ compiler to build test inferiors. Now it uses the just-built clang/clang++ to build test inferiors. At some

Re: [lldb-dev] Green Dragon LLDB Xcode build update: TSAN support

One more update: The Green Dragon OS X LLDB builder now actually runs the gtests instead of just building them. The gtests run as a phase right before the Python test suite. A non-zero value returning from the gtests will cause the OS X LLDB build to fail. Right now, tracking down the cause of t

Re: [lldb-dev] Green Dragon LLDB Xcode build update: TSAN support

Okay, thanks all. FWIW I am running them on the OS X side. I haven't seen any stability problems yet. I'd also expect them to be very stable, much more like a compiler test, since there are far fewer parts in a small-scoped C++ unit test (vs., say, our Python tests which are end-to-end and have

[lldb-dev] Ubuntu buildbot timing after -gmodules

Hi Pavel, FYI - I took a look at the ubuntu 14.04 x86_64 cmake buildbot before and after the -gmodules change landed, and it looks like the total runtime is up about 12%. (Now ~28 minutes, before ~25 minutes). Doesn't seem too bad for the scope of increased coverage. -- -Todd

[lldb-dev] LLVM_PRETTY_FUNCTION in RNBRemote.cpp?

Hi Zachary, I've got the latest LLVM and clang updated, and I'm trying to build debugserver in svn trunk. It's failing on these two calls which looks like you modified last today: DNBLogThreadedIf (LOG_RNB_REMOTE, "%s", LLVM_PRETTY_FUNCTION); /Users/tfiala/src/ lldb-llvm.org/lldb/tools/debu

Re: [lldb-dev] LLVM_PRETTY_FUNCTION in RNBRemote.cpp?

(Did you do a global search and replace, and maybe we just need a new include here?) On Tue, Aug 9, 2016 at 5:55 PM, Todd Fiala wrote: > Hi Zachary, > > I've got the latest LLVM and clang updated, and I'm trying to build > debugserver in svn trunk. It's failing on these two calls which looks li

Re: [lldb-dev] LLVM_PRETTY_FUNCTION in RNBRemote.cpp?

We don't link in LLVM in debugserver, so this part probably just needs to go back to what it was before. On Tue, Aug 9, 2016 at 5:57 PM, Todd Fiala wrote: > (Did you do a global search and replace, and maybe we just need a new > include here?) > > On Tue, Aug 9, 2016 at 5:55 PM, Todd Fiala wrot

Re: [lldb-dev] LLVM_PRETTY_FUNCTION in RNBRemote.cpp?

I got it fixed up. On Tue, Aug 9, 2016 at 5:59 PM, Todd Fiala wrote: > We don't link in LLVM in debugserver, so this part probably just needs to > go back to what it was before. > > On Tue, Aug 9, 2016 at 5:57 PM, Todd Fiala wrote: > >> (Did you do a global search and replace, and maybe we just

Re: [lldb-dev] LLVM_PRETTY_FUNCTION in RNBRemote.cpp?

Yep totally fine, I figured it out in real time ;-) Thanks! -Todd On Tue, Aug 9, 2016 at 6:05 PM, Zachary Turner wrote: > Sorry about that, yes I did a global search and replace since there were a > few hundred instances > > On Tue, Aug 9, 2016 at 6:01 PM Todd Fiala wrote: > >> I got it fixed

Re: [lldb-dev] Linux ELF header e_ident[EI_OSABI] value

FWIW, I've taken a few whacks at getting Linux detected better over the last few years, and haven't yet found a reliable way to detect it from quite a few samples of cores from a number of different systems. We can spend more time looking into it, but that stone has been turned over several times.

Re: [lldb-dev] LLDB Evolution

On Mon, Aug 8, 2016 at 2:57 PM, Zachary Turner via lldb-dev < lldb-dev@lists.llvm.org> wrote: > > > On Mon, Aug 8, 2016 at 2:40 PM Kate Stone via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > >> LLDB has come a long way since the project was first announced. As a >> robust debugger for C-family

[lldb-dev] macOS Xcode test bot back in shape

Hello, all! I just wanted to update everyone on the state of the Green Dragon Xcode build of LLDB. That builder has had a rocky few months. The hardware, OS and Xcode version all were updated simultaneously, and in the process, several aspects of the test bot's logic were broken. We all recogni

<    1   2   3   4   >