On 2/28/20 4:12 PM, Alexey Neyman wrote:
On 2/28/20 12:28 PM, Jason Merrill wrote:
On 2/28/20 2:11 PM, Alexander Monakov wrote:
On Fri, 28 Feb 2020, Eric Botcazou wrote:
+1 - I think Alexey correctly pointed out in the Bugzilla that
debuginfo
growth from this change would be minimal (usually the number of global
variables is very small compared to number of functions (and
linemap info).
Well, this will drag the associated types too, so figures would be
welcome...
Below are the numbers from compiling GLIBC 2.31 for
x86_64-unknown-linux-gnu. The first column is with a pristine copy of
GCC at -g1, the 2nd/3rd columns are -g1 with this patch, 4th/5th columns
are -g2.
.debug_ranges�� 125872� 125872� 0%����� 452864����� 260%
.debug_str����� 88689�� 102005� 15%���� 183650����� 107%
.debug_abbrev�� 112470� 255769� 127%��� 735914����� 554%
.debug_line���� 647942� 705070� 9%����� 1544877���� 138%
.debug_loc����� 64150�� 64150�� 0%����� 2976025���� 4539%
.debug_aranges� 77712�� 80784�� 4%����� 80912������ 4%
.debug_info���� 240284� 907461� 278%��� 4707104���� 1859%
TOTAL���������� 1357119 2241111 65%���� 10681346��� 687%
So indeed, an increase due to type info is substantial - but still
nothing compared to -g2 increase.
Hm. So apparently at -g1 we don't emit type information for
functions, and
gdb sees each function as 'void foo()' regardless of actual prototype.
Otherwise I would expect most of the types to be already present in
debug info.
I wonder if it would make sense to emit defined variables in a
similar fashion,
i.e. only address and size?
I'll see if I can modify the patch to do so.
I think so.� And we probably don't want function-scope or class-scope
variables that happen to be TREE_PUBLIC.
Can you give an example of such function/class scope variables being
TREE_PUBLIC? I tried a static variable described within a function
scope, it was not TREE_PUBLIC.
A class static data member, or a static variable in an inline function
or template instantiation.
Jason
