[Bug macros/27754] Excessive CPU load and memory usage with -g3 debug info

["rguenth at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=27754

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at redhat dot com

--- Comment #11 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Tom Tromey from comment #9)
> (In reply to Richard Biener from comment #6)
> > The non-LTO .debug_macro has
> > 
> >  DW_MACRO_import - offset : 0x0
> >  DW_MACRO_end_file
> > 
> > as well, whatever that means.
> 
> The problem with LTO is that the output is pathological.
> For example I see this sequence:
> 
>  DW_MACRO_import - offset : 0x0
>  DW_MACRO_end_file
>  DW_MACRO_import - offset : 0x0
>  DW_MACRO_end_file
>  DW_MACRO_import - offset : 0x0
>  DW_MACRO_end_file
> 
> This says to import the macros from offset 0 three times in succession.
> While this is technically ok, it's also absurd.  Is this really
> intentional? This file imports the unit at offset 0x0 multiple times
> -- 108 in fact.

It does look odd.  It appears that it might be a bug with relocation
handling - the imports should be resolved from .rel[a].debug_macro.
I notice the imports at offset zero all appear at the "end" of
.debug_macro.  The first CU with offset zero imports is

  Offset:                      0x11f01
  Version:                     4
  Offset size:                 4
  Offset into .debug_line:     0xc814

Referred from

 <0><10d76>: Abbrev Number: 1 (DW_TAG_compile_unit)
    <10d77>   DW_AT_producer    : (indirect string, offset: 0x5ea6c): GNU C++17 
10.3.0 -mcpu=cortex-m3 -mthumb -mfloat-abi=soft -march=armv7-m -g3 -O3
-std=gnu+
+17 -flto -fno-fat-lto-objects -ffunction-sections -fdata-sections
--param=max-i
nline-insns-single=500
    <10d7b>   DW_AT_language    : 4     (C++)
    <10d7c>   DW_AT_name        : (indirect string, offset: 0x5f012):
/home/rdie
z/rdiez/arduino/JtagDue/Project/BareMetalSupport/Miscellaneous.cpp
    <10d80>   DW_AT_comp_dir    : (indirect string, offset: 0x80ec4):
/home/rdie
z/rdiez/arduino/JtagDue/BuildOutput/JtagDue-obj-release
    <10d84>   DW_AT_stmt_list   : 0xc814
    <10d88>   DW_AT_GNU_macros  : 0x11f01

The exact same zero offset macro imports happen in the Debug non-LTO
firmware btw. (as said, .debug_macro is generate at compile, not at
link time).

That said, a smaller example to reproduce those repeated offset zero
imports would be nice to have.  Unfortunately "preprocessed source"
won't do it ...

It might be that GCC simply misses something here.

> We can probably work around it in gdb somehow.  My first thought is
> to have it simply skip multiple imports of the same unit.  This could
> in theory yield the wrong answer sometimes, though.
> 
> Looks vaguely related to bug#26303, in the "suspicious import" sense.

-- 
You are receiving this mail because:
You are on the CC list for the bug.