Date: Sun, 5 Jan 2014 14:00:03 +0100 From: Dimitry Andric <dim@FreeBSD.org> To: Ed Schouten <ed@80386.nl> Cc: freebsd-toolchain@freebsd.org Subject: Re: [CFT] Update to clang 3.4 Message-ID: <29C2D69E-9EC8-418D-A333-FC1A8DA2133B@FreeBSD.org> In-Reply-To: <CAJOYFBAf6rsZvNKgm5O-_rS%2BR5c=7939A3THNXanVSHVMnZcog@mail.gmail.com> References: <541C998A-071A-4917-9D91-DD00CB0E2689@FreeBSD.org> <CAJOYFBAf6rsZvNKgm5O-_rS%2BR5c=7939A3THNXanVSHVMnZcog@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--Apple-Mail=_7399F1A6-F0A0-435A-9444-93C083C2727E Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 05 Jan 2014, at 13:06, Ed Schouten <ed@80386.nl> wrote: > 2014/1/1 Dimitry Andric <dim@freebsd.org>: >> Another important new issue is that clang 3.4 now outputs DWARF4 as >> default format when using -g. Our ancient version of gdb in base does >> not support this, so you must either install the gdb port, or build lldb >> and use it (very experimental at this time!). > > Would it make sense to just change our copy of Clang to emit DWARF2 > when using -g? People expect that -g emits something that can be used > by our shipped version of gdb. There are multiple problems with that: first of all, it changes the upstream defaults, which I am very reluctant to do. Upstream actually wants to get rid of older DWARF support, since that makes their code needlessly complicated, and the rest of the world has long since moved on to newer DWARF versions. Even gcc defaults to DWARF4 now. Second, the shipped version of gdb in our tree is very old, and is basically unmaintained. Nobody in their right mind should ever use it for debugging, unless they have no other choice. As soon as the in-tree version of lldb is in workable state, we should get rid of the base gdb. I think the only tricky task left is our custom kgdb hacks, which must be ported to some newer version of gdb soon, or preferably to lldb. I have no idea if anybody is working on those. Last but not least, I can build a kernel with -gdwarf-2, but ctfconvert and/or ctfmerge still have some trouble correctly converting and/or merging the debug information to CTF. So there is something broken in either the DWARF2 output, or there is a problem in ctfconvert and ctfmerge. I need some assistance with this, from somebody who knows exactly how CTF and DTrace work together. Our CTF tools use libdwarf in base, which is also quite old, and seems to be largely unmaintained. It does not seem to support anything beyond DWARF2. I think it would be worthwhile to upgrade this library from upstream ASAP. -Dimitry --Apple-Mail=_7399F1A6-F0A0-435A-9444-93C083C2727E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iEYEARECAAYFAlLJV2AACgkQsF6jCi4glqPaBwCfSspAomAXe/zZC7hPDjIBfFBb 4j8AnAhCbXFWzv2Kw9fuW9PuCCC6bnRa =j9iq -----END PGP SIGNATURE----- --Apple-Mail=_7399F1A6-F0A0-435A-9444-93C083C2727E--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?29C2D69E-9EC8-418D-A333-FC1A8DA2133B>