From owner-freebsd-toolchain@freebsd.org Mon Jul 27 19:37:40 2020 Return-Path: Delivered-To: freebsd-toolchain@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 3FF8536CDFA for ; Mon, 27 Jul 2020 19:37:40 +0000 (UTC) (envelope-from pjfloyd@wanadoo.fr) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4BFqpD0Nnrz4GDR for ; Mon, 27 Jul 2020 19:37:40 +0000 (UTC) (envelope-from pjfloyd@wanadoo.fr) Received: by mailman.nyi.freebsd.org (Postfix) id 0B94736D2B7; Mon, 27 Jul 2020 19:37:40 +0000 (UTC) Delivered-To: toolchain@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 0B59F36CDF9 for ; Mon, 27 Jul 2020 19:37:40 +0000 (UTC) (envelope-from pjfloyd@wanadoo.fr) Received: from smtp.smtpout.orange.fr (smtp06.smtpout.orange.fr [80.12.242.128]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "Bizanga Labs SMTP Client Certificate", Issuer "Bizanga Labs CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BFqpC11gqz4Gb1 for ; Mon, 27 Jul 2020 19:37:38 +0000 (UTC) (envelope-from pjfloyd@wanadoo.fr) Received: from garrigue.home ([2.7.112.8]) by mwinf5d82 with ME id 8Kdd2300E0AvN5u03Kddds; Mon, 27 Jul 2020 21:37:37 +0200 X-ME-Helo: garrigue.home X-ME-Auth: cGpmbG95ZEB3YW5hZG9vLmZy X-ME-Date: Mon, 27 Jul 2020 21:37:37 +0200 X-ME-IP: 2.7.112.8 From: Paul Floyd Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: Getting started with clang debuginfo Date: Mon, 27 Jul 2020 21:37:34 +0200 References: <1139268534.2282.1595842060133.JavaMail.www@wwinf1m22> <20200727143753.GA59953@raichu> <20200727153913.GC2551@kib.kiev.ua> To: toolchain@freebsd.org In-Reply-To: <20200727153913.GC2551@kib.kiev.ua> Message-Id: <620939C4-27B3-498C-AD9B-D1645F7C869B@wanadoo.fr> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 4BFqpC11gqz4Gb1 X-Spamd-Bar: ++++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of pjfloyd@wanadoo.fr has no SPF policy when checking 80.12.242.128) smtp.mailfrom=pjfloyd@wanadoo.fr X-Spamd-Result: default: False [4.05 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[wanadoo.fr]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[wanadoo.fr]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; RECEIVED_SPAMHAUS_PBL(0.00)[2.7.112.8:received]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_SPAM_MEDIUM(0.84)[0.840]; NEURAL_SPAM_LONG(0.92)[0.918]; RCVD_IN_DNSWL_NONE(0.00)[80.12.242.128:from]; NEURAL_SPAM_SHORT(0.89)[0.894]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:3215, ipnet:80.12.240.0/20, country:FR]; RCVD_COUNT_TWO(0.00)[2]; FREEMAIL_ENVFROM(0.00)[wanadoo.fr]; RWL_MAILSPIKE_POSSIBLE(0.00)[80.12.242.128:from] X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2020 19:37:40 -0000 > On 27 Jul 2020, at 17:39, Konstantin Belousov = wrote: >=20 > On Mon, Jul 27, 2020 at 10:37:53AM -0400, Mark Johnston wrote: >> On Mon, Jul 27, 2020 at 11:27:40AM +0200, Paul FLOYD wrote: >>> Hi >>> =20 >>> I'm investigating some of the remaining issues with Valgrind on = FreeBSD. One of the two remaining major issues that I'm aware of is with = Valgrind reading dwarf debuginfo from clang compiled binaries. The = problem isn't too bad with clang 8 on FreeBSD 12.1. On 13-CURRENT with = clang 10 things are noticeably worse. For GCC built binaries I'm not = aware of any issues. >>> =20 >>> I'm not familiar (yet) with the debuginfo code in Valgrind. >>> =20 >>> To get me going, does anyone have any pointers to >>> - documentation on clang debuginfo > Clang generates DWARF which is documented by the DWARF standard(s), > available at http://dwarfstd.org/ The site seems to be down ATM. =46rom what I=E2=80=99ve read, DWARF is somewhat flexible and allows for = vendor extensions. For instance I=E2=80=99ve already seen = DW_AT_GNU_all_call_sites and DW_GNU_all_tail_call_sites. >=20 >>> - any info on differences wrt GCC (I have seen that GCC does have = some debuginfo extensions) > Gcc also generates DWARF. It is up to the compiler to interpret the = standard > and provide compliant metadata according to it. >=20 > But I would expect that the practical difference or troubles in = parsing > the compiler' output is due to different versions of the used = standard. > Both gcc and clang allow to specify which level of standard should be > used, see the description of the -gdwarf- switch. >=20 > Different versions of the same compiler might default to different=20 > version of DWARF as well. >=20 No, I don=E2=80=99t think that is the problem. Valgrind can read DWARF = up to version 4 (not 5). If it encounters a version it does not know = about it says so directly =3D=3D1602=3D=3D Command: ./leak_dwarf5 =3D=3D1602=3D=3D=20 --1602-- WARNING: Serious error when reading debug info --1602-- When reading debug info from = /usr/home/paulf/scratch/vg_examples/leak_dwarf5: --1602-- Ignoring non-Dwarf2/3/4 block in .debug_info --1602-- WARNING: Serious error when reading debug info --1602-- When reading debug info from = /usr/home/paulf/scratch/vg_examples/leak_dwarf5: --1602-- parse_CU_Header: is neither DWARF2 nor DWARF3 nor DWARF4 =3D=3D1602=3D=3D=20 So I suspect that this is a question of dialect rather than version. A+ Paul