[Bug 250702] c++filt crashes on a symbol representing a C++ lambda function
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=250702 Dimitry Andric changed: What|Removed |Added Resolution|--- |FIXED Status|In Progress |Closed -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
[Bug 250702] c++filt crashes on a symbol representing a C++ lambda function
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=250702 --- Comment #28 from commit-h...@freebsd.org --- A commit references this bug: Author: dim Date: Wed Dec 2 21:39:58 UTC 2020 New revision: 368285 URL: https://svnweb.freebsd.org/changeset/base/368285 Log: MFC r367304: Add WITH_LLVM_CXXFILT option to install llvm-cxxfilt as c++filt Since elftoolchain's cxxfilt is rather far behind on features, and we ran into several bugs, add an option to use llvm-cxxfilt as an drop-in replacement. It supports the same options as elftoolchain cxxfilt, though it doesn't have support for old ARM (C++ Annotated Reference Manual, not the CPU) and GNU v2 manglings. But these are irrelevant in 2020. Note: as we already compile the required libraries as part of libllvm, this will not add any significant build time either. PR: 250702 Reviewed by: emaste, yuri Differential Revision: https://reviews.freebsd.org/D27071 MFC r367712: Ensure make delete-old does not unlink the llvm-cxxfilt and its manpage, after r367304 and r367324, when WITH_LLVM_CXXFILT is enabled. Noticed by: "Herbert J. Skuhra" Changes: _U stable/11/ stable/11/share/man/man5/src.conf.5 stable/11/share/mk/src.opts.mk stable/11/tools/build/mk/OptionalObsoleteFiles.inc stable/11/tools/build/options/WITHOUT_LLVM_CXXFILT stable/11/tools/build/options/WITH_LLVM_CXXFILT stable/11/usr.bin/Makefile stable/11/usr.bin/clang/Makefile stable/11/usr.bin/clang/llvm-cxxfilt/Makefile _U stable/12/ stable/12/share/man/man5/src.conf.5 stable/12/share/mk/src.opts.mk stable/12/tools/build/mk/OptionalObsoleteFiles.inc stable/12/tools/build/options/WITHOUT_LLVM_CXXFILT stable/12/tools/build/options/WITH_LLVM_CXXFILT stable/12/usr.bin/Makefile stable/12/usr.bin/clang/Makefile stable/12/usr.bin/clang/llvm-cxxfilt/Makefile -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: Removing obsolete GDB 6.1.1 for FreeBSD 13
On Wed, 2 Dec 2020 at 12:52, Warner Losh wrote: > > even if lldb isn't a complete drop in replacement (I've not used it at all, > so I can't say one way or another). Quick comment on this point - the FreeBSD Foundation has been sponsoring Moritz Systems to improve LLDB on FreeBSD, and they've done great work getting it into shape. Their work is in LLVM upstream now, and they're iterating on fixing issues found by LLDB's test suite. LLDB 12 should provide a capable userland debugging experience in FreeBSD 13, although I suspect many users will still install the gdb port or package for the familiar command line interface. There's no FreeBSD kernel support in LLDB yet, but it's being investigated. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: Removing obsolete GDB 6.1.1 for FreeBSD 13
On Wed, Dec 2, 2020 at 10:44 AM Ed Maste wrote: > We currently have an obsolete version of GDB 6.1 installed as > /usr/libexec/gdb, kept only for use by crashinfo(8), which extracts > some basic information from a kernel core dump after a crash. If the > gdb port is installed crashinfo will use that in preference to > /usr/libexec/gdb. If neither exists it will not perform any analysis, > reporting "Unable to find a kernel debugger." > > GDB 6.1.1 was released in June 2004 and is long obsolete. It does not > support all of the architectures that FreeBSD does, and imposes > limitations on the FreeBSD kernel build - the continued use of DWARF2. > > I would like to remove GDB 6.1.1 before FreeBSD 13, and propose to > switch the GDB knob to default to NO in the near future. If the > crashinfo utility and related man pages do not already include > references to installing the gdb port/package I will add those before > making the change. > > In the fullness of time we may use LLDB to extract the same > information, or provide other tooling to do so, but I do not want to > block GDB 6.1.1's removal on this. > > Please let me know of any objections or comments. > I fully support this action. We kept gdb on board for 12 (and 11?) for crashinfo as a transition to the new gdb port and to help smooth over bumps from moving kgdb support into that port. jhb@ has done a great job in getting kgdb moved into the port. I use the port exclusively these days for all the kernel debugging I have to do from panics in our fleet (although I have some minorly special needs so I use a special script to fit into our buildenv vs deployed env). The current gdb in the base can't cope with anything more complicated than 'hello world'. It's broken for threads. It's broken for much of the code clang generates. It's useless for kernel dumps (even tracebacks are unreliable in my experience). There's little to no value that having gdb in the tree at this point. I also agree that none of this should be gated on lldb. gdb in tree is so out of date that we are much better off removing it, even if lldb isn't a complete drop in replacement (I've not used it at all, so I can't say one way or another). Warner ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Removing obsolete GDB 6.1.1 for FreeBSD 13
We currently have an obsolete version of GDB 6.1 installed as /usr/libexec/gdb, kept only for use by crashinfo(8), which extracts some basic information from a kernel core dump after a crash. If the gdb port is installed crashinfo will use that in preference to /usr/libexec/gdb. If neither exists it will not perform any analysis, reporting "Unable to find a kernel debugger." GDB 6.1.1 was released in June 2004 and is long obsolete. It does not support all of the architectures that FreeBSD does, and imposes limitations on the FreeBSD kernel build - the continued use of DWARF2. I would like to remove GDB 6.1.1 before FreeBSD 13, and propose to switch the GDB knob to default to NO in the near future. If the crashinfo utility and related man pages do not already include references to installing the gdb port/package I will add those before making the change. In the fullness of time we may use LLDB to extract the same information, or provide other tooling to do so, but I do not want to block GDB 6.1.1's removal on this. Please let me know of any objections or comments. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
