Re: [lldb-dev] [cfe-dev] 7.0.1-final has been tagged
Windows is ready: $ sha1sum *7.0.1-w*.exe 87feb5fbb0fa0c473d3d22e9dbc1935464b63415 LLVM-7.0.1-win32.exe f0944995f26fa98713ff0cf12b512512c7931f83 LLVM-7.0.1-win64.exe It was built with the attached batch file. Thanks, Hans On Thu, Dec 20, 2018 at 1:24 AM Tom Stellard via cfe-dev wrote: > > Hi, > > I've tagged the 7.0.1 final release. Testers may begin uploading binaries. > > -Tom > ___ > cfe-dev mailing list > cfe-...@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev build_llvm_701-final._bat_ Description: Binary data ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [Release-testers] 7.0.1-final has been tagged
Le 20/12/2018 à 01:23, Tom Stellard via Release-testers a écrit : Hi, I've tagged the 7.0.1 final release. Testers may begin uploading binaries. Uploaded in Debian with a stage2 build (piouf, wasn't trivial). All green on the official arch: https://buildd.debian.org/status/package.php?p=llvm-toolchain-7 Should be in Ubuntu Disco very soon. I took the ABI fix because it was breaking a bunch of things (ex: the rust ecosystem) Cheers, Sylvestre ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [Bug 40112] New: LLDB crashes (SEGV) by pressing ↑ in the first entry in print
https://bugs.llvm.org/show_bug.cgi?id=40112 Bug ID: 40112 Summary: LLDB crashes (SEGV) by pressing ↑ in the first entry in print Product: lldb Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: All Bugs Assignee: lldb-dev@lists.llvm.org Reporter: e.kawaschima+l...@gmail.com CC: llvm-b...@lists.llvm.org Steps to Reproduce % lldb-7 -v lldb version 7.0.1 % lldb-7 a.out # do not have to exist (lldb) target create "a.out" Current executable set to 'a.out' (x86_64). (lldb) print Enter expressions, then terminate with an empty line to evaluate: 1: Pressing an arrow key (←, ↓ and →) is OK, but ↑ crashes lldb (lldb) print Enter expressions, then terminate with an empty line to evaluate: /usr/lib/x86_64-linux-gnu/libLLVM-7.so.1(_ZN4llvm3sys15PrintStackTraceERNS_11raw_ostreamE+0x1f)[0x7f21ebefc12f] /usr/lib/x86_64-linux-gnu/libLLVM-7.so.1(_ZN4llvm3sys17RunSignalHandlersEv+0x22)[0x7f21ebefa632] /usr/lib/x86_64-linux-gnu/libLLVM-7.so.1(+0x9c6442)[0x7f21ebefc442] /lib/x86_64-linux-gnu/libpthread.so.0(+0x110c0)[0x7f21eb32a0c0] /usr/lib/x86_64-linux-gnu/liblldb-7.so.1(+0x5474a7)[0x7f21e995d4a7] /usr/lib/x86_64-linux-gnu/liblldb-7.so.1(+0x547606)[0x7f21e995d606] /usr/lib/x86_64-linux-gnu/liblldb-7.so.1(+0x547d90)[0x7f21e995dd90] /usr/lib/x86_64-linux-gnu/liblldb-7.so.1(+0x54b709)[0x7f21e9961709] /usr/lib/x86_64-linux-gnu/libedit.so.2(el_wgets+0x1a7)[0x7f21e83a96b7] /usr/lib/x86_64-linux-gnu/libedit.so.2(el_gets+0x13)[0x7f21e83a4da3] /usr/lib/x86_64-linux-gnu/liblldb-7.so.1(+0x54b2ad)[0x7f21e99612ad] /usr/lib/x86_64-linux-gnu/liblldb-7.so.1(+0x4b9114)[0x7f21e98cf114] /usr/lib/x86_64-linux-gnu/liblldb-7.so.1(+0x49cff6)[0x7f21e98b2ff6] /usr/lib/x86_64-linux-gnu/liblldb-7.so.1(+0x569941)[0x7f21e997f941] /usr/lib/x86_64-linux-gnu/liblldb-7.so.1(_ZN4lldb10SBDebugger21RunCommandInterpreterEbb+0x34)[0x7f21e9768224] lldb-7[0x40704c] lldb-7[0x407667] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1)[0x7f21e87fa2e1] lldb-7[0x403c9a] Stack dump: 0. Program arguments: lldb-7 a.out zsh: segmentation fault lldb-7 a.out If ↑ is pressed in the second or later entry, the problem does not happen. clang and lldb are installed by apt (apt.llvm.org). lldb-6.0 and lldb-8 have the same problem (they cannot coexist due to conflict of dependencies). -- You are receiving this mail because: You are the assignee for the bug.___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] OperatingSystem plugin
Thank you Jim, It's much clearer for me now. As you might remember, we discussed an opportunity of adding new OS objects to LLDB, e.g. mutexes. The conclusion of our discussion was that if we want to do this, we should add such objects to Platform plugin, but is there a difference between threads and mutexes for example, both are OS specific data structures. Wouldn't it be better to delegate mutexes to OperatingSystem plugin? It could deal with them the same way as it deals with threads. On Thu, Dec 20, 2018 at 1:51 AM Jim Ingham wrote: > You would use an operating system plugin in cases where the underlying > process interface doesn't tell the complete story for the OS threads. For > instance, a lot of kernel and bare board OS'es have a gdb-remote stub that > just describes the state of the threads currently running on the cores of > the machine. Any swapped out threads are unknown to it. So the Operating > system plugin reconstructs the swapped out threads by looking at OS > specific data structures. > > We didn't think that lldb should own the support for every variant of > every OS which might want to reconstruct threads from some data structures > in the OS. After all, this isn't dealing with fairly stable API's - like > the Platforms do. The OS plugins deal with internal data structures, which > tend to change fairly frequently. So trying to package them with lldb > doesn't seem supportable. > > By making the OS plugin something that comes from outside lldb, we allow > the kernel developers to provide this knowledge on demand. That is very > convenient. For instance, on macOS, the dSYM bundle for the mach kernel > contains the Operating System plugin for that kernel. When lldb is used > for kernel debugging, it finds the dSYM associated with the kernel it is > targeting and loads in the python support from the dSYM. That way it is > ensured to get the correct plugin for that kernel. It also means that lldb > can support kernel versions that didn't even exist when it was made. > > As for why this is done with Python and not the C++ SB API's, there's > nothing to stop it from also being in C++, you can actually write loadable > C++ plugins with the SB API's for data formatters, for instance. But > there's generally no significant performance advantage to doing that, and > its less convenient, so there just hasn't been much demand for it. > > Jim > > > > On Dec 19, 2018, at 12:44 PM, Alexander Polyakov via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > > > Hi lldb-dev, > > > > Could someone explain me why do we use python (OperatingSystemPython) to > describe OS objects like threads? What are the advantages of such an > approach in comparison to C++ used in Platform plugin for example? IMO, the > OperatingSystem plugin could be more like the Platform one, it could have a > separate directory for each OS with its own implementation inside. > > > > -- > > Alexander > > ___ > > lldb-dev mailing list > > lldb-dev@lists.llvm.org > > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > > -- Alexander ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [Bug 40119] New: stop-hook test fails on Windows
https://bugs.llvm.org/show_bug.cgi?id=40119 Bug ID: 40119 Summary: stop-hook test fails on Windows Product: lldb Version: 7.0 Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: All Bugs Assignee: lldb-dev@lists.llvm.org Reporter: sti...@microsoft.com CC: llvm-b...@lists.llvm.org The test fails because "expr ptr" does not evaluate correctly. More specifically, ptr is unresolved. The error message produced is: error: Aborting reading of commands after command #0: 'expr ptr' failed with error: use of undeclared identifier 'ptr' which contains "expr ptr" which is what the test is looking for on success. So the test is counted as passed even though the commands failed. Right now the test is disabled on Windows in order to avoid the unexpected (and inaccurate) pass. -- You are receiving this mail because: You are the assignee for the bug.___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [Bug 35193] MiniDumpTestCase.test_stack_info_in_minidump failing
https://bugs.llvm.org/show_bug.cgi?id=35193 Stella Stamenova changed: What|Removed |Added Status|NEW |RESOLVED CC||sti...@microsoft.com Resolution|--- |FIXED --- Comment #1 from Stella Stamenova --- The test marked as failing because of this bug is now passing. -- You are receiving this mail because: You are the assignee for the bug.___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [Release-testers] 7.0.1-final has been tagged
On 20 Dec 2018, at 01:23, Tom Stellard via Release-testers wrote: > > I've tagged the 7.0.1 final release. Testers may begin uploading binaries. Main test results on amd64-freebsd11 had 1 more Expected Pass compared to 7.0.1 rc3, and no more Passes With Retry: Expected Passes: 52445(7.0.1 rc3: 52444) Passes With Retry : n/a(7.0.1 rc3: 1) Expected Failures : 232(7.0.1 rc3: 232) Unsupported Tests : 3687(7.0.1 rc3: 3687) Unexpected Passes : 1(7.0.1 rc3: 1) Unexpected Failures: 491(7.0.1 rc3: 491) Test-suite results on amd64-freebsd11 did not change: Expected Passes: 903(7.0.1 rc3: 903) Unexpected Failures: 3(7.0.1 rc3: 3) Test results on i386-freebsd11 had 1 more Expected Pass compared to 7.0.1 rc3, and 3 less Unexpected Failures: Expected Passes: 50254(7.0.1 rc3: 50253) Passes With Retry : 2(7.0.1 rc3: n/a) Expected Failures : 226(7.0.1 rc3: 226) Unsupported Tests : 2502(7.0.1 rc3: 2502) Unexpected Failures: 272(7.0.1 rc3: 275) The test-suite still doesn't build on i386-freebsd11, but that is a known issue. I have uploaded: SHA256 (clang+llvm-7.0.1-amd64-unknown-freebsd11.tar.xz) = 617be68f00c7a80fb77ee5a124b800aadab64dff052acf51428da3af3f58e407 SHA256 (clang+llvm-7.0.1-i386-unknown-freebsd11.tar.xz) = 1f696728db8cd4850e0d97ea6bb9d8f3a715fa05fec04ff5618a3f2da6ae7d36 -Dimitry signature.asc Description: Message signed with OpenPGP ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] Holiday update on LLVM's Relicensing effort
I wanted to send out a general but brief update on relicensing as holiday season (at least in my part of the world) approaches. (If you don't know what the relicensing effort is, or want background, see our website: http://llvm.org/foundation/relicensing/) First off, a huge thank you to everyone who has gone through the relicensing form and individual agreement. We are making fantastic progress, with well over 500 individual agreements completed. This covers over 73% of committers and over 80% of commits in the last 6 months, and over 63% of committers and over 74% of commits in the last 2 years. But we need to get these higher, so if you haven't already *Please send me the best holiday gift you can by filling out the agreement form below:* https://goo.gl/forms/X4HiyYRcRHOnTSvC3 =D We plan to install the new developer policy on *January 14th*, at which point commit access will be disabled for anyone not covered by an agreement. We have emailed every committer in the last 6 months who hasn't gone through the form twice about this already, and will be sending weekly emails from now until the switch happens. We have emailed every committer in the last 2 years who hasn't gone through the form once, and will send at least two more direct emails before the 14th. Also, please, if at all possible, *sign the agreement as part of this*. While you may in fact be 100% certain that all of your contributions are owned by your employer, in many cases the LLVM Foundation will end up having to verify this which is a very expensive operation and may significantly delay us confirming that you are covered so we can restore commit access. And last but not least, if relevant, please forward the information on our relicensing page to your current employer as we will need to get them to sign the corporate agreement by January as well: http://llvm.org/foundation/relicensing/#corporate_agreement (Note that companies that have already signed or we are in active discussions with are listed.) Thank you again to everyone who has helped with this, is working with their employers to get these things taken care of, and who has gone through the individual agreement process. -Chandler ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
