From nobody Fri Feb 9 20:15:06 2024 X-Original-To: toolchain@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TWlTC1ySSz5BGnR for ; Fri, 9 Feb 2024 20:15:11 +0000 (UTC) (envelope-from pjfloyd@wanadoo.fr) Received: from smtp.smtpout.orange.fr (smtp-21.smtpout.orange.fr [80.12.242.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "*.smtpout.orange.fr", Issuer "DigiCert Global G2 TLS RSA SHA256 2020 CA1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TWlTB23ywz40MQ for ; Fri, 9 Feb 2024 20:15:10 +0000 (UTC) (envelope-from pjfloyd@wanadoo.fr) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=wanadoo.fr header.s=t20230301 header.b=silRtRoN; dmarc=pass (policy=none) header.from=wanadoo.fr; spf=pass (mx1.freebsd.org: domain of pjfloyd@wanadoo.fr designates 80.12.242.21 as permitted sender) smtp.mailfrom=pjfloyd@wanadoo.fr Received: from [192.168.1.28] ([90.112.30.115]) by smtp.orange.fr with ESMTPA id YXH8rQsiVCB5QYXH9rSlhT; Fri, 09 Feb 2024 21:15:07 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wanadoo.fr; s=t20230301; t=1707509707; bh=dk6T1ajDKhsqN5b+zJY0xPMagaYzvaQ95Mb3i5IWLCE=; h=Date:To:From:Subject; b=silRtRoNRvhhthz6lIYlw7CVcIApJlIN2zlt7xoPACHOAbj1AvGk57Ix3LrOEnB8G iZb0COGKHy3yFtMI8rtBZBYkJCxibg9D0kUuAoLBmkNO1EtvfTmfqdoYMJjr63llqc jZ284PTZbqrLtsMOO3+e03gv6EPFHdpoKxKvSVudMt0H1Nlh7X5fpYo06uWnnU3G7I VfnJrcNe0OlBzFsuAiEdRr3m5Rfgp4x7W+NnwzR6xXQ5TBq50DrX4sGU/EimUYD6Dy At5Y/Za6+9mOd7ShfNdIXwWvGJDrKp7UK877vGFjWIYqsFRrdpV7YLZDIGJ40ZSi+W KWfZZgzJ1CVLg== X-ME-Helo: [192.168.1.28] X-ME-Auth: cGpmbG95ZEB3YW5hZG9vLmZy X-ME-Date: Fri, 09 Feb 2024 21:15:07 +0100 X-ME-IP: 90.112.30.115 Message-ID: <33b63792-0311-4f71-b75d-ba12b51510a7@wanadoo.fr> Date: Fri, 9 Feb 2024 21:15:06 +0100 List-Id: Maintenance of FreeBSD s integrated toolchain List-Archive: https://lists.freebsd.org/archives/freebsd-toolchain List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: toolchain@FreeBSD.org Content-Language: en-US From: Paul Floyd Subject: debuginfo changes Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.20 / 15.00]; NEURAL_HAM_LONG(-1.00)[-0.999]; NEURAL_HAM_MEDIUM(-0.96)[-0.960]; NEURAL_HAM_SHORT(-0.95)[-0.951]; DMARC_POLICY_ALLOW(-0.50)[wanadoo.fr,none]; RWL_MAILSPIKE_EXCELLENT(-0.40)[80.12.242.21:from]; R_DKIM_ALLOW(-0.20)[wanadoo.fr:s=t20230301]; R_SPF_ALLOW(-0.20)[+ip4:80.12.242.0/25]; ONCE_RECEIVED(0.10)[]; MIME_GOOD(-0.10)[text/plain]; XM_UA_NO_VERSION(0.01)[]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; DWL_DNSWL_NONE(0.00)[wanadoo.fr:dkim]; FREEMAIL_FROM(0.00)[wanadoo.fr]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[wanadoo.fr:+]; FROM_EQ_ENVFROM(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[toolchain@freebsd.org]; TO_DN_NONE(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:3215, ipnet:80.12.240.0/20, country:FR]; FREEMAIL_ENVFROM(0.00)[wanadoo.fr]; RCVD_IN_DNSWL_NONE(0.00)[80.12.242.21:from] X-Rspamd-Queue-Id: 4TWlTB23ywz40MQ Hi I recently upgraded from FreeBSD 13.2 to 14.0 amd64. I'm getting one new Valgrind regression test failure that seems to be related to DWARF debuginfo. The changes are partly better, partly worse. Here is an example from the diff Uninitialised byte(s) found during client check request at 0x........: croak (tests/varinfo5so.c:29) - by 0x........: bar3 (tests/varinfo5so.c:97) by 0x........: foo3 (tests/varinfo5so.c:110) - by 0x........: varinfo3_main (tests/varinfo5so.c:118) by 0x........: varinfo5_main (tests/varinfo5so.c:156) by 0x........: main (tests/varinfo5.c:5) - Address 0x........ is on thread 1's stack - in frame #X, created by foo3 (varinfo5so.c:101) + Location 0x........ is 0 bytes inside nonstatic_local_undef[8], + declared at varinfo5so.c:105, in frame #X of thread 1 The good bit it at the end. Valgrind has found the variable name rather than just saying it is on the stack. The bad bit is the missing lines in the callstack. They are due to inline functions. Does anyone have any information as to what might have changed between clang 14.0.5 and 16.0.6? A+ Paul