gdb/
2015-01-31 Eli Zaretskii <eliz@gnu.org>
* tui/tui-io.c (tui_expand_tabs): New function.
(tui_puts, tui_redisplay_readline): Expand TABs into the
appropriate number of spaces.
* tui/tui-regs.c: Include tui-io.h.
(tui_register_format): Call tui_expand_tabs to expand TABs into
the appropriate number of spaces.
* tui/tui-io.h: Add prototype for tui_expand_tabs.
To make it clear that some functions should not modify the variable
object, this patch adds the const qualifier where it makes sense to some
struct varobj * parameters. Most getters should take a const pointer to
guarantee they don't modify the object.
Unfortunately, I couldn't add it to some callbacks (such as name_of_child).
In the C implementation, they call c_describe_child, which calls
varobj_get_path_expr. varobj_get_path_expr needs to modify the object in
order to cache the computed value. It therefore can't take a const
pointer, and it affects the whole call chain. I suppose that's where you
would use a "mutable" in C++.
I did that to make sure there was no other cases like the one fixed in
the previous patch. I don't think it can hurt.
gdb/ChangeLog:
* ada-varobj.c (ada_number_of_children): Constify struct varobj *
parameter.
(ada_name_of_variable): Same.
(ada_path_expr_of_child): Same.
(ada_value_of_variable): Same.
(ada_value_is_changeable_p): Same.
(ada_value_has_mutated): Same.
* c-varobj.c (varobj_is_anonymous_child): Same.
(c_is_path_expr_parent): Same.
(c_number_of_children): Same.
(c_name_of_variable): Same.
(c_path_expr_of_child): Same.
(get_type): Same.
(c_value_of_variable): Same.
(cplus_number_of_children): Same.
(cplus_name_of_variable): Same.
(cplus_path_expr_of_child): Same.
(cplus_value_of_variable): Same.
* jv-varobj.c (java_number_of_children): Same.
(java_name_of_variable): Same.
(java_path_expr_of_child): Same.
(java_value_of_variable): Same.
* varobj.c (number_of_children): Same.
(name_of_variable): Same.
(is_root_p): Same.
(varobj_ensure_python_env): Same.
(varobj_get_objname): Same.
(varobj_get_expression): Same.
(varobj_get_display_format): Same.
(varobj_get_display_hint): Same.
(varobj_has_more): Same.
(varobj_get_thread_id): Same.
(varobj_get_frozen): Same.
(dynamic_varobj_has_child_method): Same.
(varobj_get_gdb_type): Same.
(is_path_expr_parent): Same.
(varobj_default_is_path_expr_parent): Same.
(varobj_get_language): Same.
(varobj_get_attributes): Same.
(varobj_is_dynamic_p): Same.
(varobj_get_child_range): Same.
(varobj_value_has_mutated): Same.
(varobj_get_value_type): Same.
(number_of_children): Same.
(name_of_variable): Same.
(check_scope): Same.
(varobj_editable_p): Same.
(varobj_value_is_changeable_p): Same.
(varobj_floating_p): Same.
(varobj_default_value_is_changeable_p): Same.
* varobj.h (struct lang_varobj_ops): Consitfy some struct varobj *
parameters.
(varobj_get_objname): Constify struct varobj * parameter.
(varobj_get_expression): Same.
(varobj_get_thread_id): Same.
(varobj_get_frozen): Same.
(varobj_get_child_range): Same.
(varobj_get_display_hint): Same.
(varobj_get_gdb_type): Same.
(varobj_get_language): Same.
(varobj_get_attributes): Same.
(varobj_editable_p): Same.
(varobj_floating_p): Same.
(varobj_has_more): Same.
(varobj_is_dynamic_p): Same.
(varobj_ensure_python_env): Same.
(varobj_default_value_is_changeable_p): Same.
(varobj_value_is_changeable_p): Same.
(varobj_get_value_type): Same.
(varobj_is_anonymous_child): Same.
(varobj_value_get_print_value): Same.
(varobj_default_is_path_expr_parent): Same.
It seems like different languages are doing this differently (e.g.
C and Ada). For C, var->path_expr is set inside c_path_expr_of_child.
The next time the value is requested, is it therefore not recomputed.
Ada does not set this field, but just returns the value. Since the field
is never set, the value is recomputed every time it is requested.
This patch makes it so that path_expr_of_child's only job is to compute
the path expression, not save/cache the value. The field is set by the
varobj common code.
gdb/ChangeLog:
* varobj.c (varobj_get_path_expr): Set var->path_expr.
* c-varobj.c (c_path_expr_of_child): Set local var instead of
child->path_expr.
(cplus_path_expr_of_child): Same.
varobj_get_expression returns an allocated string, which must be freed
by the caller.
gdb/ChangeLog:
* mi-cmd-var.c (print_varobj): Free varobj_get_expression
result.
(mi_cmd_var_info_expression): Same.
* varobj.c (varobj_get_expression): Mention in the comment that
the result must by freed by the caller.
varobj_get_type and type_to_string return an allocated string, which is
not freed at a couple of places.
New in v2:
* Rename char * type to type_name.
* Free in all cases in update_type_if_necessary.
gdb/ChangeLog:
* mi/mi-cmd-var.c (mi_cmd_var_info_type): Free result of
varobj_get_type.
(varobj_update_one): Same.
* varobj.c (update_type_if_necessary): Free curr_type_str and
new_type_str.
(varobj_get_type): Specify in comment that the result needs to be
freed by the caller.
This is a feature required in chromeos arm development work.
Tested:
1) Built passed all-gold on x86_64 machine
2) Tested with basic gold aarch64 ifunc unittests -
a) global ifunc, statically/non-statically linked
b) local ifunc, statically/non-statically linked
c) global/local, other shared library routine mixed,
statically/non-statically linked
d) arm/thumb mode ifunc
e) linking chrome browser passed
Both dwarf2read.c (checkproducer) and utils.c (producer_is_gcc_ge_4)
implemented a GCC producer parser that tried to extract the major and minor
version of GCC. Merge them into one GCC producer parser used by both. Also
allow digits in the identifier after "GNU " such as used by GCC5 like:
"GNU C11 5.0.0 20150123 (experimental) -mtune=generic -march=x86-64 -gdwarf-5"
gdb/ChangeLog:
* dwarf2read.c (checkproducer): Call producer_is_gcc.
* utils.c (producer_is_gcc_ge_4): Likewise.
(producer_is_gcc): New function.
* utils.h (producer_is_gcc): New declaration.
Relaxable fragments can be relaxed when there are alignment requirements.
Besides, insert a dummy fragment in the final to make sure that all
alignment is traversed. Finally, convert these fragments
in md_convert_frag with relax_table.
Consider the following declarations:
type Array_Type is array (Integer range <>) of Integer;
type Record_Type (N : Integer) is record
A : Array_Type (1 .. N);
end record;
R : Record_Type := Get (10);
It defines what Ada programers call a "discriminated record", where
"N" is a component of that record called a "discriminant", and where
"A" is a component defined as an array type whose upper bound is
equal to the value of the discriminant.
So far, we rely on a number of fairly complex GNAT-specific encodings
to handle this situation. This patch is to enhance GDB to be able to
print this record in the case where the compiler has been modified
to replace those encodings by pure DWARF constructs.
In particular, the debugging information generated for the record above
looks like the following. "R" is a record..
.uleb128 0x10 # (DIE (0x13e) DW_TAG_structure_type)
.long .LASF17 # DW_AT_name: "foo__record_type"
... whose is is of course dynamic (not our concern here)...
.uleb128 0xd # DW_AT_byte_size
.byte 0x97 # DW_OP_push_object_address
.byte 0x94 # DW_OP_deref_size
.byte 0x4
.byte 0x99 # DW_OP_call4
.long 0x19b
.byte 0x23 # DW_OP_plus_uconst
.uleb128 0x7
.byte 0x9 # DW_OP_const1s
.byte 0xfc
.byte 0x1a # DW_OP_and
.byte 0x1 # DW_AT_decl_file (foo.adb)
.byte 0x6 # DW_AT_decl_line
... and then has 2 members, fist "n" (our discriminant);
.uleb128 0x11 # (DIE (0x153) DW_TAG_member)
.ascii "n\0" # DW_AT_name
.byte 0x1 # DW_AT_decl_file (foo.adb)
.byte 0x6 # DW_AT_decl_line
.long 0x194 # DW_AT_type
.byte 0 # DW_AT_data_member_location
... and "A"...
.uleb128 0x11 # (DIE (0x181) DW_TAG_member)
.ascii "a\0" # DW_AT_name
.long 0x15d # DW_AT_type
.byte 0x4 # DW_AT_data_member_location
... which is an array ...
.uleb128 0x12 # (DIE (0x15d) DW_TAG_array_type)
.long .LASF18 # DW_AT_name: "foo__record_type__T4b"
.long 0x194 # DW_AT_type
... whose lower bound is implicitly 1, and the upper bound
a reference to DIE 0x153 = "N":
.uleb128 0x13 # (DIE (0x16a) DW_TAG_subrange_type)
.long 0x174 # DW_AT_type
.long 0x153 # DW_AT_upper_bound
This patch enhanced GDB to understand references to other DIEs
where the DIE's address is at an offset of its enclosing type.
The difficulty was that the address used to resolve the array's
type (R's address + 4 bytes) is different from the address used
as the base to compute N's address (an offset to R's address).
We're solving this issue by using a stack of addresses rather
than a single address when trying to resolve a type. Each address
in the stack corresponds to each containing level. For instance,
if resolving the field of a struct, the stack should contain
the address of the field at the top, and then the address of
the struct. That way, if the field makes a reference to an object
of the struct, we can retrieve the address of that struct, and
properly resolve the dynamic property references that struct.
gdb/ChangeLog:
* gdbtypes.h (struct dynamic_prop): New PROP_ADDR_OFFSET enum
kind.
* gdbtypes.c (resolve_dynamic_type_internal): Replace "addr"
parameter by "addr_stack" parameter.
(resolve_dynamic_range): Replace "addr" parameter by
"stack_addr" parameter. Update function documentation.
Update code accordingly.
(resolve_dynamic_array, resolve_dynamic_union)
(resolve_dynamic_struct, resolve_dynamic_type_internal): Likewise.
(resolve_dynamic_type): Update code, following the changes made
to resolve_dynamic_type_internal's interface.
* dwarf2loc.h (struct property_addr_info): New.
(dwarf2_evaluate_property): Replace "address" parameter
by "addr_stack" parameter. Adjust function documentation.
(struct dwarf2_offset_baton): New.
(struct dwarf2_property_baton): Update documentation of
field "referenced_type" to be more general. New field
"offset_info" in union data field.
* dwarf2loc.c (dwarf2_evaluate_property): Replace "address"
parameter by "addr_stack" parameter. Adjust code accordingly.
Add support for PROP_ADDR_OFFSET properties.
* dwarf2read.c (attr_to_dynamic_prop): Add support for
DW_AT_data_member_location attributes as well. Use case
statements instead of if/else condition.
gdb/testsuite/ChangeLog:
* gdb.ada/disc_arr_bound: New testcase.
Tested on x86_64-linux, no regression.
This is preparation work to avoid a regression in the Ada/varobj.
An upcoming patch is going to add support for types in DWARF
which have dynamic properties whose value is a reference to another
DIE.
Consider for instance the following declaration:
type Variant_Type (N : Int := 0) is record
F : String(1 .. N) := (others => 'x');
end record;
type Variant_Type_Access is access all Variant_Type;
VTA : Variant_Type_Access := null;
This declares a variable "VTA" which is an access (=pointer)
to a variant record Variant_Type. This record contains two
components, the first being "N" (the discriminant), and the
second being "F", an array whose lower bound is 1, and whose
upper bound depends on the value of "N" (the discriminant).
Of interest to us, here, is that second component ("F"), and
in particular its bounds. The debugging info, and in particular
the info for the array looks like the following...
.uleb128 0x9 # (DIE (0x91) DW_TAG_array_type)
.long .LASF16 # DW_AT_name: "bar__variant_type__T2b"
.long 0xac # DW_AT_GNAT_descriptive_type
.long 0x2cb # DW_AT_type
.long 0xac # DW_AT_sibling
.uleb128 0xa # (DIE (0xa2) DW_TAG_subrange_type)
.long 0xc4 # DW_AT_type
.long 0x87 # DW_AT_upper_bound
.byte 0 # end of children of DIE 0x91
... where the upper bound of the array's subrange type is a reference
to "n"'s DIE (0x87):
.uleb128 0x8 # (DIE (0x87) DW_TAG_member)
.ascii "n\0" # DW_AT_name
[...]
Once the patch to handle this dynamic property gets applied,
this is what happens when creating a varobj for variable "VTA"
(whose value is null), and then trying to list its children:
(gdb)
-var-create vta * vta
^done,name="vta",numchild="2",value="0x0",
type="bar.variant_type_access",has_more="0"
(gdb)
-var-list-children 1 vta
^done,numchild="2",
children=[child={name="vta.n",[...]},
child={name="vta.f",exp="f",
numchild="43877616", <<<<-----
value="[43877616]", <<<<-----
type="array (1 .. n) of character"}],
has_more="0"
It has an odd number of children.
In this case, we cannot really determine the number of children,
since that number depends on the value of a field in a record
for which we do not have a value. Up to now, the value we've been
displaying is zero - meaning we have an empty array.
What happens in this case, is that, because the VTA is a null pointer,
we're not able to resolve the pointer's target type, and therefore
end up asking ada_varobj_get_array_number_of_children to return
the number of elements in that array; for that, it relies blindly
on get_array_bounds, which assumes the type is no longer dynamic,
and therefore the reads the bound without seeing that it's value
is actually a reference rather than a resolved constant.
This patch prevents the issue by explicitly handling the case of
dynamic arrays, and returning zero child in that case.
gdb/ChangeLog:
* ada-varobj.c (ada_varobj_get_array_number_of_children):
Return zero if PARENT_VALUE is NULL and parent_type's
range type is dynamic.
gdb/testsuite/ChangeLog:
* gdb.ada/mi_var_array: New testcase.
Tested on x86_64-linux.
Consider the following code:
type Record_Type (N : Integer) is record
A : Array_Type (1 .. N);
end record;
[...]
R : Record_Type := Get (10);
Trying to print the bounds of the array R.A yielded:
(gdb) p r.a'last
$4 = cannot find reference address for offset property
A slightly different example, but from the same cause:
(gdb) ptype r
type = <ref> record
n: integer;
a: array (cannot find reference address for offset property
Looking at the debugging info, "A" is described as...
.uleb128 0x11 # (DIE (0x181) DW_TAG_member)
.ascii "a\0" # DW_AT_name
.long 0x15d # DW_AT_type
[...]
... which is an array...
.uleb128 0x12 # (DIE (0x15d) DW_TAG_array_type)
.long .LASF18 # DW_AT_name: "foo__record_type__T4b"
.long 0x194 # DW_AT_type
.long 0x174 # DW_AT_sibling
... whose bounds are described as:
.uleb128 0x13 # (DIE (0x16a) DW_TAG_subrange_type)
.long 0x174 # DW_AT_type
.long 0x153 # DW_AT_upper_bound
.byte 0 # end of children of DIE 0x15d
We can see above that the range has an implict lower value of
1, and an upper value which is a reference 0x153="n". All Good.
But looking at the array's subrange subtype, we see...
.uleb128 0x14 # (DIE (0x174) DW_TAG_subrange_type)
.long 0x153 # DW_AT_upper_bound
.long .LASF19 # DW_AT_name: "foo__record_type__T3b"
.long 0x18d # DW_AT_type
... another subrange type whose bounds are exactly described
the same way. So we have a subrange of a subrange, both with
one bound that's dynamic.
What happens in the case above is that GDB's resolution of "R.A"
yields a array whose index type has static bounds. However, the
subtype of the array's index type was left untouched, so, when
taking the subtype of the array's subrange type, we were left
with the unresolved subrange type, triggering the error above.
gdb/ChangeLog:
* gdbtypes.c (is_dynamic_type_internal) <TYPE_CODE_RANGE>: Return
nonzero if the type's subtype is dynamic.
(resolve_dynamic_range): Also resolve the range's subtype.
Tested on x86_64-linux, no regression.
Compilation of (GDB) 7.9.50.20150127-cvs with (GCC) 5.0.0 20150127
fails with
In file included from symfile.c:32:0:
symfile.c: In function 'unmap_overlay_command':
objfiles.h:628:3: error: 'sec' may be used uninitialized in this
function [-Werror=maybe-uninitialized]
for (osect = objfile->sections; osect < objfile->sections_end; osect++) \
^
symfile.c:3442:23: note: 'sec' was declared here
struct obj_section *sec;
^
cc1: all warnings being treated as errors
make[2]: *** [symfile.o] Error 1
make[2]: Leaving directory `gdb/gdb'
While the bug was reported to GCC as
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64823>,
the attached patch simply initializes sec with NULL.
gdb/ChangeLog:
* symfile.c (unmap_overlay_command): Initialize sec to NULL.
Tested on x86_64-linux.
The linker hardcoded r3 into a local-dynamic to local-exec TLS
optimization sequence. This is normally the case since r3 is required
as a parameter to (the optimized out) __tls_get_addr call. However,
it is possible for a compiler, LLVM in this case, to set up the
parameter value in another register then copy it to r3 before the
call.
When fixing this problem, I noticed that ppc32 had another bug when
optimizing away one of the TLS insns to a nop.
The patch also tidies a mask used by global-dynamic to initial-exec
TLS optimization, to just select the fields needed. Leaving the
offset in the instruction wasn't a bug since it will be overwritten
anyway.
bfd/
* elf64-ppc.c (ppc64_elf_relocate_section): Correct GOT_TLSLD
optimization. Tidy mask for GOT_TLSGD optimization.
* elf32-ppc.c (ppc_elf_relocate_section): Likewise. Correct
location of nop zapping high insn too.
ld/testsuite/
* ld-powerpc/tlsld.d, * ld-powerpc/tlsld.s: New test.
* ld-powerpc/tlsld32.d, * ld-powerpc/tlsld32.s: New test.
* ld-powerpc/powerpc.exp: Run them. Move tocvar and tocnovar.
When --warn-unresolved-symbols is used, gold tries to create a dynamic relocation
for it, and gives an internal error if the TLS segment has not already been
created. This patch allows the IE-to-LE optimization for an undefined symbol
when building an executable, which suppresses the dynamic relocation, and
relaxes the requirement to have a TLS segment when applying a relocation for
an undefined symbol.
2015-01-28 Cary Coutant <ccoutant@google.com>
gold/
* x86_64.cc (Target_x86_64::Scan::global): Allow IE-to-LE optimization
for undef TLS symbols.
(Target_x86_64::Relocate::relocate_tls): Likewise.
(Target_x86_64::Relocate::tls_ie_to_le): Likewise.
"f1" is a register name on ia64, and hence gets warned upon when used
as expression value:
.../binutils/2.25/ld/testsuite/ld-elf/pr16322.s: Assembler messages:
.../binutils/2.25/ld/testsuite/ld-elf/pr16322.s:6: Warning: register value used as expression
Change the name (and "p1" at once, which is a register name too, albeit
not currently causing any immediate problem).
ld/testsuite/
2015-01-28 Jan Beulich <jbeulich@suse.com>
* ld-elf/pr16322.s (p1): Rename to px1.
(f1): Rename to fx1.
The changes to reorder sections for better relro protection on powerpc64,
3e2b0f31, 23283c1b, and 5ad18f16, run into a problem with xlc.
xlc -qdatalocal puts global variables into .toc, which means that .toc
must be writable. The simplest way to accomplish this is to edit the
linker script to remove .toc sections from .got on detecting xlc object
files.
bfd/
* elf64-ppc.h (struct ppc64_elf_params): Add "object_in_toc".
* elf64-ppc.c (ppc64_elf_add_symbol_hook): Assume that global symbols
in .toc indicate xlc compiled code that might require a rw .toc.
ld/
* emulparams/elf64ppc.sh (INITIAL_READWRITE_SECTIONS): Define.
* emultempl/ppc64elf.em (params): Init new field.
(ppc_after_open): New function.
(LDEMUL_AFTER_OPEN): Define.
* ldlang.c (lang_final): Whitespace fix.
ld/testsuite/
* ld-powerpc/tocvar.d, * ld-powerpc/tocvar.s: New test.
* ld-powerpc/tocnovar.d, * ld-powerpc/tocnovar.s: New test.
* ld-powerpc/powerpc.exp: Run tocvar and tocnovar.
This patch fixes PR 4643 by allowing symbols in the LENGTH and ORIGIN
fields of MEMORY regions. Previously, only constants and constant
expressions are allowed.
For the AVR target, this helps define memory constraints more
accurately (per device), without having to create a ton of device
specific linker scripts.
ld/
PR 4643
* ldexp.c (fold_name): Fold LENGTH only after
lang_first_phase_enum.
* ldgram.y (memory_spec): Don't evaluate ORIGIN and LENGTH
rightaway.
* ldlang.h (struct memory_region_struct): Add origin_exp and
length_exp fields.
* ldlang.c (lang_do_memory_regions): New.
(lang_memory_region_lookup): Initialize origin_exp and
length_exp fields.
(lang_process): Call lang_do_memory_regions.
ld/testsuite/
* ld-scripts/memory.t: Define new symbol tred.
* ld-scripts/memory_sym.t: New.
* ld-scripts/script.exp: Perform MEMORY with symbols test, and
conditionally check values of linker symbols.
gdb/ChangeLog:
* NEWS: Mention gdb.Objfile.username.
* python/py-objfile.c (objfpy_get_username): New function.
(objfile_getset): Add "username".
gdb/doc/ChangeLog:
* python.texi (Objfiles In Python): Document Objfile.username.
gdb/testsuite/ChangeLog:
* gdb.python/py-objfile.exp: Add tests for objfile.username.
Add test for objfile.filename, objfile.username after objfile
has been unloaded.
PR binutils/17512
* rcparse.y: Add checks to avoid integer divide by zero.
* rescoff.c (read_coff_rsrc): Add check on the size of the
resource section.
(read_coff_res_dir): Add check on the nesting level.
Check for resource names overrunning the buffer.
* resrc.c (write_rc_messagetable): Update formatting.
Add check of 'elen' being zero.
PR binutils/17512
* addr2line.c (slurp_symtab): If the symcount is zero, free the
symbol table pointer.
* dwarf2.c (concat_filename): Check for an empty directory table.
(scan_unit_for_symbols): Check for reading off the end of the
unit.
(parse_comp_unit): Check for a DW_AT_comp_dir attribute with a
non-string form.
* elf64-ppc.c (opd_entry_value): Fail if there are no relocs
available.
PR binutils/17512
* dlltool.c (identify_search_archive): If the last archive was the
same as the current archive, terminate the loop.
* pdp11.c (aout_get_external_symbols): Return false if there are
no symbols.
This further improves this testcase to check the output of
our calls to gdb.lookup_type.
gdb/ChangeLog:
* gdb.python/py-lookup-type.exp (test_lookup_type): Change
the second test to print the name attribute of value
returned by the call to gdb.lookup_type, and adjust
the expected output accordingly.
GCC5 defaults to the GNU11 standard for C and warns by default for
implicit function declarations and implicit return types.
https://gcc.gnu.org/gcc-5/porting_to.html
Fixing these issues in the testsuite turns 9 untested and 17 unsupported
testcases into 417 new passes when compiling with GCC5.
gdb/testsuite/ChangeLog:
* gdb.arch/i386-bp_permanent.c (standard): New declaration.
* gdb.base/disp-step-fork.c: Include unistd.h.
* gdb.base/siginfo-obj.c: Include stdio.h.
* gdb.base/siginfo-thread.c: Likewise.
* gdb.mi/non-stop.c: Include unistd.h.
* gdb.mi/nsthrexec.c: Include stdio.h.
* gdb.mi/pthreads.c: Include unistd.h.
* gdb.modula2/unbounded1.c (main): Declare returns int.
* gdb.reverse/consecutive-reverse.c: Likewise.
* gdb.threads/create-fail.c: Include unistd.h.
* gdb.threads/killed.c: Likewise.
* gdb.threads/linux-dp.c: Likewise.
* gdb.threads/non-ldr-exc-1.c: Include stdio.h and string.h.
* gdb.threads/non-ldr-exc-2.c: Likewise.
* gdb.threads/non-ldr-exc-3.c: Likewise.
* gdb.threads/non-ldr-exc-4.c: Likewise.
* gdb.threads/pthreads.c: Include unistd.h.
(main): Declare returns int.
* gdb.threads/tls-main.c (foo): New declaration.
* gdb.threads/watchpoint-fork-mt.c: Define _GNU_SOURCE.
Since Fedora started to use DWZ DWARF compressor:
http://fedoraproject.org/wiki/Features/DwarfCompressor
GDB has slowed down a lot. To make it clear - DWZ is DWARF structure
rearrangement, "compressor" does not mean any zlib style data compression.
This patch reduces LibreOffice backtrace from 5 minutes to 3 seconds (100x)
and it also reduces memory consumption 20x.
[ benchmark is at the bottom of this mail ]
Example of DWZ output:
------------------------------------------------------------------------------
Compilation Unit @ offset 0xc4:
<0><cf>: Abbrev Number: 17 (DW_TAG_partial_unit)
<d0> DW_AT_stmt_list : 0x0
<d4> DW_AT_comp_dir : (indirect string, offset: 0x6f): /usr/src/debug/gdb-7.7.1/build-x86_64-redhat-linux-gnu/gdb
<1><d8>: Abbrev Number: 9 (DW_TAG_typedef)
<d9> DW_AT_name : (indirect string, offset: 0x827dc): size_t
<dd> DW_AT_decl_file : 4
<de> DW_AT_decl_line : 212
<df> DW_AT_type : <0xae>
Compilation Unit @ offset 0xe4:
<0><ef>: Abbrev Number: 13 (DW_TAG_partial_unit)
<f0> DW_AT_stmt_list : 0x0
<f4> DW_AT_comp_dir : (indirect string, offset: 0x6f): /usr/src/debug/gdb-7.7.1/build-x86_64-redhat-linux-gnu/gdb
<1><f8>: Abbrev Number: 45 (DW_TAG_typedef)
<f9> DW_AT_name : (indirect string, offset: 0x251): __off_t
<fd> DW_AT_decl_file : 3
<fe> DW_AT_decl_line : 131
<ff> DW_AT_type : <0x68>
Compilation Unit @ offset 0x62d9f9:
<0><62da04>: Abbrev Number: 20 (DW_TAG_compile_unit)
[...]
<62da12> DW_AT_low_pc : 0x807e10
<62da1a> DW_AT_high_pc : 134
<62da1c> DW_AT_stmt_list : 0xf557e
<1><62da20>: Abbrev Number: 7 (DW_TAG_imported_unit)
<62da21> DW_AT_import : <0xcf> [Abbrev Number: 17]
------------------------------------------------------------------------------
One can see all DW_TAG_partial_unit have DW_AT_stmt_list 0x0 which causes
repeated decoding of that .debug_line unit on each DW_TAG_imported_unit.
This was OK before as each DW_TAG_compile_unit has its own .debug_line unit.
But since the introduction of DW_TAG_partial_unit by DWZ one should cache
read-in DW_AT_stmt_list .debug_line units.
Fortunately one does not need to cache whole
struct linetable *symtab->linetable
and other data from .debug_line mapping PC<->lines
------------------------------------------------------------------------------
Line Number Statements:
Extended opcode 2: set Address to 0x45c880
Advance Line by 25 to 26
Copy
------------------------------------------------------------------------------
as the only part of .debug_line which GDB needs for DW_TAG_partial_unit is:
------------------------------------------------------------------------------
The Directory Table:
../../gdb
/usr/include/bits
[...]
The File Name Table:
Entry Dir Time Size Name
1 1 0 0 gdb.c
2 2 0 0 string3.h
[...]
------------------------------------------------------------------------------
specifically referenced in GDB for DW_AT_decl_file at a single place:
------------------------------------------------------------------------------
fe = &cu->line_header->file_names[file_index - 1];
SYMBOL_SYMTAB (sym) = fe->symtab;
------------------------------------------------------------------------------
This is because for some reason DW_TAG_partial_unit never contains PC-related
DWARF information. I do not know exactly why, the compression ratio is a bit
lower due to it but thanksfully currently it is that way:
dwz.c:
------------------------------------------------------------------------------
/* These attributes reference code, prevent moving
DIEs with them. */
case DW_AT_low_pc:
case DW_AT_high_pc:
case DW_AT_entry_pc:
case DW_AT_ranges:
die->die_ck_state = CK_BAD;
+
/* State of checksum computation. Not computed yet, computed and
suitable for moving into partial units, currently being computed
and finally determined unsuitable for moving into partial units. */
enum { CK_UNKNOWN, CK_KNOWN, CK_BEING_COMPUTED, CK_BAD } die_ck_state : 2;
------------------------------------------------------------------------------
I have also verified also real-world Fedora debuginfo files really comply with
that assumption with dwgrep
https://github.com/pmachata/dwgrep
using:
------------------------------------------------------------------------------
dwgrep -e 'entry ?DW_TAG_partial_unit child* ( ?DW_AT_low_pc , ?DW_AT_high_pc , ?DW_AT_ranges )' /usr/lib/debug/**
------------------------------------------------------------------------------
BTW I think GDB already does not support the whole DW_TAG_imported_unit and
DW_TAG_partial_unit usage possibilities as specified by the DWARF standard.
I think GDB would not work if DW_TAG_imported_unit was used in some inner
level and not at the CU level (readelf -wi level <1>) - this is how DWZ is
using DW_TAG_imported_unit. Therefore I do not think further assumptions
about DW_TAG_imported_unit and DW_TAG_partial_unit usage by DWZ are a problem
for GDB.
One could save the whole .debug_line decoded PC<->lines mapping (and not just
the DW_AT_decl_file table) but:
* there are some problematic corner cases so one could do it incorrectly
* there are no real world data to really test such patch extension
* such extension could be done perfectly incrementally on top of this patch
------------------------------------------------------------------------------
benchmark - on Fedora 20 x86_64 and FSF GDB HEAD:
echo -e 'thread apply all bt\nset confirm no\nq'|./gdb -p `pidof soffice.bin` -ex 'set pagination off' -ex 'maintenance set per-command
space' -ex 'maintenance set per-command symtab' -ex 'maintenance set per-command time'
FSF GDB HEAD ("thread apply all bt"):
Command execution time: 333.693000 (cpu), 335.587539 (wall)
---sec
Space used: 1736404992 (+1477189632 for this command)
----MB
vs.
THIS PATCH ("thread apply all bt"):
Command execution time: 2.595000 (cpu), 2.607573 (wall)
-sec
Space used: 340058112 (+85917696 for this command)
--MB
FSF GDB HEAD ("thread apply all bt full"):
Command execution time: 466.751000 (cpu), 468.345837 (wall)
---sec
Space used: 2330132480 (+2070974464 for this command)
----MB
vs.
THIS PATCH ("thread apply all bt full"):
Command execution time: 18.907000 (cpu), 18.964125 (wall)
--sec
Space used: 364462080 (+110325760 for this command)
---MB
------------------------------------------------------------------------------
gdb/ChangeLog
2015-01-24 Jan Kratochvil <jan.kratochvil@redhat.com>
Fix 100x slowdown regression on DWZ files.
* dwarf2read.c (struct dwarf2_per_objfile): Add line_header_hash.
(struct line_header): Add offset and offset_in_dwz.
(dwarf_decode_lines): Add parameter decode_mapping to the declaration.
(free_line_header_voidp): New declaration.
(line_header_hash, line_header_hash_voidp, line_header_eq_voidp): New
functions.
(dwarf2_build_include_psymtabs): Update dwarf_decode_lines caller.
(handle_DW_AT_stmt_list): Use line_header_hash.
(free_line_header_voidp): New function.
(dwarf_decode_line_header): Initialize offset and offset_in_dwz.
(dwarf_decode_lines): New parameter decode_mapping, use it.
(dwarf2_free_objfile): Free line_header_hash.
