Re: [lldb-dev] [3.7 Release] RC4 has been tagged
No build or test failures. Uploaded: SHA256 (clang+llvm-3.7.0-rc4-i386-unknown-freebsd10.tar.xz) = 4d1cc01c701d453b5ddb64801b9014d2f902b08b6834d97878bf8feada56a8c5 SHA256 (clang+llvm-3.7.0-rc4-amd64-unknown-freebsd10.tar.xz) = 2a9feef3004e5787019ee41afc8efa7fbe84ff9621f26a083218d383f6a50802 -Dimitry > On 27 Aug 2015, at 01:37, Hans Wennborg wrote: > > Dear testers, > > 3.7.0-rc4 has just been tagged. It is identical to rc3, plus: > > - r245902: Revert r245355: change of clang-tools-extra symlink in the > release script > - r245947: Merge of r245927: Fix LLDB build on MIPS > - r245948: Deprecate the DataLayout on the TargetMachine, and backport > the 3.8 API > - Changes to the ReleaseNotes. > > Those changes should all be safe, and I expect this to be an extremely > short cycle. > > Please build and test. If no new issues arise, I plan to tag this as > 'final' tomorrow or Friday so we can ship the release next week. > > Thanks, > Hans signature.asc Description: Message signed with OpenPGP using GPGMail ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [3.7 Release] 3.7.0-final has been tagged
On Friday, August 28, 2015 09:46 AM, Hans Wennborg wrote: I have promoted RC4 to final; 3.7.0 has reached its final state. Thanks for all your hard work so far. Please build and upload binaries with "-final", and let's ship this next week! Uploaded: clang+llvm-3.7.0-x86_64-linux-gnu-ubuntu-14.04.tar.xz I'll try to build for 15.04 on the weekend. Ben ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] How does attach work on non-Windows?
On Thu, Aug 27, 2015 at 3:01 PM, via lldb-dev wrote: > On Thu, Aug 27, 2015 at 05:05:23PM +, Zachary Turner via lldb-dev > wrote: > > Well I'm xfailing it for now, but this other method seems kind of hackish > > to me because it means the inferior and the debugger have to coordinate > > with each other, which means the test has to know about the executable > and > > the executable has to know about the test. I'd rather remove one > direction > > of this coupling. > > > > Eventually my plan is to introduce a test_util.a which all of the test > > executables link against. We can provide a platform-independent > > wait_for_debugger_to_attach() method here that just does the right thing > on > > all platforms. This way the tests can be written without having to do > this > > funny business :) > > What about fixing lldb to prefer to debug via launch instead of attach > depending on the platform??? > > The largest section of code getting debugged in production on the Apple side is in attached scenarios (often by requirement), so reducing attach test coverage isn't something I think we'd want to do at least on Apple platforms. > I don't see how you could write a wait_for_debugger_to_attach() that would > work reliably. > What about building a helper method that we mandate main() call for attach-enabled tests, that loops in a known function and has an exit scenario that the debugger can control. Then, on attach, we set a breakpoint on something (which can be shared out several different ways, either by variable address lookup if we have symbols, or could be added to the environment by the helper method, etc.) Then the protocol becomes: The lldb test would do something like this: 1. attach to process 2. collect breakpoint information, which may require the inferior to be running more if we attach before main has even fired. No worries there, though. 3. set breakpoint at collected spot. 4. when synchronization breakpoint is hit, we now know we're in a good startup spot. And if a test might be used both in an attach-synchronous mode and not attached at all, that helper method could be controlled (again perhaps by environment variable or something else) to skip doing the waiting step if it doesn't expect to get attached to by the debugger. All that could be put behind helpers on the lldb test side to more or less hide all traces of it. Test inferiors would need a call to a helper method that could be fully defined in a header to simplify getting that code brought in. That would eliminate races in attach tests by creating an agreed synchronization point. -Todd ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > -- -Todd ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] top-of-tree build failure when using configure on Linux?
Our Ubuntu 14.10 buildbot at http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.10 is failing, and I've been tasked to fix it because I'm the LLDB guy. It fails with things like: /var/lib/buildbot/slaves/hexagon-build-03/lldb-x86_64-ubuntu-14.10/llvm.obj/ Release+Asserts/lib/libclangCodeGen.a(BackendUtil.o): In function `addObjCARCOptPass(llvm::PassManagerBuilder const&, llvm::legacy::PassManagerBase&)': BackendUtil.cpp:(.text._ZL17addObjCARCOptPassRKN4llvm18PassManagerBuilderERN S_6legacy15PassManagerBaseE+0x21): undefined reference to `llvm::createObjCARCOptPass()' I get the same error when I manually build using the same steps as the bot, but when I use cmake it works. Has anyone seen this behavior using configure? -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [3.7 Release] 3.7.0-final has been tagged
On Thu, Aug 27, 2015 at 6:46 PM, Hans Wennborg wrote: > I have promoted RC4 to final; 3.7.0 has reached its final state. > > Thanks for all your hard work so far. Please build and upload binaries > with "-final", and let's ship this next week! Windows binaries uploaded. sha1sums: 44400734e1cbe1cfef3fc3ea03d8cba31ee50e66 LLVM-3.7.0-win32.exe 70aec264a5bfce1b5e596d93762e0481cb896a6b LLVM-3.7.0-win64.exe I used the attached batch file for building. Cheers, Hans build_llvm_370._bat_ Description: Binary data ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
lldb-dev@lists.llvm.org
We've been seeing races during shutdown of inferiors for months, and I finally tracked it down to the fact that Process holds a Target&. When an inferior is exiting on Windows, we will get a notification of this and we try to do various cleanup related with the target. But there are times where the Target gets deleted even when the Process is still around, due to some interactions between our debug loop and the timing of when certain debug events that get sent by the operating system. As a result, the race leads to us getting one of the notifications from the OS and us trying to access the target, which is stored by reference leading to a crash. It seems like a purely mechanical change to make Process hold a TargetSP instead of a Target&. I've already started down this patch locally, but I want to make sure there are no objections or concerns before I continue down this path, since it's kind of mundane work. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [3.7 Release] 3.7.0-final has been tagged
On 28 Aug 2015, at 20:12, Hans Wennborg wrote: > > On Thu, Aug 27, 2015 at 6:46 PM, Hans Wennborg wrote: >> I have promoted RC4 to final; 3.7.0 has reached its final state. >> >> Thanks for all your hard work so far. Please build and upload binaries >> with "-final", and let's ship this next week! > > Windows binaries uploaded. sha1sums: > > 44400734e1cbe1cfef3fc3ea03d8cba31ee50e66 LLVM-3.7.0-win32.exe > 70aec264a5bfce1b5e596d93762e0481cb896a6b LLVM-3.7.0-win64.exe No building or testing problems encountered on FreeBSD 10. The only strange thing is that relative to -rc4, I now got a lot more "differs between phase 2 and phase 3" messages. But this is probably due to turning off assertions. Uploaded: SHA256 (clang+llvm-3.7.0-i386-unknown-freebsd10.tar.xz) = 07cf94ddff7c4dff112eeadb95aab1b905cd40a3462c6afd808988164146d880 SHA256 (clang+llvm-3.7.0-amd64-unknown-freebsd10.tar.xz) = fe8c7136d254a4a25967c4d8d97f48a985cb594fe5c864dc234526a6bacfebe2 -Dimitry signature.asc Description: Message signed with OpenPGP using GPGMail ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
lldb-dev@lists.llvm.org
I think it should be a weak_ptr if anything. Target already holds a shared_ptr of the process, and you will get pointer loops otherwise. Couldn't you make sure the debug thread exits (and processes all events) before the Target gets deleted (e.g. shut it down in Process::Finalize() or somewhere...)? If there is currently an invariant that Process should never outlive its Target (which would seem to be implied by the fact it holds a Target&), I would prefer if it can be preserved. pl On 28 August 2015 at 19:34, Zachary Turner via lldb-dev wrote: > We've been seeing races during shutdown of inferiors for months, and I > finally tracked it down to the fact that Process holds a Target&. When an > inferior is exiting on Windows, we will get a notification of this and we > try to do various cleanup related with the target. But there are times > where the Target gets deleted even when the Process is still around, due to > some interactions between our debug loop and the timing of when certain > debug events that get sent by the operating system. > > As a result, the race leads to us getting one of the notifications from the > OS and us trying to access the target, which is stored by reference leading > to a crash. > > It seems like a purely mechanical change to make Process hold a TargetSP > instead of a Target&. I've already started down this patch locally, but I > want to make sure there are no objections or concerns before I continue down > this path, since it's kind of mundane work. > > ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
lldb-dev@lists.llvm.org
We already do this in DoDestroy(), but it looks like for whatever reason DoDestroy is not getting called on us even though the Target is being destroyed. Or maybe it is and our DoDestroy is getting into some edge condition that doesn't cleanup correctly. But it's hard to debug because it only happens from the test suite, and only when the system is under heavy load (i.e. you run the entire test suite, and not just one test). In the future I had planned to make an option for dotest that would allow lldb to write full logs of every run during the test suite, so we could see the sequence of events that are happening, but it's a bigger task. A weak_ptr would work just as well and avoid the problem you describe, so I'll wait and see if anyone has an issue with that. On Fri, Aug 28, 2015 at 2:01 PM Pavel Labath wrote: > I think it should be a weak_ptr if anything. Target already holds a > shared_ptr of the process, and you will get pointer loops otherwise. > > Couldn't you make sure the debug thread exits (and processes all > events) before the Target gets deleted (e.g. shut it down in > Process::Finalize() or somewhere...)? If there is currently an > invariant that Process should never outlive its Target (which would > seem to be implied by the fact it holds a Target&), I would prefer if > it can be preserved. > > pl > > On 28 August 2015 at 19:34, Zachary Turner via lldb-dev > wrote: > > We've been seeing races during shutdown of inferiors for months, and I > > finally tracked it down to the fact that Process holds a Target&. When > an > > inferior is exiting on Windows, we will get a notification of this and we > > try to do various cleanup related with the target. But there are times > > where the Target gets deleted even when the Process is still around, due > to > > some interactions between our debug loop and the timing of when certain > > debug events that get sent by the operating system. > > > > As a result, the race leads to us getting one of the notifications from > the > > OS and us trying to access the target, which is stored by reference > leading > > to a crash. > > > > It seems like a purely mechanical change to make Process hold a TargetSP > > instead of a Target&. I've already started down this patch locally, but > I > > want to make sure there are no objections or concerns before I continue > down > > this path, since it's kind of mundane work. > > > > ___ > > lldb-dev mailing list > > lldb-dev@lists.llvm.org > > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > > > ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
