From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id iVvoAUD+4GnoUxwAWB0awg (envelope-from ) for ; Thu, 16 Apr 2026 11:20:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1776352832; bh=5WrmUoJcntJznkLpCwHxa1X0CMprYfa5Ys2Lor2ObZM=; h=Date:Subject:To:References:From:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=JJY71uS0pqZ51fCEjALhpjd7YULziUi6tDmdS9VEI+xNP76HxJy8jkdZasiImNdqU cuIsORNEu/hbBESIeUmih/5D04HEutP+jWG0Zse2YwzCQQ8Xf7wSUvwDWnH0NLqEJJ 6v8vdXDk1tm1WkPks98uc9j7ROGEYPKjqGnDyodw= Received: by simark.ca (Postfix, from userid 112) id 0316F1E0C3; Thu, 16 Apr 2026 11:20:31 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED, RCVD_IN_VALIDITY_RPBL_BLOCKED,RCVD_IN_VALIDITY_SAFE_BLOCKED autolearn=ham autolearn_force=no version=4.0.1 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=D52FiuEc; dkim-atps=neutral Received: from vm01.sourceware.org (vm01.sourceware.org [38.145.34.32]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 64E811E04F for ; Thu, 16 Apr 2026 11:20:31 -0400 (EDT) Received: from vm01.sourceware.org (localhost [127.0.0.1]) by sourceware.org (Postfix) with ESMTP id EF0914BB58BE for ; Thu, 16 Apr 2026 15:20:30 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org EF0914BB58BE Authentication-Results: sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=D52FiuEc Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id 436994BB58BE for ; Thu, 16 Apr 2026 15:20:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 436994BB58BE Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark.ca ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 436994BB58BE Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=158.69.221.121 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1776352801; cv=none; b=MsC0QUy3Gdb1rtLWAgJGh8jcHrnDD535PGpAXruk40sEyQ/SfQcTXYYY+UHYc6DrdLcR5jWIFckQGuiYjSBxK/jKnV3hczzF+VqU8v1XfZ6l5Mbq1R8hcH2KHA4LiEsBiXsdyFqkeE3nfw/xeBbDUUYEC6YppOoKXfPy72u/syU= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1776352801; c=relaxed/simple; bh=5WrmUoJcntJznkLpCwHxa1X0CMprYfa5Ys2Lor2ObZM=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=le1gce466nBsRiNETyXzX6EcuhTeG44ibOOwXSXl5KZMurt8j9lazq75NdVSP/xsWoT+OLS8HofYxmBRMZxWhsqMABEUbgYJxWw/M+kLz2599jS0oNCgcrjXFK0hDSF/89aPJ5a5BrZrIB2eBjPkAQn53s0GtfKJz7PKIxu0ZXw= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 436994BB58BE DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1776352799; bh=5WrmUoJcntJznkLpCwHxa1X0CMprYfa5Ys2Lor2ObZM=; h=Date:Subject:To:References:From:In-Reply-To:From; b=D52FiuEcynlxeW/V1yEIU1eIFZRQrTLcfVUALMAbiO3rDXRCFHpCZ5ly2mv+Mxl8A ASrb7d4PPeXz4U/kXCisY6E3ni5u97bVAyxU5ohllAMMasWxOOSRWqw4Of0YjG1RR3 ZBHuP6wgZUrmdxQig5kLmXgQy27A8lCLOt7CKKuw= Received: by simark.ca (Postfix) id BE0DE1E04F; Thu, 16 Apr 2026 11:19:59 -0400 (EDT) Message-ID: Date: Thu, 16 Apr 2026 11:19:59 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] testsuite: Skip fission-dw-form-strx with clang To: Bratislav Filipovic , gdb-patches@sourceware.org References: <20260416140306.1556274-1-bfilipov@amd.com> Content-Language: fr From: Simon Marchi In-Reply-To: <20260416140306.1556274-1-bfilipov@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org On 4/16/26 10:00 AM, Bratislav Filipovic wrote: > Clang's integrated assembler incorrectly sets the SHF_EXCLUDE flag > on .debug_*.dwo sections when assembling DWARF fission debug info. > This causes all linkers (both lld and GNU ld) to strip these > sections from the final output, breaking the test. > > This is a limitation of clang's integrated assembler, not a GDB > issue. The test works correctly with GCC's assembler, which does > not set this flag. > > A workaround exists (-fno-integrated-as to use GNU's external > assembler), but it is not practical to apply in the testsuite. > Therefore, restrict this test to GCC only. > --- > > I've investigated this thoroughly and found that clang's integrated > assembler hardcodes the SHF_EXCLUDE flag on .debug_*.dwo sections. > The only workaround I found is -fno-integrated-as, which forces clang > to use GNU's external assembler. > > Does anyone have suggestions for making this test work with clang > without skipping it entirely? Or should we report this to LLVM as a bug? Can you explain what is the sequence of compiling / linking steps in this test? Normally, I think that .dwo sections are not meant to go through a linker. This is how gcc works: - cc1 compiler produces a .o file containing .dwo sections - objcopy extracts the .dwo sections to a .dwo file using --extract-dwo - objcopy strips the .dwo sections from the .o file using --strip-dwo - linker links the final executable from the .o files, without the .dwo sections I don't know how clang operates, but it seems fine for the .dwo sections to have SHF_EXCLUDE: if they are still present at the link step, we don't want them to end up in the final executable. If we see that in this test the .dwo sections go through the linker and get discarded, it might be the test that is doing things wrong. See the commit log here for example: https://gitlab.com/gnutools/binutils-gdb/-/commit/6a29913eeb98595b76a7c5a3b3c2c4464c7c1484 In this commit, I fixed a test (that I had written myself initially, before understanding the .dwo flow I described above) that was running the .dwo sections through the linker, and that was causing other problems. Simon