From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6763 invoked by alias); 14 Sep 2019 15:28:54 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 6755 invoked by uid 89); 14 Sep 2019 15:28:54 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-14.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=possibility X-HELO: mail-qt1-f178.google.com Received: from mail-qt1-f178.google.com (HELO mail-qt1-f178.google.com) (209.85.160.178) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 14 Sep 2019 15:28:52 +0000 Received: by mail-qt1-f178.google.com with SMTP id m15so1598027qtq.2 for ; Sat, 14 Sep 2019 08:28:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=embecosm.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=PyXUCqOJ4eH6efNo25z9+B2/g0L0CUqYaxLvQNjKTHk=; b=VyOzKntcmo3qfUvl6eL7g/ZZiXZAleGRrUr12wqE64G/xHS5fcNfpRTUcsxDXOuGJM fJZP9D5o3hzjUu8EMcqrG9DLQz9sHwzG/4HtNPoGXH2a/r21ZuFI5hkn1GG8aKVKXeyX vAyOHLiIoj+YTXyBv9EsL9nOOXjjKg3nnRnWXi+41VoVLp/91lAxbnvPbkDfCnVQV+Yd zrj3sxvhjOJTssC0NxhyztdD368mDSBuY5P4+2U4DSem5Z5C2YBvnaVUv8BmuVDstnTn DZjkQ4eAZYhuKbtHx3IEOn4V5UpR3ew/xAcI01Ot+4EGmQ5mWDvWdXxduNMYjm4M2kH2 EIMQ== Return-Path: Received: from localhost ([198.168.27.218]) by smtp.gmail.com with ESMTPSA id v23sm1771424qto.89.2019.09.14.08.28.48 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sat, 14 Sep 2019 08:28:48 -0700 (PDT) Date: Sat, 14 Sep 2019 15:28:00 -0000 From: Andrew Burgess To: Eli Zaretskii Cc: mgulick@mathworks.com, gdb-patches@sourceware.org Subject: Re: [RFC] Apply compilation dir to source_path lookup Message-ID: <20190914152847.GY6076@embecosm.com> References: <8058b501-9020-84f1-ecf4-b46bfe3b86e3@mathworks.com> <20190907235059.GN6076@embecosm.com> <4d9f4c81-8580-2b42-a434-389ed7655d7f@mathworks.com> <20190913013851.GT6076@embecosm.com> <835zlw1z45.fsf@gnu.org> <834l1g1wp7.fsf@gnu.org> <20190913224535.GX6076@embecosm.com> <83r24jz7q4.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <83r24jz7q4.fsf@gnu.org> X-Fortune: It's lucky you're going so slowly, because you're going in the wrong direction. X-Editor: GNU Emacs [ http://www.gnu.org/software/emacs ] User-Agent: Mutt/1.9.2 (2017-12-15) X-IsSubscribed: yes X-SW-Source: 2019-09/txt/msg00254.txt.bz2 * Eli Zaretskii [2019-09-14 09:56:35 +0300]: > > Date: Fri, 13 Sep 2019 18:45:35 -0400 > > From: Andrew Burgess > > Cc: mgulick@mathworks.com, gdb-patches@sourceware.org > > > > > Btw, do the "prepend" and "append", as implemented, take care to DTRT > > > with Windows drive letters at the beginning of absolute file names? A > > > literal prepending or appending will do the wrong thing there. > > > > Gah! > > > > Looking at the implementation of 'openp' (in source.c) I see this > > code: > > > > /* For dos paths, d:/foo -> /foo, and d:foo -> foo. */ > > if (HAS_DRIVE_SPEC (string)) > > string = STRIP_DRIVE_SPEC (string); > > > > which just seems to throw out the drive spec, and I can't find any > > code that adds it back in. Is that going to do the right thing? > > I'm not sure we are talking about the same thing. My concern is > specifically this use case mentioned in your description: > > SEARCH_PATH/COMP_DIR/FILENAME > > What will happen here if both SEARCH_PATH and COMP_DIR are absolute > file names (which on Windows means they have drive letters)? AFAIU on > Unix you will concatenate them, so we need some kind of > "concatenation" on Windows as well, but that means one of the drive > letters should "win". Which drive letter wins in this case, and will > the result make sense from the user perspective? If we get as far trying this merge then the drive letter on COMP_DIR will be removed and we use whatever is on SEARCH_PATH. This is exactly the same as what we've always done if FILENAME is itself absolute. The code I pointed out above that last night I didn't understand now makes perfect sense. If we have: DW_AT_name: c:/project/foo.c DW_AT_comp_dir: d:/project/build/ And if the directory search path is: g:/mnt/project;$cdir;$cwd And the current directory is: h:/home/ Then this is what I think the search order will be: c:/project/foo.c g:/mnt/project/project/foo.c d:/project/build/project/foo.c h:/home/project/foo.c d:/project/build/project/foo.c g:/mnt/project/project/build/project/foo.c d:/project/build/project/build/project/foo.c h:/home/project/build/project/foo.c g:/mnt/project/foo.c d:/project/build/foo.c h:/home/foo.c The first and third block is what we currently (pre-patch) do, and the second block is what I think the patch should provide after Mike's last suggested update. > > It is clear to me that if FILENAME is absolute, we don't use any of > the directories to locate it, neither on Unix nor on Windows. Right? Well.... if FILENAME is absolute then that will get tried first, which for most developers will work fine. But we also want to support the possibility that people might relocate the source tree into source other location. So if you compile /project/foo-1.0/f1.c the DW_AT_name will be that absolute path, if you then moved that source tree into: '~/.debug-cache/foo/project/foo-1.0/f1.c' we still want to allow that to be found which requires prefixing the absolute path with a directory. I guess on Windows if the absolute file path include a 'c:' prefix, but you relocated the source into a location below 'd:' then you want the 'c:' prefix stripped off, which is what would happen at the moment, so I think all is good. Thanks, Andrew