From patchwork Thu Feb 28 12:52:15 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: LRN X-Patchwork-Id: 31685 Received: (qmail 27092 invoked by alias); 28 Feb 2019 12:52:30 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 26692 invoked by uid 89); 28 Feb 2019 12:52:30 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-22.6 required=5.0 tests=BAYES_00, BODY_8BITS, FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM, GARBLED_BODY, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, RCVD_IN_DNSWL_NONE, SPF_PASS autolearn=ham version=3.3.2 spammy=2017-02, 201702, H*RU:sk:broadba, Hx-spam-relays-external:sk:broadba X-HELO: mail-lf1-f68.google.com Received: from mail-lf1-f68.google.com (HELO mail-lf1-f68.google.com) (209.85.167.68) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 28 Feb 2019 12:52:28 +0000 Received: by mail-lf1-f68.google.com with SMTP id a8so9357105lfi.7 for ; Thu, 28 Feb 2019 04:52:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:autocrypt:subject:message-id:date:user-agent:mime-version; bh=8kIypNxvgHa8nmc38IMgEpfuSDmWKne8ppT6XrWM1H0=; b=UH1ezxWEkklpfOGwVq/WfpF64oLcj2rQupiAMfNq2xNsHa2h8Bc30jki+CjCWkieDz Y5wP5wP93JC4Vd7b2PDOFkp2xhSKVN3ashIWDIbueoYa/zlGwXbQduUSBMXblnV6yxDs g53txKLmmjrT6nXygLd9bpkBERDC2TveGajnPxdvPAzBgtCsunmS2nXd7l5LxD6q1FtT 6VH/ozpOvAAtgpsHapIakJQhAcdD7yynmTRkK9YSNPQ93xHbFgIE/st7SR8wJLdFZc8S DqO31z7uFM2pK2Pf7jt4bp3+cIWAxU3ymDL/FiV6/YL8T+Te0Ps4CoNhBPPSYsZS/TDu GA/w== Return-Path: Received: from [192.168.4.39] (broadband-95-84-200-6.ip.moscow.rt.ru. [95.84.200.6]) by smtp.gmail.com with ESMTPSA id e23sm4102582ljj.3.2019.02.28.04.52.23 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 28 Feb 2019 04:52:23 -0800 (PST) To: gdb-patches@sourceware.org From: LRN Subject: [PATCH] Apply substitute-path to relative filenames as well Message-ID: <5a785bba-7432-f6e0-1089-5d2bdd3450a3@gmail.com> Date: Thu, 28 Feb 2019 15:52:15 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 X-IsSubscribed: yes The patch is attached. The change itself is similar to https://www.sourceware.org/ml/gdb-patches/2017-02/msg00693.html , but the code is slightly cleaner (at the cost of making the patch larger). Also, as the patch is trivial, so i would expect it to not to require copyright assignment (i do have one, but David Grayson might not have). Here's the copy of the commit message: When source file path is relative to the build directory (which is considered a good practice and is enforced in certain buildsystems, such as meson), gdb only applies substitute-path to the build directory path. Then gdb appends the source file path to the rewritten build directory path, and tries to access that. This fails if either two of the following conditions are true: a) The user didn't specify substitute-path for the build directory. This is highly likely, since path substitution for build directories is not documented anywhere, and since gdb does not tell[0] the user the path to the build directory, just the source file path. b) The source file path changed. This can also easily happen, since a source path that is relative to the build directory can include any number of directory names that are not part of the program source tree (starting with the name of the root directory of the source tree). Gdb will not apply substitute-path to that relative path, thus there is no way for the user to tell gdb about these changes. This commit changes the code to apply substitute-path to all filenames, both relative and absolute. This way it is possible to do things like: set substitute-path ../foobar-1.0 /src/my/foobar-1.0 which is completely in line with the user expectations. This might break unusual cases where build directory path is also relative (is that even possible?) and happens to match the path to the source directory (i.e. happens to match a substitution rule). [0]: There's a "maintenance info symtabs" command that does show the names of the build directories, but normal users are not required to know or use that. --- gdb/source.c | 12 ++++-------- 1 file changed, 4 insertions(+), 8 deletions(-) gdb/ChangeLog: 2019-02-28 Руслан Ижбулатов * source.c (find_and_open_source): Apply substitute-path to all filenames, both absolute and relative From 28431cdf98ec6c606373fd02c36c5642c4f196df Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=D0=A0=D1=83=D1=81=D0=BB=D0=B0=D0=BD=20=D0=98=D0=B6=D0=B1?= =?UTF-8?q?=D1=83=D0=BB=D0=B0=D1=82=D0=BE=D0=B2?= Date: Thu, 28 Feb 2019 10:25:41 +0000 Subject: [PATCH] Apply substitute-path to relative filenames as well When source file path is relative to the build directory (which is considered a good practice and is enforced in certain buildsystems, such as meson), gdb only applies substitute-path to the build directory path. Then gdb appends the source file path to the rewritten build directory path, and tries to access that. This fails if either two of the following conditions are true: a) The user didn't specify substitute-path for the build directory. This is highly likely, since path substitution for build directories is not documented anywhere, and since gdb does not tell[0] the user the path to the build directory, just the source file path. b) The source file path changed. This can also easily happen, since a source path that is relative to the build directory can include any number of directory names that are not part of the program source tree (starting with the name of the root directory of the source tree). Gdb will not apply substitute-path to that relative path, thus there is no way for the user to tell gdb about these changes. This commit changes the code to apply substitute-path to all filenames, both relative and absolute. This way it is possible to do things like: set substitute-path ../foobar-1.0 /src/my/foobar-1.0 which is completely in line with the user expectations. This might break unusual cases where build directory path is also relative (is that even possible?) and happens to match the path to the source directory (i.e. happens to match a substitution rule). [0]: There's a "maintenance info symtabs" command that does show the names of the build directories, but normal users are not required to know or use that. --- gdb/source.c | 12 ++++-------- 1 file changed, 4 insertions(+), 8 deletions(-) diff --git a/gdb/source.c b/gdb/source.c index f99215f..673ebc3 100644 --- a/gdb/source.c +++ b/gdb/source.c @@ -1028,15 +1028,11 @@ find_and_open_source (const char *filename, } gdb::unique_xmalloc_ptr rewritten_filename; - if (IS_ABSOLUTE_PATH (filename)) - { - /* If filename is absolute path, try the source path - substitution on it. */ - rewritten_filename = rewrite_source_path (filename); - if (rewritten_filename != NULL) - filename = rewritten_filename.get (); - } + rewritten_filename = rewrite_source_path (filename); + + if (rewritten_filename != NULL) + filename = rewritten_filename.get (); result = openp (path, OPF_SEARCH_IN_PATH | OPF_RETURN_REALPATH, filename, OPEN_MODE, fullname);