From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 6BE843858C98 for ; Thu, 4 Apr 2024 12:42:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 6BE843858C98 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 6BE843858C98 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712234556; cv=none; b=uprPq/j0RQqyOzk+byTXAdnuo/vI6ojNOVQzq+4S0bQua1vqlbFSyYTxVjIicYUYx0Unzr6aPL9qKtjmcWOOkaPT/0j94mB2na5dnukJPiMaDhD62odEQEOxZps+XRIe/07lrBt3981Q8VPrNATWIoXbxfiTJmlPH2+b0hSbX1I= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712234556; c=relaxed/simple; bh=u5YIzJDwduGTSjbH6s7ZEFuIOzuExolIGdaSbdXoj/M=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=qslaTuq60EFDXEBKcu9H9m2ECno2NgO59LS2dI7Uo9oKxCIKeyj7SeNQH5o57KPylTkT1c9uVIaN+AtgTyD8pLZYEnwiSC13vZTFt+WuBBoNESD7lFrkmYpNkaPh3mLSl50WlzRsmTqnD31wGsepRYlBlbm6os83D/JLbBdN8s8= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1712234554; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=GECsTg+KZa8Bq7LkH3JLBz374P/bJ5u3dxbgqm/w0YY=; b=OiLyAYQmqn5tien5ZGzhoHx1ZSj3qLUo4TI3WIlCwuZcMXMlepHVw9f22tJqV7Zs0WVAwF IziTGpo9v/F6LcIzg0lDpL/thG2DHpY9H4AcOd/SmzjzzZj8pTRcpwrrMTYhGWrKIvbXS1 IjbpNBOzBToVoUtsivj1FnxkD/mJT8c= Received: from mail-qk1-f198.google.com (mail-qk1-f198.google.com [209.85.222.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-531-9NoWmlEcMiuByQkYegj_3A-1; Thu, 04 Apr 2024 08:42:32 -0400 X-MC-Unique: 9NoWmlEcMiuByQkYegj_3A-1 Received: by mail-qk1-f198.google.com with SMTP id af79cd13be357-78c6a3ff9bcso161856285a.0 for ; Thu, 04 Apr 2024 05:42:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712234551; x=1712839351; h=in-reply-to:from:content-language:references:cc:to:subject :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=GECsTg+KZa8Bq7LkH3JLBz374P/bJ5u3dxbgqm/w0YY=; b=X20+H0qCIwiKMGTJYWCpG6TZK3keSQp1yEsxkE2Lf36H0mDuZ4sUtpd0vePVVzHnvi hjgdvmhH7+sP4f+dc/idXsKTBVk9ta69uK1auBwWaKeZiC6HETShdmmV26tmNrKrP44Q aonE1J4I+WfOqzGeyfDQYLcRp9M4nyRghR3Axu6i7ADXXPuxKKX5u8bTLn8NZDmxbO3b 0uofJ8/iJsTkqlWCqjllec5Qeeiia1yW7sJ8e7GdvoH0VoTQbBqq+7kk8NDo2P9jjn8R vnuk/gI7KyQVCVidZxnB7sM+EmBkctg8pvC4GqNFLVZG6itDYRJJUcEkwoeCC8ZRk8AU JLGg== X-Gm-Message-State: AOJu0YwarNsPmu5RvfNRJ/SKYQkj1/sYJn1DPAgLa1xDCNnOqaCEXLXt 1kkGA51BUt2wQeJwjHxCqLTXACplhuLKNZcJlzAmVBzGUNgHgNEJ8EKJy4OtZehIliaSPxTuFmP 0klwIdjpkh/53Lif7IUBmnlsg8vDjLveC92wYSwnK/itX8Ip736ZeG45IhkjfaBOr4vV6tw== X-Received: by 2002:a05:620a:4610:b0:78d:46af:73f9 with SMTP id br16-20020a05620a461000b0078d46af73f9mr20534qkb.7.1712234551584; Thu, 04 Apr 2024 05:42:31 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFvR3B+JEOoS0G9x1jWmk84MeOGMwuJh1pP8vHg6k3MgOCVuMtKTYolCXNoh4JmPu0c+KBSLw== X-Received: by 2002:a05:620a:4610:b0:78d:46af:73f9 with SMTP id br16-20020a05620a461000b0078d46af73f9mr20505qkb.7.1712234551141; Thu, 04 Apr 2024 05:42:31 -0700 (PDT) Received: from ?IPV6:2804:14d:8084:92c5::1002? ([2804:14d:8084:92c5::1002]) by smtp.gmail.com with ESMTPSA id q12-20020a05620a038c00b0078d39df6f73sm1108274qkm.70.2024.04.04.05.42.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 04 Apr 2024 05:42:30 -0700 (PDT) Message-ID: <845a6a0f-6a7d-4b75-84b8-6dd2d33ea0e3@redhat.com> Date: Thu, 4 Apr 2024 09:42:27 -0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] Add wildcard matching to substitute-path rules To: Eli Zaretskii , Max Yvon Zimmermann Cc: gdb-patches@sourceware.org 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> From: Guinevere Larsen In-Reply-To: <86zfu973b1.fsf@gnu.org> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: multipart/alternative; boundary="------------RwMrM5P0ApC5lGQLC2VuopHs" Content-Language: en-US X-Spam-Status: No, score=-5.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,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: This is a multi-part message in MIME format. --------------RwMrM5P0ApC5lGQLC2VuopHs Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 4/4/24 08:52, Eli Zaretskii wrote: >>> To me, this means that the two-line example you've shown is processed >>> in a predictable way, by only using the first one if both match, >>> whereas a wildcard rule will cause unpredictable results, because the >>> order in which files are compared against a wildcard is undefined. >>> Right? >> No, rules that use wildcards are still processed in a predictable way. If we set the following two rules (and in that order!): >> >> set substitute-path /foo/include /path/to/foo >> set substitute-path /*/include /path/to/somewhere >> >> Then any file names matching '/foo/include' would be rewritten to '/path/to/foo' and NOT '/path/to/somewhere'. Even though any file name matching '/foo/include' would of course also match '/*/include'. The rule selection is entirely based on the order of their definition. > That's not what I meant. I meant that a rule like > > set substitute-path /*/include /path/to/somewhere > > can catch any parent directory of 'include', and which one it will > catch is not known in advance. This was something I was also wondering about. taking from the original example: Max> In the case of conan (https://conan.io/) the path will consist of some constant part and some directory named with some hash value (i.e., /path/to//builddir/) Suppose there are 2 builds for this package, so we have the following valid directories: /path/to/deadbeef/builddir /path/to/00000000/builddir which of those will be chosen? Is it consistent across gdb runs? OSs? How can a user know in advance which will be picked? > >> 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). The difference I see is that in the previous examples, the problem is apparent within what the user would expect (some GDB script, debug information, or other things related to their project), whereas with glob matching, the problem may be unrelated (directory structure of unrelated folders). If I wasn't aware of this patch, I would never think to check if the folder structure of my system could be the problem for getting debug information. > Well, two wrongs don't make a right. > > I'd be interested to hear opinions of others about this. -- Cheers, Guinevere Larsen She/Her/Hers --------------RwMrM5P0ApC5lGQLC2VuopHs--