From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 87665 invoked by alias); 14 Sep 2019 07:11:50 -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 87655 invoked by uid 89); 14 Sep 2019 07:11:49 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-3.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 spammy=letter X-HELO: eggs.gnu.org Received: from eggs.gnu.org (HELO eggs.gnu.org) (209.51.188.92) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 14 Sep 2019 07:11:47 +0000 Received: from fencepost.gnu.org ([2001:470:142:3::e]:48447) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1i92Dh-0008OU-Mv; Sat, 14 Sep 2019 03:11:45 -0400 Received: from [176.228.60.248] (port=1997 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1i92Dh-0003QD-5y; Sat, 14 Sep 2019 03:11:45 -0400 Date: Sat, 14 Sep 2019 07:11:00 -0000 Message-Id: <83pnk3z70d.fsf@gnu.org> From: Eli Zaretskii To: Mike Gulick CC: andrew.burgess@embecosm.com, gdb-patches@sourceware.org In-reply-to: <82898bf2-3928-85a4-4f5f-cc9e194dd2a8@mathworks.com> (message from Mike Gulick on Fri, 13 Sep 2019 22:52:19 +0000) Subject: Re: [RFC] Apply compilation dir to source_path lookup 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> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-IsSubscribed: yes X-SW-Source: 2019-09/txt/msg00250.txt.bz2 > From: Mike Gulick > CC: Mike Gulick , "gdb-patches@sourceware.org" > > Date: Fri, 13 Sep 2019 22:52:19 +0000 > > The only way this would be a problem is if both the compilation > directory and the source file contained a drive letter. Are you sure this is the only problematic use case? Does GDB even try to prepend any directories to a source file whose name is absolute and includes a drive letter? If it does, is that TRT? > 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. That's not exactly what I see on Windows (but note that I used -g3): D:\usr\eli\data>gcc -g3 -c -o test.o d:/usr/eli/data/test.c D:\usr\eli\data>objdump --dwarf test.o ... <3a> DW_AT_name : d:/usr/eli/data/test.c <51> DW_AT_comp_dir : D:\usr\eli\data D:\usr\eli\data>gcc -g3 -c -o test.o -fdebug-prefix-map=D:\usr= d:/usr/eli/data/test.c D:\usr\eli\data>objdump --dwarf test.o ... <3a> DW_AT_name : /eli/data/test.c <4b> DW_AT_comp_dir : \eli\data > If you are concerned about this (possibly some crazy compiler emitting > strange dwarf), the following change should suffice: I'm not familiar with the code enough to be sure, but how do we convince ourselves that removing one of the several drive letters and doing nothing else is TRT in this case? Maybe we should prepend that drive letter to the complete file name we produce? Thanks.