From: Eli Zaretskii <eliz@gnu.org>
To: Mike Gulick <mgulick@mathworks.com>
Cc: andrew.burgess@embecosm.com, gdb-patches@sourceware.org
Subject: Re: [RFC] Apply compilation dir to source_path lookup
Date: Sat, 14 Sep 2019 07:11:00 -0000 [thread overview]
Message-ID: <83pnk3z70d.fsf@gnu.org> (raw)
In-Reply-To: <82898bf2-3928-85a4-4f5f-cc9e194dd2a8@mathworks.com> (message from Mike Gulick on Fri, 13 Sep 2019 22:52:19 +0000)
> From: Mike Gulick <mgulick@mathworks.com>
> CC: Mike Gulick <mgulick@mathworks.com>, "gdb-patches@sourceware.org"
> <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.
next prev parent reply other threads:[~2019-09-14 7:11 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-05 22:40 Mike Gulick
2019-09-07 23:51 ` Andrew Burgess
2019-09-09 22:41 ` Mike Gulick
2019-09-13 1:38 ` Andrew Burgess
2019-09-13 6:36 ` Eli Zaretskii
2019-09-13 7:28 ` Eli Zaretskii
2019-09-13 22:45 ` Andrew Burgess
2019-09-13 22:52 ` Mike Gulick
2019-09-14 7:11 ` Eli Zaretskii [this message]
2019-09-17 20:22 ` Andrew Burgess
2019-09-17 20:39 ` Mike Gulick
2019-09-14 6:56 ` Eli Zaretskii
2019-09-14 15:28 ` Andrew Burgess
2019-09-14 15:54 ` Eli Zaretskii
2019-09-15 2:07 ` Mike Gulick
2019-09-15 4:01 ` Andrew Burgess
2019-09-15 15:29 ` Eli Zaretskii
2019-09-16 15:53 ` Mike Gulick
2019-09-13 22:11 ` Mike Gulick
2019-09-13 22:41 ` Andrew Burgess
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83pnk3z70d.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=andrew.burgess@embecosm.com \
--cc=gdb-patches@sourceware.org \
--cc=mgulick@mathworks.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox