| Message ID | 20260402102559.323847-1-bfilipov@amd.com |
|---|---|
| State | New |
| Headers |
Return-Path: <gdb-patches-bounces~patchwork=sourceware.org@sourceware.org> X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from vm01.sourceware.org (localhost [127.0.0.1]) by sourceware.org (Postfix) with ESMTP id 571ED4BA2E32 for <patchwork@sourceware.org>; Thu, 2 Apr 2026 10:26:55 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 571ED4BA2E32 Authentication-Results: sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=amd.com header.i=@amd.com header.a=rsa-sha256 header.s=selector1 header.b=v6PcHTFw X-Original-To: gdb-patches@sourceware.org Delivered-To: gdb-patches@sourceware.org Received: from BN1PR04CU002.outbound.protection.outlook.com (mail-eastus2azon11010061.outbound.protection.outlook.com [52.101.56.61]) by sourceware.org (Postfix) with ESMTPS id F2C824BA2E2B for <gdb-patches@sourceware.org>; Thu, 2 Apr 2026 10:26:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org F2C824BA2E2B Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=amd.com Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=amd.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org F2C824BA2E2B Authentication-Results: server2.sourceware.org; arc=pass smtp.remote-ip=52.101.56.61 ARC-Seal: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1775125581; cv=pass; b=mA/9j7/22LuEJShrwCaw7S0VkSK/htW/2wf9ZCIwbfgnO7Pg1ZjHjAy0kYEPSNpEtS7QtVCXjhLAj+9M4MEJyINZSitAsz5ynH68npVpt3+nYEWGItsmv/FbkObRm7C6B2/eKIs5l2e1+onMEr3sqth9KkQLMXoZLFMLGdWkeSc= ARC-Message-Signature: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1775125581; c=relaxed/simple; bh=TlJlXr+eHWTxln9/YkbKofdcWN1nMffumgHVwDA1d8g=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=hNHl1YDk56koHwLn9LVXyf0JQCQUYPj3r4eHb4qIbWB2ExjidUMK+1ZZ4gSpclOw9LUt1zIroHpkV4pCiwFLANRDVV7OZVIktlWdbwcqmh/EjNTnnIauUiIvR7GiapzXcz9lgXIKBPjlmXv0qGFAahSI5zNercsSko6F8bWHJs4= ARC-Authentication-Results: i=2; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org F2C824BA2E2B ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=D0CgpI+5yFgcPaubUKnKD/xe7N9yFLWMJV7FvHa5ZhiLdm0CK78X/C4j7AocTGwNyerzu6c/2nMeGulkhiiNLMhZs0PjCkuKpy7MXpNqgdMXV4Jjj5jUmVlM3SlocySlwJQjxjM8i8vVN89ahMN2eq1UsLBqMnDvYZ+u0LFA9upM8pZyt9i2mY2ftO4G8P3l5Y1PxdrIJouxbRz7AXrB1gZDpIvkXsLO/TJvQ0Sux75jpc8AWOGAzkd4ie+cHhndmS0wBKlqnEqec3p1A5q+zdGE1peBCTfXz3uGLrNcS3TEwun46fqvGiZ7Mn4IlUNWiTGzLIw4R4KPDc3jbuOEpA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=sPIihonTJ0gqKK/bDxr8VULfK1IRPaL1w3rVH/5s3ds=; b=fEwHdU5UzLuo+xWED0E9uTromh05kvqPmgjdqpOH76NcM4NFUuGkVLqYd7IGIh+PXU4lqjMNOaC/YvlK40GTuhefhwHBFhacMethIh8bnv2io8zvP0o5UvlZJdfIGKK56VwLUag5JRb7AZYeWRIQXJjLURhvA/rJp9jLLlCY0VHXH83hHzWo+XlWp6uCZVfhgbYNw8JH3EWjkl4lVuFG6xcTa/8YfFH9JyNwRbqrD6gfoIPGyd6ab2n0bmuo3mfgn4LwK4kSzy5//6uX0SFwLG6rg886uNeIWdE4Ts86BhgWjpsK2vf9JPjJJYjN5qW+nIiPDGJCjnfsJcZkSK8TkQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=redhat.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=sPIihonTJ0gqKK/bDxr8VULfK1IRPaL1w3rVH/5s3ds=; b=v6PcHTFw4oNCjV3d2+6POIo6H6X4ZGUhqVGIscgVumLhTeb7mWbO2X8nP/Opf8nKxxbMjxIzxP0ENK9v/VMejPlJBl0Cru+pMsGG6YKMcXu2HHmybquOlLZHKlBBN/dP2Gco3OpLUgAYnBg2XDSomSjJZWdMDVQm1y2OGcdCZPQ= Received: from MW4PR04CA0390.namprd04.prod.outlook.com (2603:10b6:303:81::35) by MN2PR12MB4357.namprd12.prod.outlook.com (2603:10b6:208:262::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9769.19; Thu, 2 Apr 2026 10:26:16 +0000 Received: from CO1PEPF000066ED.namprd05.prod.outlook.com (2603:10b6:303:81:cafe::b1) by MW4PR04CA0390.outlook.office365.com (2603:10b6:303:81::35) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9745.30 via Frontend Transport; Thu, 2 Apr 2026 10:26:16 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C Received: from satlexmb07.amd.com (165.204.84.17) by CO1PEPF000066ED.mail.protection.outlook.com (10.167.249.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9769.17 via Frontend Transport; Thu, 2 Apr 2026 10:26:16 +0000 Received: from rocm-BirmanPlus-KRK2e.amd.com (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Thu, 2 Apr 2026 05:26:13 -0500 From: Bratislav Filipovic <bfilipov@amd.com> To: <aburgess@redhat.com> CC: <bfilipov@amd.com>, <gdb-patches@sourceware.org>, <simon.marchi@efficios.com> Subject: [PATCH] test: basename filenames in dwarf2 frame checks Date: Thu, 2 Apr 2026 15:54:42 +0530 Message-ID: <20260402102559.323847-1-bfilipov@amd.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <87a4vl659l.fsf@redhat.com> References: <87a4vl659l.fsf@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [10.180.168.240] X-ClientProxiedBy: satlexmb07.amd.com (10.181.42.216) To satlexmb07.amd.com (10.181.42.216) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CO1PEPF000066ED:EE_|MN2PR12MB4357:EE_ X-MS-Office365-Filtering-Correlation-Id: e59aa4a6-ae68-4001-981b-08de90a245eb X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; ARA:13230040|82310400026|1800799024|36860700016|376014|18002099003|22082099003|56012099003; X-Microsoft-Antispam-Message-Info: FhbcKZJ+mpXzoGBDZ0PLj3euTJArdEg727CnpLcum4FLRpHdk1HCGpDrVQTjes/jSHdG6dhChWfUrvNohP+L+Ffy7fnR2vqZ+mPyAhRcEMqqXw7DJqmq8uKCAoQg+xjpdzf4fAwUy4ftQpgNRu8x4mSv8JNyfG91/fPF5KgL+UZQWlr4akfbp/AA/2bnvw49uPzilz+zfcvr+4Lrz+ggE2bDq0vCpSSKnlXM9yAI5UHQWQUDb9kpCHlTAQiji1/Lrtj707YKjGlv3rN4CE2BwG21KRTR9MeCVnPjJQFobHIkxn3iDCpwJ5RTLToWjCZkyAM5VIJA6iB6DIIyfgXhHGa5ETvmJmTDvRNbfvg9wnrZ4CnlOIJjAUB3kCucp/KeP1QYhE+fVZW0/U9wJat5HbzAep6aWPRRyRkj9J1yl/AtTe6dBsFmC3ZWz2lq8LjY8Tg5T4zCvNuiHeBtV0shbrKZDbWMWnl0yfwFtJnXJa09ihBsYCsbzxdpJvbCccMIPLwlDVq7Zgc6bbBS5Rzu/b9ItIdheixYh005Y1aIv0crvFEs4G3rzv9O9Q71cKwk0gj/KTVmDlrEIIXpa1DlAqBv16C3dQx/OcFb2x+HwGjVEDCLxSGpRGwel5tkTrj66qMEwk5lm7JuSVEpeW8Ik2JP8lsgtiLvI98xIBi0Ss1961XgvtRMshjSdmHj063q9Wk4xPjkm+e6C6ah0ZuOxK5CJ87nV6wFWl2SU/5uwB96w72bX2qOJ0yqQlL+ZK2HMIR3tV4GsD8rMBd8qSHMhA== X-Forefront-Antispam-Report: CIP:165.204.84.17; CTRY:US; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:satlexmb07.amd.com; PTR:InfoDomainNonexistent; CAT:NONE; SFS:(13230040)(82310400026)(1800799024)(36860700016)(376014)(18002099003)(22082099003)(56012099003); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: aemXwFe2E6GKE4bUUDL4Zz+qyUWVt/bBO0sa9Q24PBoL9VoxTK27VrnIUFHf9QYX4wTPHQeQYtP+JVoBYCUSG0H8+duOa9R2GqW0nOAIxe+9wPbW1QsimUYZHCvta0MIV5FcgUNMgIRc1EX8Tg3Z9d4jX32yakVE6EBGNZNaUF2MLOhDKRtRaqpfTnk0FdznxEcyuxUlgXAvq+zc5CSvsOGBZuf6pkYWgfXxMYukb1lc+M/bVt5t3BEX+LtARXSEfqlLizevYwMK0Mya2+smzezKjDaGbwQBWNVhkXc3l6LLMffGHZU9MExFGp4vAhOcqYkKPYTo8cpw7la2oZSf5X+pjUaYoJ/xh76yqFUG5zMpdoQ+uOJZXx3S+FePv54ua5okkAsYFqVuZxBEXHKaYSTNkPIJU+mf3kp8RHlV51VK7smnFOfywVHbADeD5t0W X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Apr 2026 10:26:16.4002 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: e59aa4a6-ae68-4001-981b-08de90a245eb X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d; Ip=[165.204.84.17]; Helo=[satlexmb07.amd.com] X-MS-Exchange-CrossTenant-AuthSource: CO1PEPF000066ED.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR12MB4357 X-Spam-Status: No, score=-9.5 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FORGED_SPF_HELO, GIT_PATCH_0, LOCAL_AUTHENTICATION_FAIL_SPF, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_PASS, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list <gdb-patches.sourceware.org> List-Unsubscribe: <https://sourceware.org/mailman/options/gdb-patches>, <mailto:gdb-patches-request@sourceware.org?subject=unsubscribe> List-Archive: <https://sourceware.org/pipermail/gdb-patches/> List-Post: <mailto:gdb-patches@sourceware.org> List-Help: <mailto:gdb-patches-request@sourceware.org?subject=help> List-Subscribe: <https://sourceware.org/mailman/listinfo/gdb-patches>, <mailto:gdb-patches-request@sourceware.org?subject=subscribe> Errors-To: gdb-patches-bounces~patchwork=sourceware.org@sourceware.org |
| Series |
test: basename filenames in dwarf2 frame checks
|
|
Checks
| Context | Check | Description |
|---|---|---|
| linaro-tcwg-bot/tcwg_gdb_build--master-arm | success | Build passed |
| linaro-tcwg-bot/tcwg_gdb_build--master-aarch64 | success | Build passed |
| linaro-tcwg-bot/tcwg_gdb_check--master-aarch64 | success | Test passed |
| linaro-tcwg-bot/tcwg_gdb_check--master-arm | success | Test passed |
Commit Message
Bratislav Filipovic
April 2, 2026, 10:24 a.m. UTC
Some gdb.dwarf2 tests match the output of commands like frame and
expect to see locations printed as fission-base.c:LINE (no directory
prefix). When the test programs are built with clang as CC_FOR_TARGET,
GDB can print an absolute source path instead, causing FAILs.
For example, with clang:
(gdb) PASS: gdb.dwarf2/fission-base.exp: ptype func
(gdb) frame
#0 main () at /path/to/gdb/testsuite/fission-base.c:27
27 return func (-1);
(gdb) FAIL: gdb.dwarf2/fission-base.exp: frame in main
With gcc:
(gdb) PASS: gdb.dwarf2/fission-base.exp: ptype func
(gdb) frame
#0 main () at fission-base.c:27
27 return func (-1);
(gdb) PASS: gdb.dwarf2/fission-base.exp: frame in main
The difference comes from the DWARF line table contents. With clang,
the .debug_line directory table can contain an absolute directory that
the file table entries reference:
The Directory Table:
0 /path/to/gdb/testsuite
The File Name Table:
0 Dir=0 Name=fission-base.c
1 Dir=0 Name=fission-base.c
Whereas with gcc the directory table is empty and only the bare filename
is present:
The Directory Table is empty.
The File Name Table:
1 Name=fission-base.c
This difference reflects toolchain/assembler behavior in how .file/.loc
are translated into .debug_line and is orthogonal to what these tests
aim to validate.
Force set filename-display basename in the affected tests so the
output is stable across toolchains.
Test: gdb.dwarf2/fission-base.exp (CC_FOR_TARGET=clang, gcc)
Test: gdb.dwarf2/dw2-undefined-ret-addr.exp (CC_FOR_TARGET=clang, gcc)
---
Thanks for the review Andrew. Fixed the comments.
Regards Bratislav
gdb/testsuite/gdb.dwarf2/dw2-undefined-ret-addr.exp | 5 +++++
gdb/testsuite/gdb.dwarf2/fission-base.exp | 5 +++++
2 files changed, 10 insertions(+)
Comments
Bratislav Filipovic <bfilipov@amd.com> writes: > Some gdb.dwarf2 tests match the output of commands like frame and > expect to see locations printed as fission-base.c:LINE (no directory > prefix). When the test programs are built with clang as CC_FOR_TARGET, > GDB can print an absolute source path instead, causing FAILs. > > For example, with clang: > > (gdb) PASS: gdb.dwarf2/fission-base.exp: ptype func > (gdb) frame > #0 main () at /path/to/gdb/testsuite/fission-base.c:27 > 27 return func (-1); > (gdb) FAIL: gdb.dwarf2/fission-base.exp: frame in main > > With gcc: > > (gdb) PASS: gdb.dwarf2/fission-base.exp: ptype func > (gdb) frame > #0 main () at fission-base.c:27 > 27 return func (-1); > (gdb) PASS: gdb.dwarf2/fission-base.exp: frame in main > > The difference comes from the DWARF line table contents. With clang, > the .debug_line directory table can contain an absolute directory that > the file table entries reference: > > The Directory Table: > 0 /path/to/gdb/testsuite > > The File Name Table: > 0 Dir=0 Name=fission-base.c > 1 Dir=0 Name=fission-base.c > > Whereas with gcc the directory table is empty and only the bare filename > is present: > > The Directory Table is empty. > > The File Name Table: > 1 Name=fission-base.c > > This difference reflects toolchain/assembler behavior in how .file/.loc > are translated into .debug_line and is orthogonal to what these tests > aim to validate. > > Force set filename-display basename in the affected tests so the > output is stable across toolchains. > > Test: gdb.dwarf2/fission-base.exp (CC_FOR_TARGET=clang, gcc) > Test: gdb.dwarf2/dw2-undefined-ret-addr.exp (CC_FOR_TARGET=clang, gcc) > --- > > Thanks for the review Andrew. Fixed the comments. Looks good. Feel free to push this patch. Approved-By: Andrew Burgess <aburgess@redhat.com> Thanks, Andrew > > Regards Bratislav > > > gdb/testsuite/gdb.dwarf2/dw2-undefined-ret-addr.exp | 5 +++++ > gdb/testsuite/gdb.dwarf2/fission-base.exp | 5 +++++ > 2 files changed, 10 insertions(+) > > diff --git a/gdb/testsuite/gdb.dwarf2/dw2-undefined-ret-addr.exp b/gdb/testsuite/gdb.dwarf2/dw2-undefined-ret-addr.exp > index 32ddaf4a..88765d4f 100644 > --- a/gdb/testsuite/gdb.dwarf2/dw2-undefined-ret-addr.exp > +++ b/gdb/testsuite/gdb.dwarf2/dw2-undefined-ret-addr.exp > @@ -30,6 +30,11 @@ if {![runto "stop_frame"]} { > return -1 > } > > +# If test is compiled with clang, GDB would display absolute path. > +# This command keeps output consistent across toolchains. > + > +gdb_test_no_output "set filename-display basename" > + > # stop_frame should be the outermost frame. > > # Check that backtrace shows only frame #0. > diff --git a/gdb/testsuite/gdb.dwarf2/fission-base.exp b/gdb/testsuite/gdb.dwarf2/fission-base.exp > index 035fe731..d1abf6c9 100644 > --- a/gdb/testsuite/gdb.dwarf2/fission-base.exp > +++ b/gdb/testsuite/gdb.dwarf2/fission-base.exp > @@ -46,6 +46,11 @@ if {![runto_main]} { > gdb_test "ptype main" "type = int \\(\\)" > gdb_test "ptype func" "type = int \\(int\\)" > > +# If test is compiled with clang, GDB would display absolute path. > +# This command keeps output consistent across toolchains. > + > +gdb_test_no_output "set filename-display basename" > + > gdb_test "frame" "#0 *main \\(\\) at $testfile\\.c:$decimal.*" \ > "frame in main" > > -- > 2.43.0
[AMD Official Use Only - AMD Internal Distribution Only] Hello Andrew, I still don't have write-after-approval yet. Can you get it pushed? Regards Bratislav -----Original Message----- From: Andrew Burgess <aburgess@redhat.com> Sent: Thursday, April 2, 2026 2:53 PM To: Filipovic, Bratislav <Bratislav.Filipovic@amd.com> Cc: Filipovic, Bratislav <Bratislav.Filipovic@amd.com>; gdb-patches@sourceware.org; simon.marchi@efficios.com Subject: Re: [PATCH] test: basename filenames in dwarf2 frame checks [You don't often get email from aburgess@redhat.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding. Bratislav Filipovic <bfilipov@amd.com> writes: > Some gdb.dwarf2 tests match the output of commands like frame and > expect to see locations printed as fission-base.c:LINE (no directory > prefix). When the test programs are built with clang as > CC_FOR_TARGET, GDB can print an absolute source path instead, causing FAILs. > > For example, with clang: > > (gdb) PASS: gdb.dwarf2/fission-base.exp: ptype func > (gdb) frame > #0 main () at /path/to/gdb/testsuite/fission-base.c:27 > 27 return func (-1); > (gdb) FAIL: gdb.dwarf2/fission-base.exp: frame in main > > With gcc: > > (gdb) PASS: gdb.dwarf2/fission-base.exp: ptype func > (gdb) frame > #0 main () at fission-base.c:27 > 27 return func (-1); > (gdb) PASS: gdb.dwarf2/fission-base.exp: frame in main > > The difference comes from the DWARF line table contents. With clang, > the .debug_line directory table can contain an absolute directory that > the file table entries reference: > > The Directory Table: > 0 /path/to/gdb/testsuite > > The File Name Table: > 0 Dir=0 Name=fission-base.c > 1 Dir=0 Name=fission-base.c > > Whereas with gcc the directory table is empty and only the bare > filename is present: > > The Directory Table is empty. > > The File Name Table: > 1 Name=fission-base.c > > This difference reflects toolchain/assembler behavior in how > .file/.loc are translated into .debug_line and is orthogonal to what > these tests aim to validate. > > Force set filename-display basename in the affected tests so the > output is stable across toolchains. > > Test: gdb.dwarf2/fission-base.exp (CC_FOR_TARGET=clang, gcc) > Test: gdb.dwarf2/dw2-undefined-ret-addr.exp (CC_FOR_TARGET=clang, gcc) > --- > > Thanks for the review Andrew. Fixed the comments. Looks good. Feel free to push this patch. Approved-By: Andrew Burgess <aburgess@redhat.com> Thanks, Andrew > > Regards Bratislav > > > gdb/testsuite/gdb.dwarf2/dw2-undefined-ret-addr.exp | 5 +++++ > gdb/testsuite/gdb.dwarf2/fission-base.exp | 5 +++++ > 2 files changed, 10 insertions(+) > > diff --git a/gdb/testsuite/gdb.dwarf2/dw2-undefined-ret-addr.exp > b/gdb/testsuite/gdb.dwarf2/dw2-undefined-ret-addr.exp > index 32ddaf4a..88765d4f 100644 > --- a/gdb/testsuite/gdb.dwarf2/dw2-undefined-ret-addr.exp > +++ b/gdb/testsuite/gdb.dwarf2/dw2-undefined-ret-addr.exp > @@ -30,6 +30,11 @@ if {![runto "stop_frame"]} { > return -1 > } > > +# If test is compiled with clang, GDB would display absolute path. > +# This command keeps output consistent across toolchains. > + > +gdb_test_no_output "set filename-display basename" > + > # stop_frame should be the outermost frame. > > # Check that backtrace shows only frame #0. > diff --git a/gdb/testsuite/gdb.dwarf2/fission-base.exp > b/gdb/testsuite/gdb.dwarf2/fission-base.exp > index 035fe731..d1abf6c9 100644 > --- a/gdb/testsuite/gdb.dwarf2/fission-base.exp > +++ b/gdb/testsuite/gdb.dwarf2/fission-base.exp > @@ -46,6 +46,11 @@ if {![runto_main]} { gdb_test "ptype main" "type = > int \\(\\)" > gdb_test "ptype func" "type = int \\(int\\)" > > +# If test is compiled with clang, GDB would display absolute path. > +# This command keeps output consistent across toolchains. > + > +gdb_test_no_output "set filename-display basename" > + > gdb_test "frame" "#0 *main \\(\\) at $testfile\\.c:$decimal.*" \ > "frame in main" > > -- > 2.43.0
diff --git a/gdb/testsuite/gdb.dwarf2/dw2-undefined-ret-addr.exp b/gdb/testsuite/gdb.dwarf2/dw2-undefined-ret-addr.exp index 32ddaf4a..88765d4f 100644 --- a/gdb/testsuite/gdb.dwarf2/dw2-undefined-ret-addr.exp +++ b/gdb/testsuite/gdb.dwarf2/dw2-undefined-ret-addr.exp @@ -30,6 +30,11 @@ if {![runto "stop_frame"]} { return -1 } +# If test is compiled with clang, GDB would display absolute path. +# This command keeps output consistent across toolchains. + +gdb_test_no_output "set filename-display basename" + # stop_frame should be the outermost frame. # Check that backtrace shows only frame #0. diff --git a/gdb/testsuite/gdb.dwarf2/fission-base.exp b/gdb/testsuite/gdb.dwarf2/fission-base.exp index 035fe731..d1abf6c9 100644 --- a/gdb/testsuite/gdb.dwarf2/fission-base.exp +++ b/gdb/testsuite/gdb.dwarf2/fission-base.exp @@ -46,6 +46,11 @@ if {![runto_main]} { gdb_test "ptype main" "type = int \\(\\)" gdb_test "ptype func" "type = int \\(int\\)" +# If test is compiled with clang, GDB would display absolute path. +# This command keeps output consistent across toolchains. + +gdb_test_no_output "set filename-display basename" + gdb_test "frame" "#0 *main \\(\\) at $testfile\\.c:$decimal.*" \ "frame in main"