https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88386
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |lto
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed| |2018-12-06
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
-gsplit-dwarf doesn't really work with LTO so I would recommend to not use it
(the situation gets worse starting with GCC 8). So I'd propose the following
instead which simply does not generate split debug info. If you simply remove
the .dwo files you end up with no debuginfo at all and just have the stubs
in the main executable so that's definitely undesired. To make -gsplit-dwarf
work with LTO one would need to retain the .dwo files somewhere and make sure
the debug consumer can find them from the debug info that ends up in the
final executable.
Does the following work for you? (I still suggest to stop using -gsplit-dwarf
alltogether)
diff --git a/gcc/lto/lto-lang.c b/gcc/lto/lto-lang.c
index 8eb4a25a634..94e3f8fcfaf 100644
--- a/gcc/lto/lto-lang.c
+++ b/gcc/lto/lto-lang.c
@@ -939,6 +939,11 @@ lto_post_options (const char **pfilename ATTRIBUTE_UNUSED)
if (!flag_merge_constants)
flag_merge_constants = 1;
+ /* Since link-time created objects are temporary it doesn't make sense
+ to split their debug information into .dwo files which have no
+ sensible way to be found. */
+ dwarf_split_debug_info = 0;
+
/* Initialize the compiler back end. */
return false;
}
