From owner-freebsd-toolchain@freebsd.org Thu Dec 3 16:57:53 2015 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 11272A3F646 for ; Thu, 3 Dec 2015 16:57:53 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AA8B3145E; Thu, 3 Dec 2015 16:57:52 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 84FF1B9C0; Thu, 3 Dec 2015 11:57:51 -0500 (EST) From: John Baldwin To: Craig Rodrigues Cc: Dag-Erling =?ISO-8859-1?Q?Sm=F8rgrav?= , FreeBSD Toolchain , Pedro Giffuni , David Chisnall , Garrett Cooper , Allan Jude , Kurt Lidl , Dimitry Andric Subject: Re: Can we have a toolchain that works? Date: Thu, 03 Dec 2015 07:54:41 -0800 Message-ID: <22020101.bKcckG4jXT@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.2-STABLE; KDE/4.14.3; amd64; ; ) In-Reply-To: References: <86egf5ckwa.fsf@desk.des.no> <86io4guekw.fsf@desk.des.no> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 03 Dec 2015 11:57:51 -0500 (EST) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2015 16:57:53 -0000 On Thursday, December 03, 2015 01:15:00 AM Craig Rodrigues wrote: > [Moving discussion to freebsd-toolchain] > > Dag, > > Regarding your question about a working debugger, due to your problems > debugging > code with the in-tree gdb on latest current, we have a few options: > > (1) Enable WITH_LLDB by default in the make infrastructure, and install > lldb. > > We already have lldb in the tree: > https://svnweb.freebsd.org/base/head/contrib/llvm/tools/lldb/ > but it is not built by default. > > lldb does not have kgdb support though. > > (2) Kick gdb out of the base system, and tell people to install the > devel/gdb port. > This will install gdb 7.10 from ports. > This port also installs kgdb As noted in a recent thread on arch@ it is not quite that simple. lldb only supports amd64 and arm64 AFAIK (perhaps arm as well?). It does not support i386 yet, and it does not have meaningful support for kernel debugging (there was an SoC project to add a subset of amd64-only kgdb support that is a decent start). devel/gdb only supports x86 and powerpc. sparc64 is also supported upstream, but not in the port IIRC. It supports kgdb for x86 well, but on powerpc64 (the only other arch I've been able to test under qemu), kgdb isn't able to unwind the stack past the initial frame in cpu_switch, though with some small patches to at least get the initial frame more correct I can see all the threads in info threads and kld symbols are loaded ok. devel/gdb is also the only debugger (to my knowledge) that handles some more exotic uses like fork following and AVX (on x86). The only debugger we have for mips (possibly arm?) and sparc64 and for kgdb on mips, arm, sparc64 is in-tree gdb. One limitation of this debugger is it is native-only. Both lldb and devel/gdb are cross debuggers out of the box (e.g. devel/gdb should be able to examine a process core and (after my libkvm commit) a kernel core from any platform it supports on any platform where it runs). I believe lldb includes all supported platforms out of the box as well. Somewhat in my spare time I want to fill in more of the gaps in devel/gdb coverage (rewrite threads to use ptrace directly and be MI without requiring hacks in each backend the way the current fbsd-threads.c target does; other platforms like arm; kgdb on other platforms). Realistically this means we can't axe gdb in base from all platforms today as we'd have platforms with no debugger. As I mentioned previously, there was a recent thread on arch@ on this very topic. -- John Baldwin