* [Bug debug/93865] .debug_line with LTO refers to bogus file-names
[not found] <bug-93865-4@http.gcc.gnu.org/bugzilla/>
@ 2020-07-26 15:50 ` mark at gcc dot gnu.org
2020-09-07 15:58 ` jakub at gcc dot gnu.org
` (5 subsequent siblings)
6 siblings, 0 replies; 7+ messages in thread
From: mark at gcc dot gnu.org @ 2020-07-26 15:50 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93865
--- Comment #2 from Mark Wielaard <mark at gcc dot gnu.org> ---
This also impacts rpm (find-debuginfo.sh) when it tries to extract the source
files from binaries compiled with LTO enabled:
https://github.com/rpm-software-management/rpm/issues/1207
^ permalink raw reply [flat|nested] 7+ messages in thread* [Bug debug/93865] .debug_line with LTO refers to bogus file-names
[not found] <bug-93865-4@http.gcc.gnu.org/bugzilla/>
2020-07-26 15:50 ` [Bug debug/93865] .debug_line with LTO refers to bogus file-names mark at gcc dot gnu.org
@ 2020-09-07 15:58 ` jakub at gcc dot gnu.org
2020-09-08 6:26 ` rguenther at suse dot de
` (4 subsequent siblings)
6 siblings, 0 replies; 7+ messages in thread
From: jakub at gcc dot gnu.org @ 2020-09-07 15:58 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93865
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I guess this isn't only about the main source files, but about any includes (if
they are relative, not absolute).
Perhaps when streaming out lto we should stream for each TU also the
get_src_pwd () string, and in canon_file_name in lto-streamer-in.c take into
account the src pwd read from the current TU vs. get_src_pwd () for the LTO
link.
If they are the same, don't do any changes, similarly for absolute paths no
difference, otherwise canonicalize relative paths for the difference in the
paths.
^ permalink raw reply [flat|nested] 7+ messages in thread* [Bug debug/93865] .debug_line with LTO refers to bogus file-names
[not found] <bug-93865-4@http.gcc.gnu.org/bugzilla/>
2020-07-26 15:50 ` [Bug debug/93865] .debug_line with LTO refers to bogus file-names mark at gcc dot gnu.org
2020-09-07 15:58 ` jakub at gcc dot gnu.org
@ 2020-09-08 6:26 ` rguenther at suse dot de
2020-09-09 12:50 ` jakub at gcc dot gnu.org
` (3 subsequent siblings)
6 siblings, 0 replies; 7+ messages in thread
From: rguenther at suse dot de @ 2020-09-08 6:26 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93865
--- Comment #4 from rguenther at suse dot de <rguenther at suse dot de> ---
On Mon, 7 Sep 2020, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93865
>
> Jakub Jelinek <jakub at gcc dot gnu.org> changed:
>
> What |Removed |Added
> ----------------------------------------------------------------------------
> CC| |jakub at gcc dot gnu.org
>
> --- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> I guess this isn't only about the main source files, but about any includes (if
> they are relative, not absolute).
> Perhaps when streaming out lto we should stream for each TU also the
> get_src_pwd () string, and in canon_file_name in lto-streamer-in.c take into
> account the src pwd read from the current TU vs. get_src_pwd () for the LTO
> link.
> If they are the same, don't do any changes, similarly for absolute paths no
> difference, otherwise canonicalize relative paths for the difference in the
> paths.
Something like that - but note that there's another "copy" of .debug_line
in the early debug data (but with "correct" CWD). Note one "natural"
place to stream the CWD string is attached to the TRANSLATION_UNIT_DECL,
but then streaming the original location file and intending to massage
it later is probably awkward which means the easiest fix would certainly
be to canonicalize / concat CWD and location file at location stream out
time. The question is whether we want to "undo" / re-canonicalize
any of that afterwards (and what "CWD" to use for the LTRANS .debug_line).
^ permalink raw reply [flat|nested] 7+ messages in thread* [Bug debug/93865] .debug_line with LTO refers to bogus file-names
[not found] <bug-93865-4@http.gcc.gnu.org/bugzilla/>
` (2 preceding siblings ...)
2020-09-08 6:26 ` rguenther at suse dot de
@ 2020-09-09 12:50 ` jakub at gcc dot gnu.org
2020-09-10 9:25 ` cvs-commit at gcc dot gnu.org
` (2 subsequent siblings)
6 siblings, 0 replies; 7+ messages in thread
From: jakub at gcc dot gnu.org @ 2020-09-09 12:50 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93865
--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 49204
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49204&action=edit
gcc11-pr93865-wip.patch
Untested WIP patch which seems to fix the problem.
I have some problems with make_relative_prefix_ignore_links though, one is that
it has way too many cases in which it just returns NULL, another one is that
due to all the memory allocations it is quite expensive and lastly e.g. for
"/", "/usr/src/gcc/obj/gcc/tt/b", "/usr/src/gcc/obj/gcc/tt" it returns
"../../tt" rather than ".." I'd expect. So I'm considering writing a lighter
version of that and have a fallback to using absolute path e.g. if the two
paths
have nothing in common (consider Windowsy C:\foo and D:\bar ).
^ permalink raw reply [flat|nested] 7+ messages in thread* [Bug debug/93865] .debug_line with LTO refers to bogus file-names
[not found] <bug-93865-4@http.gcc.gnu.org/bugzilla/>
` (3 preceding siblings ...)
2020-09-09 12:50 ` jakub at gcc dot gnu.org
@ 2020-09-10 9:25 ` cvs-commit at gcc dot gnu.org
2020-09-11 7:48 ` cvs-commit at gcc dot gnu.org
2022-06-01 13:10 ` rguenth at gcc dot gnu.org
6 siblings, 0 replies; 7+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2020-09-10 9:25 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93865
--- Comment #6 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:
https://gcc.gnu.org/g:3d0af0c997fe42a7f0963d970a9c495b81041206
commit r11-3096-g3d0af0c997fe42a7f0963d970a9c495b81041206
Author: Jakub Jelinek <jakub@redhat.com>
Date: Thu Sep 10 11:25:02 2020 +0200
lto: Stream current working directory for first streamed relative filename
and adjust relative paths [PR93865]
If the gcc -c -flto ... commands to compile some or all objects are run in
a
different directory (or in different directories) from the directory in
which the gcc -flto link line is invoked, then the .debug_line will be
incorrect if there are any relative filenames, it will use those relative
filenames while .debug_info will contain a different DW_AT_comp_dir.
The following patch streams (at most once after each clear_line_info)
the current working directory (what we record in DW_AT_comp_dir) when
encountering the first relative pathname, and when reading the location
info
reads it back and if the current working directory at that point is
different from the saved one, adjusts relative paths by adding a relative
prefix how to go from the current working directory to the previously saved
path (with a fallback e.g. for DOS e:\\foo vs. d:\\bar change to use
absolute directory).
2020-09-10 Jakub Jelinek <jakub@redhat.com>
PR debug/93865
* lto-streamer.h (struct output_block): Add emit_pwd member.
* lto-streamer-out.c: Include toplev.h.
(clear_line_info): Set emit_pwd.
(lto_output_location_1): Encode the ob->current_file != xloc.file
bit directly into the location number. If changing file, emit
additionally a bit whether pwd is emitted and emit it before the
first relative pathname since clear_line_info.
(output_function, output_constructor): Don't call clear_line_info
here.
* lto-streamer-in.c (struct string_pair_map): New type.
(struct string_pair_map_hasher): New type.
(string_pair_map_hasher::hash): New method.
(string_pair_map_hasher::equal): New method.
(path_name_pair_hash_table, string_pair_map_allocator): New
variables.
(relative_path_prefix, canon_relative_path_prefix,
canon_relative_file_name): New functions.
(canon_file_name): Add relative_prefix argument, if non-NULL
and string is a relative path, return canon_relative_file_name.
(lto_location_cache::input_location_and_block): Decode file change
bit from the location number. If changing file, unpack bit whether
pwd is streamed and stream in pwd. Adjust canon_file_name caller.
(lto_free_file_name_hash): Delete path_name_pair_hash_table
and string_pair_map_allocator.
^ permalink raw reply [flat|nested] 7+ messages in thread* [Bug debug/93865] .debug_line with LTO refers to bogus file-names
[not found] <bug-93865-4@http.gcc.gnu.org/bugzilla/>
` (4 preceding siblings ...)
2020-09-10 9:25 ` cvs-commit at gcc dot gnu.org
@ 2020-09-11 7:48 ` cvs-commit at gcc dot gnu.org
2022-06-01 13:10 ` rguenth at gcc dot gnu.org
6 siblings, 0 replies; 7+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2020-09-11 7:48 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93865
--- Comment #7 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:
https://gcc.gnu.org/g:ceabd8fc7c299b3428f37e8c07b0c9662b119c75
commit r10-8736-gceabd8fc7c299b3428f37e8c07b0c9662b119c75
Author: Jakub Jelinek <jakub@redhat.com>
Date: Thu Sep 10 11:25:02 2020 +0200
lto: Stream current working directory for first streamed relative filename
and adjust relative paths [PR93865]
If the gcc -c -flto ... commands to compile some or all objects are run in
a
different directory (or in different directories) from the directory in
which the gcc -flto link line is invoked, then the .debug_line will be
incorrect if there are any relative filenames, it will use those relative
filenames while .debug_info will contain a different DW_AT_comp_dir.
The following patch streams (at most once after each clear_line_info)
the current working directory (what we record in DW_AT_comp_dir) when
encountering the first relative pathname, and when reading the location
info
reads it back and if the current working directory at that point is
different from the saved one, adjusts relative paths by adding a relative
prefix how to go from the current working directory to the previously saved
path (with a fallback e.g. for DOS e:\\foo vs. d:\\bar change to use
absolute directory).
2020-09-10 Jakub Jelinek <jakub@redhat.com>
PR debug/93865
* lto-streamer.h (struct output_block): Add emit_pwd member.
* lto-streamer-out.c: Include toplev.h.
(clear_line_info): Set emit_pwd.
(lto_output_location_1): Encode the ob->current_file != xloc.file
bit directly into the location number. If changing file, emit
additionally a bit whether pwd is emitted and emit it before the
first relative pathname since clear_line_info.
(output_function, output_constructor): Don't call clear_line_info
here.
* lto-streamer-in.c (struct string_pair_map): New type.
(struct string_pair_map_hasher): New type.
(string_pair_map_hasher::hash): New method.
(string_pair_map_hasher::equal): New method.
(path_name_pair_hash_table, string_pair_map_allocator): New
variables.
(relative_path_prefix, canon_relative_path_prefix,
canon_relative_file_name): New functions.
(canon_file_name): Add relative_prefix argument, if non-NULL
and string is a relative path, return canon_relative_file_name.
(lto_location_cache::input_location_and_block): Decode file change
bit from the location number. If changing file, unpack bit whether
pwd is streamed and stream in pwd. Adjust canon_file_name caller.
(lto_free_file_name_hash): Delete path_name_pair_hash_table
and string_pair_map_allocator.
(cherry picked from commit 3d0af0c997fe42a7f0963d970a9c495b81041206)
^ permalink raw reply [flat|nested] 7+ messages in thread* [Bug debug/93865] .debug_line with LTO refers to bogus file-names
[not found] <bug-93865-4@http.gcc.gnu.org/bugzilla/>
` (5 preceding siblings ...)
2020-09-11 7:48 ` cvs-commit at gcc dot gnu.org
@ 2022-06-01 13:10 ` rguenth at gcc dot gnu.org
6 siblings, 0 replies; 7+ messages in thread
From: rguenth at gcc dot gnu.org @ 2022-06-01 13:10 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93865
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|--- |10.3
Resolution|--- |FIXED
Status|UNCONFIRMED |RESOLVED
Known to fail| |10.2.0
--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
Fixed in GCC 10.3.
^ permalink raw reply [flat|nested] 7+ messages in thread