From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 109683 invoked by alias); 13 Sep 2019 22:45:40 -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 109674 invoked by uid 89); 13 Sep 2019 22:45:40 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-13.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy= X-HELO: mail-qt1-f180.google.com Received: from mail-qt1-f180.google.com (HELO mail-qt1-f180.google.com) (209.85.160.180) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 13 Sep 2019 22:45:39 +0000 Received: by mail-qt1-f180.google.com with SMTP id g16so2255854qto.9 for ; Fri, 13 Sep 2019 15:45:38 -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=dQwmXmXEgBkSClNI1mi5yj/frQaL/HJBepJmUNXcHoo=; b=dHvv1oSfLHgytNhdeIZOdOhhUoxhzBMWqlknosag+Kgb91Q+iRR+HDUAYA2YJLMe0c yP2QE2d8/hlXFwLKP6agX38w56kimZExjG9ToLjoHg7AnNYTWO43DJ2A80F88XwZ5Hc3 fuEdYwsp13aZUpoGQmrUz1FXUhOsf6RjR+yxzi/W2x+MVedGGBt0+DjLMfUBrPQyPOX6 FK71EXFb3D3H39HHns2fzx89Ez5u/Iqfwknq40xv5TOq8cnU/7+rzq9zZAI5hRoHTyV9 kBwLjzFjdIkF9hh5kcY/Abb5lC5UYEWCs3dudkfUfmLQpiW+6TpdNy2jhIy/4RFy+8/G zx2w== Return-Path: Received: from localhost ([207.253.95.5]) by smtp.gmail.com with ESMTPSA id e5sm17395466qtk.35.2019.09.13.15.45.36 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 13 Sep 2019 15:45:36 -0700 (PDT) Date: Fri, 13 Sep 2019 22:45: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: <20190913224535.GX6076@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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <834l1g1wp7.fsf@gnu.org> X-Fortune: routing problems on the neural net 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/msg00247.txt.bz2 * Eli Zaretskii [2019-09-13 10:28:52 +0300]: > > Date: Fri, 13 Sep 2019 09:36:42 +0300 > > From: Eli Zaretskii > > CC: mgulick@mathworks.com, gdb-patches@sourceware.org > > > > > @value{GDBN} will also append the compilation > > > +directory to the filename and check this against all other entries in > > > +the source path. > > > > I think "append" here is a mistake. Should it be "prepend"? And > > anyway, doesn't this simply repeat what was described in the text > > above? > > 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 did consider only creating the COMP_DIR/FILENAME combination if FILENAME was not absolute, but I worried that this might be unnecessarily restrictive, but now I'm tempted to say that would solve this problem, and we should just wait until someone comes up with an example where that is not good enough, before we figure out how to allow it... Thanks, Andrew