From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 85790 invoked by alias); 17 Sep 2019 20:22:28 -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 85777 invoked by uid 89); 17 Sep 2019 20:22:28 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-26.2 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=HOME, sk:STRIP_D, HAS_DRIVE_SPEC, sk:strip_d X-HELO: mail-qk1-f176.google.com Received: from mail-qk1-f176.google.com (HELO mail-qk1-f176.google.com) (209.85.222.176) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 17 Sep 2019 20:22:26 +0000 Received: by mail-qk1-f176.google.com with SMTP id x134so5502126qkb.0 for ; Tue, 17 Sep 2019 13:22:26 -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=Wv/TwTHhRa23PpsHOcYCvD9F2wPPfccR2fwyyAVvkd8=; b=R7381mxCw10r4CKE9xtBdHquapaMAWNrbggAOhazke7Jm/TjPRe2UeN/eN3MJ6/O+s pIB+a+gycbrH4iWrM2V6bO9+a330M4Rjq+KVTIgawjb23LZwXv/CREEubXkI7j9x0HcP gRqjB8pr7yY5VG1r7P86QVX/SeAHxZoVUDW84YJ5oYIusX5HXU+lDBnSPvbBMkR7aYlT BojRNuie+eJ6lX7cpAj2Cche5qdVmSWPjR75fD76YcxB05zZ54Y6lUw6uJCSMMOiKTNx IcLxS5URg6LFFfrTP4e02YDlukxl7jc98ATqo/nzwzUVlM87YWhTPRvdxRR4u7FcxuBT Z1Rw== Return-Path: Received: from localhost ([172.110.70.5]) by smtp.gmail.com with ESMTPSA id q64sm1572176qkb.32.2019.09.17.13.22.23 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 17 Sep 2019 13:22:24 -0700 (PDT) Date: Tue, 17 Sep 2019 20:22:00 -0000 From: Andrew Burgess To: Mike Gulick Cc: Eli Zaretskii , "gdb-patches@sourceware.org" Subject: Re: [RFC] Apply compilation dir to source_path lookup Message-ID: <20190917202222.GA4962@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> <82898bf2-3928-85a4-4f5f-cc9e194dd2a8@mathworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <82898bf2-3928-85a4-4f5f-cc9e194dd2a8@mathworks.com> X-Fortune: Factorials were someone's attempt to make math LOOK exciting. 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/msg00328.txt.bz2 Mike, Thanks for your feedback. I incorporated your suggested changes and pushed this to master. Thanks, Andrew * Mike Gulick [2019-09-13 22:52:19 +0000]: > On 9/13/19 6:45 PM, Andrew Burgess wrote: > > * 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. > > You beat me to a response, but here's what I was going to say: > > The only way this would be a problem is if both the compilation > directory and the source file contained a drive letter. I had assumed > that if the debug information contained a compilation directory, then > the file path would be relative to that. GCC at least seems to behave > this way. > > [mgulick@mgulick-deb9-64:~/test/src] ... > $ gcc -g -o test.o -fdebug-prefix-map=$HOME= -c test.c > [mgulick@mgulick-deb9-64:~/test/src] ... > $ dwarfdump test.o > ... > DW_AT_name test.c > DW_AT_comp_dir /test/src > ... > > [mgulick@mgulick-deb9-64:~/test/src] ... > $ gcc -g -o test.o -fdebug-prefix-map=$HOME= -c `pwd`/test.c > [mgulick@mgulick-deb9-64:~/test/src] ... > $ dwarfdump test.o > ... > DW_AT_name /test/src/test.c > ... > > In this case there is no DW_AT_comp_dir present. > > If you are concerned about this (possibly some crazy compiler emitting > strange dwarf), the following change should suffice: > > diff --git a/gdb/source.c b/gdb/source.c > index 1635563b20..3fd05a06f2 100644 > --- a/gdb/source.c > +++ b/gdb/source.c > @@ -1049,8 +1049,12 @@ find_and_open_source (const char *filename, > cdir_filename.pop_back (); > /* Add our own directory separator. */ > cdir_filename.append (SLASH_STRING); > - /* Append filename, without any leading directory separators. */ > + /* Append filename, without any leading directory separators or drive > + names. */ > const char * filename_start = filename; > + /* For dos paths, d:/foo -> /foo, and d:foo -> foo. */ > + if (HAS_DRIVE_SPEC (filename_start)) > + filename_start = STRIP_DRIVE_SPEC (filename_start); > while (IS_DIR_SEPARATOR (filename_start[0])) > filename_start++; > cdir_filename.append (filename_start); > > > > > 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... > > This also seems fine to me. If FILENAME is absolute, there shouldn't be > a compilation directory. > > > > > Thanks, > > Andrew > > > > Thanks, > Mike >