Re: [lldb-dev] [cfe-dev] RFC: Update LLVM_VERSION_SUFFIX CMake variable for release candidates
On 7/1/21 8:26 AM, Ben Boeckel wrote: On Tue, Jun 29, 2021 at 10:39:01 -0700, Tom Stellard via cfe-dev wrote: I would like to propose that we start using the LLVM_VERSION_SUFFIX CMake variable for release candidates. For example: after the release/13.x branch is created, instead of changing LLVM_VERSION_SUFFIX from "git" to "", we would change it to "rc1", then after the 13.0.0-rc1 release is tagged, we would update the variable to "rc2", etc. Then right before the final release has been tagged, we would set it to "" Just a note that this can be confusing because there would now have builds reporting as `13.0.0-rc1` without any corresponding tag in the repository. I think that instead of doing that, changing it to be `13.90.0` or something to indicate "after 13, but not yet 14" while avoiding any (plausible) `13.x` release number might be a better strategy. This is the situation now, because the version of llvm in the release/13.x branch is 13.0.0 before there is a 13.0.0 tag. We use the minor release number for ABI breaking releases sometimes, so I don't think we can use it to indicate 'almost' the next version. -Tom I learned this trick from KDE by the way if any prior art is wanted. (Just an outside observer, FWIW.) --Ben ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] RFC: Update LLVM_VERSION_SUFFIX CMake variable for release candidates
On 7/1/21 9:18 AM, Harald van Dijk wrote: On 29/06/2021 18:39, Tom Stellard via llvm-dev wrote: Hi, I would like to propose that we start using the LLVM_VERSION_SUFFIX CMake variable for release candidates. For example: after the release/13.x branch is created, instead of changing LLVM_VERSION_SUFFIX from "git" to "", we would change it to "rc1", then after the 13.0.0-rc1 release is tagged, we would update the variable to "rc2", etc. Then right before the final release has been tagged, we would set it to "" The library SONAME's currently include LLVM_VERSION_SUFFIX, so this change will cause each release candidate to have a different SONAME for libraries. This is correct for X.Y.0 releases, since it's possible for a library's ABI to change between release candidates. However, for X.Y.1 releases, we do not want to modify the SONAME's at all, so the build system will need to be updated to accommodate this change. This would mean that the so-called release candidate is no longer a candidate for release. Even if no problems are identified in 13.0.0-rc1, it is still guaranteed that 13.0.0 will be different from 13.0.0-rc1. In particular, this means if a distro were to do a rebuild against 13.0.0-rc1, and then no further changes are needed and 13.0.0 can be released, the distro will still need to rebuild everything that was already built against 13.0.0-rc1 against 13.0.0. The fact that the SONAME changes also means it's possible that other projects adjust to wrongly account for the SONAME change in a way that happens to work for the release candidates, but not for the actual release, so testing with the release candidate suggests that everything is fine when in fact it isn't. As you point out, the disadvantage of my proposal is that the SONAME will change between the last release candidate and the final release, even though the ABI has not. I agree this is not ideal. However, in my opinion, this is better than changing the ABI without changing the SONAME, which is what can happen in some release candidates with the current process. Changing the ABI without changing the SONAME is incorrect, and I would really like to find a way to fix this. I was working on changing my own testing procedures for my own system to handle the current release candidate structure, where I am in much the same boat as distros, except on a smaller scale. Currently, llvm-12.0.0rc5.src.tar.xz and llvm-12.0.0.src.tar.xz are different files, but the only difference is that the former extracts to an llvm-12.0.0rc5.src directory whereas the latter extracts to a llvm-12.0.0.src directory, the archives are otherwise 100% identical, down to the mtime of each individual file. I wanted to use this to create a build of LLVM+clang 12.0.1-rc3 that, if 12.0.1-rc3 turns out to be the final release candidate, will be bitwise identical to the same build of LLVM+clang 12.0.1 and there will be no reason to re-test anything that worked with 12.0.1-rc3 against 12.0.1, allowing me to avoid a further mass rebuild once 12.0.1 is released. Under your proposed scheme, this may continue to work for x.0.1 releases, I am not sure whether it would continue to work for x.1.0 releases, but it would definitely cease to be an option for x.0.0 releases. That seems a shame, because it means the release candidates will be less tested than they would otherwise be. The fact that we have to produce new tarballs for the final release even when nothing has changed since the last release candidate is an inefficiency in our process and is something I would also like to fix, but I'm not sure exactly how. I do acknowledge that this proposal means that we are locking ourselves in to always doing a separate final release build. Maybe there is some middle ground where we can fix our SONAME usage without forcing unnecessary builds. -Tom Cheers, Harald van Dijk ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [Bug 50958] New: Crash when kernel debugging OS X after hitting breakpoint several times
https://bugs.llvm.org/show_bug.cgi?id=50958 Bug ID: 50958 Summary: Crash when kernel debugging OS X after hitting breakpoint several times Product: lldb Version: 12.0 Hardware: PC OS: MacOS X Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-dev@lists.llvm.org Reporter: tobaljack...@gmail.com CC: jdevliegh...@apple.com, llvm-b...@lists.llvm.org Hello, I'm currently using lldb-1205.0.27.3 on host OS X 11.3.1 to kernel-debug an OS X guest (version 11.4) running under VMWare Fusion 12.1.2, and am reliably crashing any time I hit a breakpoints more than ~15 times. This issue was similarly reproducible on an identical guest version (11.3.1) as the host, but I upgraded the guest to see if that had any effect on the crashing (it didn't). I've reproduced the crash using both the gdb-stub facility provided by vmware (gdb-remote 8864), as well as performing regular network-based debugging (lldb -o "kdp-remote "). Each time I try to hit a breakpoint more than ~15 times and a crash occurs, the backtrace looks similar to the one reproduced here: (lldb) c Process 1 resuming Process 1 stopped * thread #22, name = '0xff86986ec640', queue = 'cpu-1', stop reason = breakpoint 1.1 frame #0: 0xff8020c814f4 kernel`mach_msg_trap(args=0xffa06e3fbf00) at mach_msg.c:725:16 [opt] Target 0: (kernel) stopped. (lldb) c Process 1 resuming (lldb) PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace. 0 lldb 0x00010a227de5 llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 37 1 lldb 0x00010a2274e5 llvm::sys::RunSignalHandlers() + 85 2 lldb 0x00010a228646 SignalHandler(int) + 262 3 libsystem_platform.dylib 0x7fff20451d7d _sigtramp + 29 4 libc++.1.dylib 0x7fff203a3535 std::__1::recursive_mutex::unlock() + 9 5 LLDB 0x00010a718745 lldb_private::ThreadPlan::PlanExplainsStop(lldb_private::Event*) + 37 6 LLDB 0x00010a70e6bf lldb_private::Thread::ShouldStop(lldb_private::Event*) + 1151 7 LLDB 0x00010a716786 lldb_private::ThreadList::ShouldStop(lldb_private::Event*) + 822 8 LLDB 0x00010a6c36d4 lldb_private::Process::ShouldBroadcastEvent(lldb_private::Event*) + 436 9 LLDB 0x00010a6bfd49 lldb_private::Process::HandlePrivateEvent(std::__1::shared_ptr&) + 265 10 LLDB 0x00010a6c4518 lldb_private::Process::RunPrivateStateThread(bool) + 1496 11 LLDB 0x00010a6c3b05 lldb_private::Process::PrivateStateThread(void*) + 21 12 LLDB 0x00010a6048a7 lldb_private::HostNativeThreadBase::ThreadCreateTrampoline(void*) + 103 13 libsystem_pthread.dylib 0x7fff2040c954 _pthread_start + 224 14 libsystem_pthread.dylib 0x7fff204084a7 thread_start + 15 [1]84306 segmentation fault lldb Here I set the breakpoint on mach_msg_trap and just hit 'c'ontinue 15 times until a crash. Some additional information from connecting to the guest (after gdb-remote or lldb -o "kdp-remote "): WARNING: Python 2.7 is not recommended. Future versions of lldb will not support Python 2.7. (lldb) gdb-remote 8864 Kernel UUID: 52A1E876-863E-38E3-AC80-09BBAB13B752 Load Address: 0xff8020c1 Loading kernel debugging from /Library/Developer/KDKs/KDK_11.4_20F71.kdk/System/Library/Kernels/kernel.dSYM/Contents/Resources/Python/kernel.py LLDB version lldb-1205.0.27.3 Apple Swift version 5.4 (swiftlang-1205.0.26.9 clang-1205.0.19.55) settings set target.process.python-os-plugin-path "/Library/Developer/KDKs/KDK_11.4_20F71.kdk/System/Library/Kernels/kernel.dSYM/Contents/Resources/Python/lldbmacros/core/operating_system.py" Target arch: x86_64 Connected to live debugserver or arm core. Will associate on-core threads to registers reported by server. settings set target.trap-handler-names hndl_allintrs hndl_alltraps trap_from_kernel hndl_double_fault hndl_machine_check _fleh_prefabt _ExceptionVectorsBase _ExceptionVectorsTable _fleh_undef _fleh_dataabt _fleh_irq _fleh_decirq _fleh_fiq_generic _fleh_dec command script import "/Library/Developer/KDKs/KDK_11.4_20F71.kdk/System/Library/Kernels/kernel.dSYM/Contents/Resources/Python/lldbmacros/xnu.py" xnu debug macros loaded successfully. Run showlldbtypesummaries to enable type summaries. settings set target.process.optimization-warnings false Kernel slid 0x20a1 in memory. Loaded kernel file /Library/Developer/KDKs/KDK_11.4_20F71.kdk/System/Library/Kernels/kernel Loading kernel debugging from /Library/Developer/KDKs/KDK_11.4_20F71.kdk/System/Library/K
