[Bug debug/93865] .debug_line with LTO refers to bogus file-names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93865 Richard Biener changed: What|Removed |Added Target Milestone|--- |10.3 Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED Known to fail||10.2.0 --- Comment #8 from Richard Biener --- Fixed in GCC 10.3.
[Bug debug/93865] .debug_line with LTO refers to bogus file-names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93865 --- Comment #7 from CVS Commits --- The releases/gcc-10 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:ceabd8fc7c299b3428f37e8c07b0c9662b119c75 commit r10-8736-gceabd8fc7c299b3428f37e8c07b0c9662b119c75 Author: Jakub Jelinek 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 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)
[Bug debug/93865] .debug_line with LTO refers to bogus file-names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93865 --- Comment #6 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:3d0af0c997fe42a7f0963d970a9c495b81041206 commit r11-3096-g3d0af0c997fe42a7f0963d970a9c495b81041206 Author: Jakub Jelinek 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 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.
[Bug debug/93865] .debug_line with LTO refers to bogus file-names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93865 --- Comment #5 from Jakub Jelinek --- Created attachment 49204 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49204=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 ).
[Bug debug/93865] .debug_line with LTO refers to bogus file-names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93865 --- Comment #4 from 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 changed: > >What|Removed |Added > > CC||jakub at gcc dot gnu.org > > --- Comment #3 from Jakub Jelinek --- > 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).
[Bug debug/93865] .debug_line with LTO refers to bogus file-names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93865 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- 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.
[Bug debug/93865] .debug_line with LTO refers to bogus file-names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93865 --- Comment #2 from Mark Wielaard --- 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
[Bug debug/93865] .debug_line with LTO refers to bogus file-names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93865 Richard Biener changed: What|Removed |Added Keywords||lto CC||hubicka at gcc dot gnu.org --- Comment #1 from Richard Biener --- I think we need to canonicalize locations file either at stream-out time or at stream-in time (then using a streamed comp-dir). Since we're doing cross CU inlining and thus end up mixing .loc from different comp-dirs inside a single function I see no way of somehow transparently preserving the comp-dir via the GIMPLE CUs DW_AT_comp_dir attribute (which is somewhat useless since it contains the link directory). Note the GIMPLE CU also has an empty Directory Table in .debug_line, eventually we could stick the original TUs comp-dir there. But we still need to somehow carry the information across streaming which is where we're losing it right now.
