From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailrelay.tu-berlin.de (mailrelay.tu-berlin.de [130.149.7.70]) by sourceware.org (Postfix) with ESMTPS id B747F3858C24 for ; Fri, 5 Apr 2024 05:58:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B747F3858C24 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=campus.tu-berlin.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=campus.tu-berlin.de ARC-Filter: OpenARC Filter v1.0.0 sourceware.org B747F3858C24 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=130.149.7.70 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712296720; cv=none; b=NLCYsIsCmSmv8W6gatryj1byv6XToSWC2tzg1X/zpNDasQSrNROYfHRsippOK5FwZezZ14CNa4E5O/6+ACS148eiX5zNOguktLvupBh0CL3WC5QUT3bqWuxP1ssN4/R7GCDHXy6PQR4R1WrkLPVckXRd77/ZwYTX3MAiVPxHECQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712296720; c=relaxed/simple; bh=dyKGVGMDfhlKcBiYCMaF6E4ovMF8b01KXHb2eByyM+A=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:From:To; b=gSyohbXDgvbgd4v3s3JMGAbFI5qzUTqALMxlXdoCoOuLYwXoxolN1WcN6DZMT/+3/p4ntL8HvFxL43TuK7Nzc4qg32JQZF1jQ79gDpmkbJuPd9xvEGUy1afETmh0T3rf+ARzKEXpTErkOwPPnehm2fkYUdQEQgjWq4ULtHs4XWc= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tu-berlin.de; l=2126; s=dkim-tub; t=1712296718; h=message-id:date:mime-version:subject:from:to:cc: references:in-reply-to:content-transfer-encoding; bh=GVlr9MdCl10wFAz3CqoLww35t1Y31cHp6VBALILb4vM=; b=bvxNvvAIYxF9Z6FSJllyxP+RAoj+PXbFdbPk9VGOGfXU82BLLDrafKX4 RQXkxj6TffhhkWoPWr9LDA/CXgs7p8H2tWxYKTSJe/ymZQ/3o714qPbHc nDQXe84u1cGSPIQG0HTLeavCovLRmAjaCJydjmg52irEhJ8ztXEqauGSZ M=; X-CSE-ConnectionGUID: BkbsBpU+Q/SZqlzuyg9Etw== X-CSE-MsgGUID: 6nz+5iJOQES6XpFy25xg1g== X-IronPort-AV: E=Sophos;i="6.07,180,1708383600"; d="scan'208";a="7324260" Received: from bulkmail.tu-berlin.de (HELO mail.tu-berlin.de) ([141.23.12.143]) by mailrelay.tu-berlin.de with ESMTP; 05 Apr 2024 07:58:37 +0200 Message-ID: <7ef1913e-c578-4416-bf2a-162588bb24e8@campus.tu-berlin.de> Date: Fri, 5 Apr 2024 07:58:08 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] Add wildcard matching to substitute-path rules From: Max Yvon Zimmermann To: Guinevere Larsen , Eli Zaretskii CC: References: <5ff720ec-4453-441e-ba82-84d60a2e8d50@campus.tu-berlin.de> <86o7as9ecf.fsf@gnu.org> <7eb59d60-1092-4b68-b019-d145d8fe8ab1@campus.tu-berlin.de> <867chd8yh6.fsf@gnu.org> <86zfu973b1.fsf@gnu.org> <845a6a0f-6a7d-4b75-84b8-6dd2d33ea0e3@redhat.com> <58bcd451-6cec-4f11-9428-79d9b3037e88@campus.tu-berlin.de> Content-Language: en-US In-Reply-To: <58bcd451-6cec-4f11-9428-79d9b3037e88@campus.tu-berlin.de> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Sorry, I need to make a correction. This topic can be a bit more confusing at times than I initially thought. >>> Also, in the example I stated in my last reply, no file name that matches '/foo/include' would ever match '/bar/include'. The point I was trying to get across was that two unrelated files can already be mapped onto the same file (accidentally). >> >> Well, two wrongs don't make a right. > > This is a very fair point. Having different files map to the same file in the local source directory could be annoying. > Because this isn't a new issue per se, I thought about implementing a separate patch that would warn the user if two different files get mapped onto the same source file. > But after some thought I realized that there are actually valid use-cases for this multi-mapping. > > Let's say we have the following directory structure: > > /inc.h > /foo.c > /dir/bar.c > > '/foo.c' includes '/inc.h' via #include "inc.h". > '/dir/bar.c' includes '/inc.h' via #include "../inc.h" > > With GCC this will result in two entries in the debug info: '/inc.h' and '/dir/../inc.h'. > For GDB these entries are two separate files. (Maybe this could changed with another patch though) > But with the help of the following two rules we can tell GDB to treat them the same: > > set substitute-path /from /to > set substitute-path /from/dir/../ /to > > I therefore don't know if multi-mapping should be considered wrong here. > Also I don't think that glob matching would make this more common due to the aforementioned direction of the mapping. > For me, this is a completely separate issue. The rule set substitute-path /from/dir/../ /to would actually never match because '/dir/../inc.h' (inside '/from') would also match '/from' which is defined first. Also you could make the case that this is not really a multi-mapping, because '/inc.h' and '/dir/../inc.h' are, of course, the same file. But it makes implementing a usable warning more tedious. Maybe a warning to the user is actually the right solution here but I'm not entirely sure. What are your thoughts on this?