| Message ID | 20260325163234.3377436-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 15D634BB3BFB for <patchwork@sourceware.org>; Wed, 25 Mar 2026 16:34:35 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 15D634BB3BFB 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=4tL+buJB X-Original-To: gdb-patches@sourceware.org Delivered-To: gdb-patches@sourceware.org Received: from CY7PR03CU001.outbound.protection.outlook.com (mail-westcentralusazlp170100005.outbound.protection.outlook.com [IPv6:2a01:111:f403:c112::5]) by sourceware.org (Postfix) with ESMTPS id A0A0D4BAD146 for <gdb-patches@sourceware.org>; Wed, 25 Mar 2026 16:34:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A0A0D4BAD146 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 A0A0D4BAD146 Authentication-Results: server2.sourceware.org; arc=pass smtp.remote-ip=2a01:111:f403:c112::5 ARC-Seal: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1774456441; cv=pass; b=FTLT2pwLiqDTescqUogszLEGDyTMJ4IsQ5wkWoqSVHATv0KfngWuo0+rUKdHJRQodcBkQaLPlEOYWIB90verZ8PBEOsAHRFlosfogQe127cr9kooZUhwjau2RI5hIioJkJfB/8cXdFKcQ7ZOfpPrbhzS+1YBR59sOMa0bRd2G28= ARC-Message-Signature: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1774456441; c=relaxed/simple; bh=vxpL7clLHdC/MFNZ1uRyGchNTRq8ga40EAT6lr1JZj4=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=gFEacvT2IuHBY756CRTNGhim1ozimQ9TOqiQ+f38rzsJeaoa3/v2tC1XkIyV0XHRv8NvHYPQqzuJCowdPKh4+BHLOyTmAdRl5gdbqIn5q6ZFtimqPqaif66e7Da1G04UPfcnOiyZO5HSDxFMB1s7hxEPEVZcKGfAxGeO/7Z2fDQ= ARC-Authentication-Results: i=2; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A0A0D4BAD146 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=rG+mQsnYZIG2QsVjXJXgQQMUWOxkuBt4/npx8/fzJXzftkngfmul4I4tyyQQddU1jE42991OTjIHtU72g5RZfOU7iQMY2k7Fu7D9VMP+VyHIBqiTel7xV6NeLJFIgjp7ytPHxKt/ih3jV2cY+QLIGDAYCi2NGS6yAmP3Z23eRnEOGbhIsJu6+ko2On+NoLfV+/MLlEk826DogE3vKRJm0wK11tAEjB9g+q2Hue9xel29MFmRhwJHCVi01X2G/HO606tuJfYCGHwIUJLbuCSmq84yzZ+vRK/rsYbOM6orZZPRgQ3c4lR7i2fhxbypj410yosTwKhKAjdS8Zt1EEN1PQ== 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=HVEseArEDIgNZALglHAO5sH/VrLiiRidedbsoQ2b5Ks=; b=XorTDodOJUWJj7W4i26yuctwgc/lgcAfr2kz5IQiDG9/liFgELFYWDxcFGiUHU17Bob77Qost7nZgdfOzMBmjLMXkxs2LF/8A+F3AF53i6/o+EmIKUU5ZYuX2KMXvb436/UAuB4aZK/tW8VsAFNPeT901Q3a1YYRqp6kbAEcFa/Nu45Jp5xjbwizFsjRD8rKLU6zBCpuzXbKhVhusOWxXaHnXNWDFDn+TKREr001gQzdTxm1SyHn/Cx/XFj+0AT8p5nEgRytszVrnJo66R7dLw9YyxLOqbHT3pnRdAlsY1EB3Kznk+55QKONLRMxUHSUPkuB60rbldBMT16EmvVRmw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=sourceware.org 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=HVEseArEDIgNZALglHAO5sH/VrLiiRidedbsoQ2b5Ks=; b=4tL+buJBu7oQNUK1fwUu08BzSP4xhnhcIb0OdyPisT0Ued/qkBmcbQo8GWsq++nmVSsEw06reWaaPKg2xfHVnpHcg780hRUvol7BHUgfBd7hXAyDp3lDDz0iBn/4yjoHFI6hewlXbzF2ccZL6ADGBZdYGpXfFyY6anRPpBEJdcM= Received: from SJ0PR05CA0038.namprd05.prod.outlook.com (2603:10b6:a03:33f::13) by MW6PR12MB8900.namprd12.prod.outlook.com (2603:10b6:303:244::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9745.15; Wed, 25 Mar 2026 16:33:52 +0000 Received: from SJ1PEPF00002316.namprd03.prod.outlook.com (2603:10b6:a03:33f:cafe::1a) by SJ0PR05CA0038.outlook.office365.com (2603:10b6:a03:33f::13) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9745.20 via Frontend Transport; Wed, 25 Mar 2026 16:33:52 +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 SJ1PEPF00002316.mail.protection.outlook.com (10.167.242.170) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9745.21 via Frontend Transport; Wed, 25 Mar 2026 16:33:52 +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; Wed, 25 Mar 2026 11:33:50 -0500 From: Bratislav Filipovic <bfilipov@amd.com> To: <gdb-patches@sourceware.org> CC: <simon.marchi@efficios.com>, Bratislav Filipovic <bfilipov@amd.com> Subject: [PATCH] test: basename filenames in dwarf2 frame checks Date: Wed, 25 Mar 2026 22:02:24 +0530 Message-ID: <20260325163234.3377436-1-bfilipov@amd.com> X-Mailer: git-send-email 2.43.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [10.180.168.240] X-ClientProxiedBy: satlexmb08.amd.com (10.181.42.217) To satlexmb07.amd.com (10.181.42.216) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SJ1PEPF00002316:EE_|MW6PR12MB8900:EE_ X-MS-Office365-Filtering-Correlation-Id: e72c45ef-67ed-43f1-2776-08de8a8c4d06 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; ARA:13230040|36860700016|1800799024|82310400026|376014|18002099003|56012099003; X-Microsoft-Antispam-Message-Info: ItdE17DnoKrrQgnP/kewBRYbQw0p8uujH/76KREgrfCaOPBQAPXVfAwDFTepwst1Gl9Rt4cwxmMcfGjsyJLgnh+Cbx9+4/m3hksY32W5Lk6vNRbtllqwy1m4pbPgR8w+EbaPKsvUwflO3jH51LW9t3hQi2ZZUg28c6ZWbCrbV5/uljLfHt85B+T/SeuoAARfneAohzBO5EHyDxgKBREXGPCdTddRljKiJQR35hhymmD2p+oqXd104tApN1bIqujkk12d2GY/IvTUfPaJFvmxMxBDHFgdG/4t6wOGqz4z19BUFFIem1wlMJnl+j5PR8uHxUyK20nrfL8AZP9ls5Qq6y6D+ZwrYaujQy/T+W6j8CrCujcMqiUJ/Ll5wRLsy0A4T4d6ujA+AGdDsZ1RyHgI278+dDyO0rCwKXPDgQBW5GAKLTz/71zDUAuNMNJT1Yp8gaySoxyRnMovlKoHD2Lworz5QrLI2sVdF2A/eKdBCIBo0So0lVGr8u4tyoVIVfHJZX7NVtVvoV3Vydqcd27RH1d72uKqjVi6osNJcmKqu5h4q1rtJQJI66jSFgT9oGWXEsvCjDEiTaCBmheWuXSo9ADrah8RxhkXLPOzoqDbUqbDQnW1IKEKpnnEgxUcERpC/4qxYJxiwMsB2nR/BD6p0J1DOTjK1zLDdvY+0uhVQFDTdkWhhd0Mbnngd3d7d1/B2oMoc+rUzhoWr2DRXLi72MMzYCS3oOTL5jIOIR/gM4XpawVgaOv80hQ8qiwywkGcfowyXaNZ5l/dpS3YZPC85A== 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)(36860700016)(1800799024)(82310400026)(376014)(18002099003)(56012099003); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: 22YyuW/aPl3REjXFCO6igb3x/AwvmaefOTc5Xp+9Wasyk/TClc8qH3LG0fE9Fgy5RWk5pSyq/y8wNePHoRrmIWRsBgy0qGqsEY68MH3P1Jmv/JU5JT6qvTPdeqjmj0cpF9uPH+oHOEidCKMpY8ytlhY3WRnTNgxq1sXN+jkUXARbzE6tE6NvumkPhs4G8Z2THP48dPtIHMbSFlODaB4+IOSewdjQNYZG9LLFpjGbmv31K6whUVIsPbdvnpOvhUBqSsuBsf/pV8qqk9c01PHWTdyY3H0+4UxnXmN0YsippYzfTF/SeW7JsdYfYdhu+o4Q2F2gse1UbEiGlnoe9CgNna0+crGXC/HjRV6qiToPWj1BKuvm00B0zn+kFlEqx3Il7cdupY+5FDh/+UD11AolYlqDo1frmeF4UXvDFaT34aL/V6pFYe9iAZJ4XQyUHrmF X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Mar 2026 16:33:52.4082 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: e72c45ef-67ed-43f1-2776-08de8a8c4d06 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: SJ1PEPF00002316.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW6PR12MB8900 X-Spam-Status: No, score=-8.8 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_BLOCKED, 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-aarch64 | success | Build passed |
| linaro-tcwg-bot/tcwg_gdb_build--master-arm | success | Build passed |
| linaro-tcwg-bot/tcwg_gdb_check--master-arm | success | Test passed |
| linaro-tcwg-bot/tcwg_gdb_check--master-aarch64 | success | Test passed |
Commit Message
Bratislav Filipovic
March 25, 2026, 4:32 p.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)
---
gdb/testsuite/gdb.dwarf2/dw2-undefined-ret-addr.exp | 5 +++++
gdb/testsuite/gdb.dwarf2/fission-base.exp | 5 +++++
2 files changed, 10 insertions(+)
Comments
[AMD Official Use Only - AMD Internal Distribution Only]
PING
Can someone take a look at this?
Regards Bratislav
-----Original Message-----
From: Filipovic, Bratislav <Bratislav.Filipovic@amd.com>
Sent: Wednesday, March 25, 2026 5:32 PM
To: gdb-patches@sourceware.org
Cc: simon.marchi@efficios.com; Filipovic, Bratislav <Bratislav.Filipovic@amd.com>
Subject: [PATCH] test: basename filenames in dwarf2 frame checks
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)
---
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..5b47c84c 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..a73cab48 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
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. Thanks for taking a look at this, it's always nice to see tests being improved like this. This is fine, with two minor nits fixed... > > diff --git a/gdb/testsuite/gdb.dwarf2/dw2-undefined-ret-addr.exp b/gdb/testsuite/gdb.dwarf2/dw2-undefined-ret-addr.exp > index 32ddaf4a..5b47c84c 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. This comment needs to be one complete sentence (add a comma after 'path', and change 'This' to 'this'), or two sentences (add a full stop after 'path'). > + > +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..a73cab48 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. Same issue here. With both of those fixed: Approved-By: Andrew Burgess <aburgess@redhat.com> thanks, Andrew
diff --git a/gdb/testsuite/gdb.dwarf2/dw2-undefined-ret-addr.exp b/gdb/testsuite/gdb.dwarf2/dw2-undefined-ret-addr.exp index 32ddaf4a..5b47c84c 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..a73cab48 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"