[Bug debug/93865] .debug_line with LTO refers to bogus file-names

[Bug debug/93865] .debug_line with LTO refers to bogus file-names

[mark at gcc dot gnu.org]

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

[Bug debug/93865] .debug_line with LTO refers to bogus file-names

[jakub at gcc dot gnu.org]

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.

[Bug debug/93865] .debug_line with LTO refers to bogus file-names

[rguenther at suse dot de]

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).

[Bug debug/93865] .debug_line with LTO refers to bogus file-names

[jakub at gcc dot gnu.org]

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 ).

[Bug debug/93865] .debug_line with LTO refers to bogus file-names

[cvs-commit at gcc dot gnu.org]

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.

[Bug debug/93865] .debug_line with LTO refers to bogus file-names

[cvs-commit at gcc dot gnu.org]

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)

[Bug debug/93865] .debug_line with LTO refers to bogus file-names

[rguenth at gcc dot gnu.org]

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.