In Ada, the programmer can request that a range type with a non-zero
base be stored in the minimal number of bits required for the range.
This is done by biasing the values; so, for example, a range of -7..-4
may be stored as two bits with a bias of -7.
This patch implements this for gdb. It is done by adding a bias to
struct range_bounds and then adjusting a few spots to handle this.
The test case is written to use -fgnat-encodings=minimal, but a future
compiler patch will change the compiler to emit DW_AT_GNU_bias with
-fgnat-encodings=gdb. It seemed good to get the gdb patch in first.
Tested on x86-64 Fedora 29; plus a variety of targets using AdaCore's
internal test suite.
gdb/ChangeLog
2019-09-03 Tom Tromey <tromey@adacore.com>
* ada-valprint.c (ada_val_print_num): Don't recurse for range
types.
(has_negatives): Unbias a range type bound.
* dwarf2read.c (read_subrange_type): Handle DW_AT_GNU_bias.
* gdbtypes.c (operator==): Handle new field.
(create_range_type): Add "bias" parameter.
(create_static_range_type, resolve_dynamic_range): Update.
* gdbtypes.h (struct range_bounds) <bias>: New member.
(create_range_type): Add bias parameter.
* printcmd.c (print_scalar_formatted): Unbias range types.
* value.c (unpack_long): Unbias range types.
(pack_long): Bias range types.
gdb/testsuite/ChangeLog
2019-09-03 Tom Tromey <tromey@adacore.com>
* gdb.ada/bias.exp: New file.
* gdb.ada/bias/bias.adb: New file.
* gdb.ada/print_chars.exp: Add regression test.
* gdb.ada/print_chars/foo.adb (My_Character): New type.
(MC): New variable.
I touched symtab.h and was surprised to see how many files were
rebuilt. I looked into it a bit, and found that defs.h includes
gdbarch.h, which in turn includes many things.
gdbarch.h is only needed by a minority ofthe files in gdb, so this
patch removes the include from defs.h and updates the fallout.
I did "wc -l" on the files in build/gdb/.deps; this patch reduces the
line count from 139935 to 137030; so there are definitely future
build-time savings here.
Note that while I configured with --enable-targets=all, it's possible
that some *-nat.c file needs an update. I could not test all of
these. The buildbot caught a few problems along these lines.
gdb/ChangeLog
2019-07-10 Tom Tromey <tom@tromey.com>
* defs.h: Don't include gdbarch.h.
* aarch64-ravenscar-thread.c, aarch64-tdep.c, alpha-bsd-tdep.h,
alpha-linux-tdep.c, alpha-mdebug-tdep.c, arch-utils.h, arm-tdep.h,
ax-general.c, btrace.c, buildsym-legacy.c, buildsym.h, c-lang.c,
cli/cli-decode.h, cli/cli-dump.c, cli/cli-script.h,
cli/cli-style.h, coff-pe-read.h, compile/compile-c-support.c,
compile/compile-cplus.h, compile/compile-loc2c.c, corefile.c,
cp-valprint.c, cris-linux-tdep.c, ctf.c, d-lang.c, d-namespace.c,
dcache.c, dicos-tdep.c, dictionary.c, disasm-selftests.c,
dummy-frame.c, dummy-frame.h, dwarf2-frame-tailcall.c,
dwarf2expr.c, expression.h, f-lang.c, frame-base.c,
frame-unwind.c, frv-linux-tdep.c, gdbarch-selftests.c, gdbtypes.h,
go-lang.c, hppa-nbsd-tdep.c, hppa-obsd-tdep.c, i386-dicos-tdep.c,
i386-tdep.h, ia64-vms-tdep.c, interps.h, language.c,
linux-record.c, location.h, m2-lang.c, m32r-linux-tdep.c,
mem-break.c, memattr.c, mn10300-linux-tdep.c, nios2-linux-tdep.c,
objfiles.h, opencl-lang.c, or1k-linux-tdep.c, p-lang.c,
parser-defs.h, ppc-tdep.h, probe.h, python/py-record-btrace.c,
record-btrace.c, record.h, regcache-dump.c, regcache.h,
riscv-fbsd-tdep.c, riscv-linux-tdep.c, rust-exp.y,
sh-linux-tdep.c, sh-nbsd-tdep.c, source-cache.c,
sparc-nbsd-tdep.c, sparc-obsd-tdep.c, sparc-ravenscar-thread.c,
sparc64-fbsd-tdep.c, std-regs.c, target-descriptions.h,
target-float.c, tic6x-linux-tdep.c, tilegx-linux-tdep.c, top.c,
tracefile.c, trad-frame.c, type-stack.h, ui-style.c, utils.c,
utils.h, valarith.c, valprint.c, varobj.c, x86-tdep.c,
xml-support.h, xtensa-linux-tdep.c, cli/cli-cmds.h: Update.
* s390-linux-nat.c, procfs.c, inf-ptrace.c: Likewise.
This fixes a couple of comments in gdbtypes.h. One comment had a
typo; and another comment referred to "Moto", which is presumably some
long-gone Motorola-related project.
Tested by rebuilding.
gdb/ChangeLog
2019-05-30 Tom Tromey <tromey@adacore.com>
* gdbtypes.h (struct range_bounds) <flag_upper_bound_is_count>:
Fix comment.
(TYPE_ARRAY_UPPER_BOUND_IS_UNDEFINED): Rewrite comment.
Types in Fortran can have the 'allocatable' qualifier attached to
indicate that memory needs to be explicitly allocated by the user.
This patch extends GDB to show this qualifier when printing types.
Lots of tests results are then updated to include this new qualifier
in the expected results.
gdb/ChangeLog:
* f-typeprint.c (f_type_print_base): Print 'allocatable' type
qualifier.
* gdbtypes.h (TYPE_IS_ALLOCATABLE): Define.
gdb/testsuite/ChangeLog:
* gdb.fortran/vla-datatypes.exp: Update expected results.
* gdb.fortran/vla-ptype.exp: Likewise.
* gdb.fortran/vla-type.exp: Likewise.
* gdb.fortran/vla-value.exp: Likewise.
ada-lang.c is a bit too eager trying to decode unions in the Ada style
-- looking for discriminants and such. This causes crashes when
printing a non-Ada union in Ada mode, something that can easily happen
when printing a value from history or certain registers on AArch64.
This patch fixes the bug by changing ada-lang.c to only apply special
Ada treatment to types coming from an Ada CU. This in turn required a
couple of surprising changes.
First, some of the Ada code was already using HAVE_GNAT_AUX_INFO to
decide whether a type had already been fixed -- such types had
INIT_CPLUS_SPECIFIC called on them. This patch changes these spots to
use the "none" identifier instead.
This then required changing value_rtti_type to avoid changing the
language-specific object attached to an Ada type, which seems like a
good change regardless.
Tested on x86-64 Fedora 29.
gdb/ChangeLog
2019-04-19 Tom Tromey <tromey@adacore.com>
* ada-lang.c (ada_is_variant_part, ada_to_fixed_type_1):
Check ADA_TYPE_P.
(empty_record, ada_template_to_fixed_record_type_1)
(template_to_static_fixed_type)
(to_record_with_fixed_variant_part): Use INIT_NONE_SPECIFIC.
* cp-abi.c (value_rtti_type): Check HAVE_CPLUS_STRUCT.
* gdbtypes.h (INIT_NONE_SPECIFIC, ADA_TYPE_P): New
macros.
gdb/testsuite/ChangeLog
2019-04-19 Tom Tromey <tromey@adacore.com>
* gdb.ada/ptype_union.c: New file.
* gdb.ada/ptype_union.exp: New file.
This series is revisit of Siddhesh Poyarekar's patch from back in
2012. The last status on the patch is in the following gdb-patches
thread:
https://sourceware.org/ml/gdb-patches/2012-08/msg00562.html
It appears that Tom approved the patch, but Jan had some issues
with a compiler error that made the test fail on -m32 test runs.
He wrote up a hand-tweaked .S file to deal with it. Siddesh said
he would update tests. Then nothing.
Siddesh and Jan have both moved on since.
The patch originally required a large precursor patch to work.
I have whittled this down to/rewritten the bare minimum, and this
first patch is the result, changing the type of TYPE_LENGTH
to ULONGEST from unsigned int.
The majority of the changes involve changing printf format
strings to use %s and pulongest instead of %d.
gdb/ChangeLog:
* ada-lang.c (ada_template_to_fixed_record_type_1): Use
%s/pulongest for TYPE_LENGTH instead of %d in format
strings.
* ada-typerint.c (ada_print_type): Likewise.
* amd64-windows-tdep.c (amd64_windows_store_arg_in_reg): Likewise.
* compile/compile-c-support.c (generate_register_struct): Likewise.
* gdbtypes.c (recursive_dump_type): Likewise.
* gdbtypes.h (struct type) <length>: Change type to ULONGEST.
* m2-typeprint.c (m2_array): Use %s/pulongest for TYPE_LENGTH
instead of %d in format strings.
* riscv-tdep.c (riscv_type_alignment): Cast second argument
to std::min to ULONGEST.
* symmisc.c (print_symbol): Use %s/pulongest for TYPE_LENGTH
instead of %d in format strings.
* tracepoint.c (info_scope_command): Likewise.
* typeprint.c (print_offset_data::update)
(print_offset_data::finish): Likewise.
* xtensa-tdep.c (xtensa_store_return_value)
(xtensa_push_dummy_call): Likewise.
lookup_struct_elt is a new function which returns a tuple of
information about a component of a structure or union. The returned
tuple contains a pointer to the struct field object for the component
as well as a bit offset of that field within the structure. If the
field names a field in an anonymous substructure, the offset is the
"global" offset relative to the original structure type. If noerr is
set, then the returned tuple will set the field pointer to NULL to
indicate a missing component rather than throwing an error.
lookup_struct_elt_type is now reimplemented in terms of this new
function. It simply returns the type of the returned field.
gdb/ChangeLog:
* gdbtypes.c (lookup_struct_elt): New function.
(lookup_struct_elt_type): Reimplement via lookup_struct_elt.
* gdbtypes.h (struct struct_elt): New type.
(lookup_struct_elt): New prototype.
This commit applies all changes made after running the gdb/copyright.py
script.
Note that one file was flagged by the script, due to an invalid
copyright header
(gdb/unittests/basic_string_view/element_access/char/empty.cc).
As the file was copied from GCC's libstdc++-v3 testsuite, this commit
leaves this file untouched for the time being; a patch to fix the header
was sent to gcc-patches first.
gdb/ChangeLog:
Update copyright year range in all GDB files.
badness_vector is currently an open coded vector. This reimplements
it as a std::vector.
This fixes a few leaks as well:
- find_oload_champ is leaking every badness vector calculated bar the
one returned.
- bv->rank is always leaked, since callers of rank_function only
xfree the badness_vector pointer, not bv->rank.
gdb/ChangeLog:
2018-11-21 Pedro Alves <palves@redhat.com>
* gdbtypes.c (compare_badness): Change type of parameters to const
reference. Adjust to badness_vector being a std::vector now.
(rank_function): Adjust to badness_vector being a std::vector now.
* gdbtypes.h (badness_vector): Now a typedef to std::vector.
(LENGTH_MATCH): Delete.
(compare_badness): Change type of parameters to const reference.
(rank_function): Return a badness_vector by value now.
(find_overload_match): Adjust to badness_vector being a
std::vector now. Remove cleanups.
(find_oload_champ_namespace): 'oload_champ_bv' parameter now a
badness_vector pointer.
(find_oload_champ_namespace_loop): 'oload_champ_bv' parameter now
a badness_vector pointer. Adjust to badness_vector being a
std::vector now. Remove cleanups.
(find_oload_champ): 'oload_champ_bv' parameter now
a badness_vector pointer. Adjust to badness_vector being a
std::vector now. Remove cleanups.
This replaces more pointer+length with gdb::array_view. This time,
around invoke_xmethod, and then propagating the fallout around, which
inevitably leaks to the overload resolution code.
There are several places in the code that want to grab a slice of an
array, by advancing the array pointer, and decreasing the length
pointer. This patch introduces a pair of new
gdb::array_view::slice(...) methods to make that convenient and clear.
Unit test included.
gdb/ChangeLog:
2018-11-21 Pedro Alves <palves@redhat.com>
* common/array-view.h (array_view::splice(size_type, size_t)): New.
(array_view::splice(size_type)): New.
* eval.c (eval_call, evaluate_funcall): Adjust to use array_view.
* extension.c (xmethod_worker::get_arg_types): Adjust to return an
std::vector.
(xmethod_worker::get_result_type): Adjust to use gdb::array_view.
* extension.h: Include "common/array-view.h".
(xmethod_worker::invoke): Adjust to use gdb::array_view.
(xmethod_worker::get_arg_types): Adjust to return an std::vector.
(xmethod_worker::get_result_type): Adjust to use gdb::array_view.
(xmethod_worker::do_get_arg_types): Adjust to use std::vector.
(xmethod_worker::do_get_result_type): Adjust to use
gdb::array_view.
* gdbtypes.c (rank_function): Adjust to use gdb::array_view.
* gdbtypes.h: Include "common/array-view.h".
(rank_function): Adjust to use gdb::array_view.
* python/py-xmethods.c (python_xmethod_worker::invoke)
(python_xmethod_worker::do_get_arg_types)
(python_xmethod_worker::do_get_result_type)
(python_xmethod_worker::invoke): Adjust to new interfaces.
* valarith.c (value_user_defined_cpp_op, value_user_defined_op)
(value_x_binop, value_x_unop): Adjust to use gdb::array_view.
* valops.c (find_overload_match, find_oload_champ_namespace)
(find_oload_champ_namespace_loop, find_oload_champ): Adjust to use
gdb:array_view and the new xmethod_worker interfaces.
* value.c (result_type_of_xmethod, call_xmethod): Adjust to use
gdb::array_view.
* value.h (find_overload_match, result_type_of_xmethod)
(call_xmethod): Adjust to use gdb::array_view.
* unittests/array-view-selftests.c: Add slicing tests.
-fsanitize=undefined complains about using operator~ on various enum
types that are used with DEF_ENUM_FLAGS_TYPE. This patch fixes these
problems by explicitly setting the base type for these enums to
unsigned. It also adds a static assert to enum_flags to ensure that
future enums used this way have an unsigned underlying type.
gdb/ChangeLog
2018-10-03 Tom Tromey <tom@tromey.com>
* common/enum-flags.h (enum_flags::operator~): Add static assert.
* symfile-add-flags.h (enum symfile_add_flag): Use unsigned as
base type.
* objfile-flags.h (enum objfile_flag): Use unsigned as base type.
* gdbtypes.h (enum type_instance_flag_value): Use unsigned as base
type.
* c-lang.h (enum c_string_type_values): Use unsigned as base
type.
* btrace.h (enum btrace_thread_flag): Use unsigned as base type.
This patch started as an observation from valgrind that GDB appeared
to be loosing track of some memory associated with types. An example
valgrind stack would be:
24 bytes in 1 blocks are possibly lost in loss record 419 of 5,361
at 0x4C2EA1E: calloc (vg_replace_malloc.c:711)
by 0x623D26: xcalloc (common-utils.c:85)
by 0x623D65: xzalloc(unsigned long) (common-utils.c:95)
by 0x72A066: make_function_type(type*, type**) (gdbtypes.c:510)
by 0x72A098: lookup_function_type(type*) (gdbtypes.c:521)
by 0x73635D: gdbtypes_post_init(gdbarch*) (gdbtypes.c:5439)
by 0x727590: gdbarch_data(gdbarch*, gdbarch_data*) (gdbarch.c:5230)
by 0x735B99: builtin_type(gdbarch*) (gdbtypes.c:5313)
by 0x514D95: elf_rel_plt_read(minimal_symbol_reader&, objfile*, bfd_symbol**) (elfread.c:542)
by 0x51662F: elf_read_minimal_symbols(objfile*, int, elfinfo const*) (elfread.c:1121)
by 0x5168A5: elf_symfile_read(objfile*, enum_flags<symfile_add_flag>) (elfread.c:1207)
by 0x8520F5: read_symbols(objfile*, enum_flags<symfile_add_flag>) (symfile.c:794)
When we look in make_function_type we find a call to TYPE_ZALLOC
(inside the INIT_FUNC_SPECIFIC macro). It is this call to TYPE_ZALLOC
that is allocating memory with xcalloc, that is then getting lost.
The problem is tht calling TYPE_ALLOC or TYPE_ZALLOC currently
allocates memory from either the objfile obstack or by using malloc.
The problem with this is that types are allocated either on the
objfile obstack, or on the gdbarch obstack.
As a result, if we discard a type associated with an objfile then
auxiliary data allocated with TYPE_(Z)ALLOC will be correctly
discarded. But, if we were ever to discard a gdbarch then any
auxiliary type data would be leaked. Right now there are very few
places in GDB where a gdbarch is ever discarded, but it shouldn't hurt
to close down these bugs as we spot them.
This commit ensures that auxiliary type data is allocated from the
same obstack as the type itself, which should reduce leaked memory.
The one problem case that I found with this change was in eval.c,
where in one place we allocate a local type structure, and then used
TYPE_ZALLOC to allocate some space for the type. This local type is
neither object file owned, nor gdbarch owned, and so the updated
TYPE_ALLOC code is unable to find an objstack to allocate space on.
My proposed solution for this issue is that the space should be
allocated with a direct call to xzalloc. We could extend TYPE_ALLOC
to check for type->gdbarch being null, and then fall back to a direct
call to xzalloc, however, I think that making this rare case of a
local type require special handling is not a bad thing, this serves to
highlight that clearing up the memory will require special handling
too.
This special case of a local type is interesting as the types owner
field (contained within the main_type) is completely null. While
reflecting on this I looked at how types use the get_type_arch
function. It seems clear that, based on how this is used, it is never
intended that null will be returned from this function. This only
goes to reinforce, how locally alloctaed types, with no owner, are
both special, and need to be handled carefully. To help spot errors
earlier, I added an assert into get_type_arch that the returned arch
is not null.
Inside gdbarch.c I found a few other places where auxiliary type data
was being allocated directly on the heap rather than on the types
obstack. I have fixed these to call TYPE_ALLOC now.
Finally, it is worth noting that as we don't clean up our gdbarch
objects yet, then this will not make much of an impact on the amount
of memory reported as lost at program termination time. Memory
allocated for auxiliary type information is still not freed, however,
it is now on the correct obstack. If we do ever start freeing our
gdbarch structures then the associated type data will be cleaned up
correctly.
Tested on X86-64 GNU/Linux with no regressions.
gdb/ChangeLog:
* eval.c (fake_method::fake_method): Call xzalloc directly for a
type that is neither object file owned, nor gdbarch owned.
* gdbtypes.c (get_type_gdbarch): Add an assert that returned
gdbarch is non-NULL.
(alloc_type_instance): Allocate non-objfile owned types on the
gdbarch obstack.
(copy_type_recursive): Allocate TYPE_FIELDS and TYPE_RANGE_DATA
using TYPE_ALLOC to ensure memory is allocated on the correct
obstack.
* gdbtypes.h (TYPE_ALLOC): Allocate space on either the objfile
obstack, or the gdbarch obstack.
(TYPE_ZALLOC): Rewrite using TYPE_ALLOC.
Add int24 and uint24. These are used by the upcoming S12Z target, but will be
needed for any arch which features 24 bit registers.
* gdb/gdbtypes.h (struct builtin_type): New members builtin_int24
and builtin_uint24;
* gdb/gdbtypes.c: Initialize them.
* gdb/doc/gdb.texinfo (Predefined Target Types): Mention types int24 and uint24.
TYPE_TAG_NAME has been an occasional source of confusion and bugs. It
seems to me that it is only useful for C and C++ -- but even there,
not so much, because at least with DWARF there doesn't seem to be any
way to wind up with a type where the name and the tag name are both
non-NULL and different.
So, this patch removes TYPE_TAG_NAME entirely. This should save a
little memory, but more importantly, it simplifies this part of gdb.
A few minor test suite adjustments were needed. In some situations
the new code does not yield identical output to the old code.
gdb/ChangeLog
2018-06-01 Tom Tromey <tom@tromey.com>
* valops.c (enum_constant_from_type, value_namespace_elt)
(value_maybe_namespace_elt): Update.
* valarith.c (find_size_for_pointer_math): Update.
* target-descriptions.c (make_gdb_type): Update.
* symmisc.c (print_symbol): Update.
* stabsread.c (define_symbol, read_type)
(complain_about_struct_wipeout, add_undefined_type)
(cleanup_undefined_types_1): Update.
* rust-lang.c (rust_tuple_type_p, rust_slice_type_p)
(rust_range_type_p, val_print_struct, rust_print_struct_def)
(rust_internal_print_type, rust_composite_type)
(rust_evaluate_funcall, rust_evaluate_subexp)
(rust_inclusive_range_type_p): Update.
* python/py-type.c (typy_get_tag): Update.
* p-typeprint.c (pascal_type_print_base): Update.
* mdebugread.c (parse_symbol, parse_type): Update.
* m2-typeprint.c (m2_long_set, m2_record_fields, m2_enum):
Update.
* guile/scm-type.c (gdbscm_type_tag): Update.
* go-lang.c (sixg_string_p): Update.
* gnu-v3-abi.c (build_gdb_vtable_type, build_std_type_info_type):
Update.
* gdbtypes.h (struct main_type) <tag_name>: Remove.
(TYPE_TAG_NAME): Remove.
* gdbtypes.c (type_name_no_tag): Simplify.
(check_typedef, check_types_equal, recursive_dump_type)
(copy_type_recursive, arch_composite_type): Update.
* f-typeprint.c (f_type_print_base): Update. Print "Type" prefix
in summary mode when needed.
* eval.c (evaluate_funcall): Update.
* dwarf2read.c (fixup_go_packaging, read_structure_type)
(process_structure_scope, read_enumeration_type)
(read_namespace_type, read_module_type, determine_prefix): Update.
* cp-support.c (inspect_type): Update.
* coffread.c (process_coff_symbol, decode_base_type): Update.
* c-varobj.c (c_is_path_expr_parent): Update.
* c-typeprint.c (c_type_print_base_struct_union): Update.
(c_type_print_base_1): Update. Print struct/class/union/enum in
summary when using C language.
* ax-gdb.c (gen_struct_ref, gen_namespace_elt)
(gen_maybe_namespace_elt): Update.
* ada-lang.c (ada_type_name): Simplify.
(empty_record, ada_template_to_fixed_record_type_1)
(template_to_static_fixed_type)
(to_record_with_fixed_variant_part, ada_check_typedef): Update.
gdb/testsuite/ChangeLog
2018-06-01 Tom Tromey <tom@tromey.com>
* gdb.xml/tdesc-regs.exp (load_description): Update expected
results.
* gdb.dwarf2/method-ptr.exp: Set language to C++.
* gdb.dwarf2/member-ptr-forwardref.exp: Set language to C++.
* gdb.cp/typeid.exp (do_typeid_tests): Update type_re.
* gdb.base/maint.exp (maint_pass_if): Update.
This removes a VEC from type.c, by using std::vector.
While doing this I also took the opportunity to change
types_deeply_equal to return bool. This caught some weird code in
typy_richcompare, now fixed.
And, since I was changing types_deeply_equal, it seemed like a good
idea to also change types_equal, so this patch includes that as well.
Tested by the buildbot.
ChangeLog
2018-05-29 Tom Tromey <tom@tromey.com>
* python/py-type.c (typy_richcompare): Update.
* guile/scm-type.c (tyscm_equal_p_type_smob): Update.
* gdbtypes.h (types_deeply_equal): Return bool.
(types_equal): Likewise.
* gdbtypes.c (type_equality_entry_d): Remove typedef. Don't
declare VEC.
(check_types_equal): Change worklist to std::vector. Return
bool.
(struct type_equality_entry): Add constructor.
(compare_maybe_null_strings): Return bool.
(check_types_worklist): Return bool. Change worklist to
std::vector.
(types_deeply_equal): Use std::vector.
(types_equal): Return bool.
(compare_maybe_null_strings): Simplify.
This adds some basic type alignment support to gdb. It changes struct
type to store the alignment, and updates dwarf2read.c to handle
DW_AT_alignment. It also adds a new gdbarch method and updates
i386-tdep.c.
None of this new functionality is used anywhere yet, so tests will
wait until the next patch.
2018-04-30 Tom Tromey <tom@tromey.com>
* i386-tdep.c (i386_type_align): New function.
(i386_gdbarch_init): Update.
* gdbarch.sh (type_align): New method.
* gdbarch.c, gdbarch.h: Rebuild.
* arch-utils.h (default_type_align): Declare.
* arch-utils.c (default_type_align): New function.
* gdbtypes.h (TYPE_ALIGN_BITS): New define.
(struct type) <align_log2>: New field.
<instance_flags>: Now a bitfield.
(TYPE_RAW_ALIGN): New macro.
(type_align, type_raw_align, set_type_align): Declare.
* gdbtypes.c (type_align, type_raw_align, set_type_align): New
functions.
* dwarf2read.c (quirk_rust_enum): Set type alignment.
(get_alignment, maybe_set_alignment): New functions.
(read_structure_type, read_enumeration_type, read_array_type)
(read_set_type, read_tag_pointer_type, read_tag_reference_type)
(read_subrange_type, read_base_type): Set type alignment.
This adds some initial support for variant parts to gdbtypes.h. A
variant part is represented as a union. The union has a flag
indicating that it has a discriminant, and information about the
discriminant is attached using the dynamic property system.
2018-02-26 Tom Tromey <tom@tromey.com>
* value.h (value_union_variant): Declare.
* valops.c (value_union_variant): New function.
* gdbtypes.h (TYPE_FLAG_DISCRIMINATED_UNION): New macro.
(struct discriminant_info): New.
(enum dynamic_prop_node_kind) <DYN_PROP_DISCRIMINATED>: New
enumerator.
(struct main_type) <flag_discriminated_union>: New field.
Does anybody have an opinion about this? It would be nice to unbreak
the "default" build with clang (i.e. without passing special -Wno-error=
flags).
Here's a version rebased on today's master.
From 47d28075117fa2ddb93584ec50881e33777a85e5 Mon Sep 17 00:00:00 2001
From: Simon Marchi <simon.marchi@ericsson.com>
Date: Sat, 30 Dec 2017 22:48:18 -0500
Subject: [PATCH] dwarf: Make sect_offset 64-bits
Compiling with Clang 6 shows these errors:
/home/emaisin/src/binutils-gdb/gdb/dwarf2read.c:26610:43: error: result of comparison of constant 4294967296 with expression of type 'typename std::underlying_type<sect_offset>::type' (a
ka 'unsigned int') is always false [-Werror,-Wtautological-constant-out-of-range-compare]
if (to_underlying (per_cu.sect_off) >= (static_cast<uint64_t> (1) << 32))
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/emaisin/src/binutils-gdb/gdb/dwarf2read.c:26618:43: error: result of comparison of constant 4294967296 with expression of type 'typename std::underlying_type<sect_offset>::type' (a
ka 'unsigned int') is always false [-Werror,-Wtautological-constant-out-of-range-compare]
if (to_underlying (per_cu.sect_off) >= (static_cast<uint64_t> (1) << 32))
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The code in question checks if there is any offset exceeding 32 bits,
and therefore if we need to use the 64-bit DWARF format when writing the
.debug_names section. The type we use currently to represent section
offsets is an unsigned int (32-bits), which means a value of this type
will never exceed 32 bits, hence the errors above.
There are many signs that we want to support 64-bits DWARF (although I
haven't tested), such as:
- We correctly read initial length fields (read_initial_length)
- We take that into account when reading offsets (read_offset_1)
- The check_dwarf64_offsets function
However, I don't see how it can work if sect_offset is a 32-bits type.
Every time we record a section offset, we risk truncating the value.
And if a file uses the 64-bit DWARF format, it's most likely because
there are such offset values that overflow 32 bits.
Because of this, I think the way forward is to change sect_offset to be
a uint64_t. It will be able to represent any offset, regardless of the
bitness of the DWARF info.
This patch was regtested on the buildbot.
gdb/ChangeLog:
* gdbtypes.h (sect_offset): Change type to uint64_t.
(sect_offset_str): New function.
* dwarf2read.c (create_addrmap_from_aranges): Use
sect_offset_str.
(error_check_comp_unit_head): Likewise.
(create_debug_type_hash_table): Likewise.
(read_cutu_die_from_dwo): Likewise.
(init_cutu_and_read_dies): Likewise.
(init_cutu_and_read_dies_no_follow): Likewise.
(process_psymtab_comp_unit_reader): Likewise.
(partial_die_parent_scope): Likewise.
(peek_die_abbrev): Likewise.
(process_queue): Likewise.
(dwarf2_physname): Likewise.
(read_namespace_alias): Likewise.
(read_import_statement): Likewise.
(create_dwo_cu_reader): Likewise.
(create_cus_hash_table): Likewise.
(lookup_dwo_cutu): Likewise.
(inherit_abstract_dies): Likewise.
(read_func_scope): Likewise.
(read_call_site_scope): Likewise.
(dwarf2_add_member_fn): Likewise.
(read_common_block): Likewise.
(read_module_type): Likewise.
(read_typedef): Likewise.
(read_subrange_type): Likewise.
(load_partial_dies): Likewise.
(read_partial_die): Likewise.
(find_partial_die): Likewise.
(read_str_index): Likewise.
(dwarf2_string_attr): Likewise.
(build_error_marker_type): Likewise.
(lookup_die_type): Likewise.
(dump_die_shallow): Likewise.
(follow_die_ref): Likewise.
(dwarf2_fetch_die_loc_sect_off): Likewise.
(dwarf2_fetch_constant_bytes): Likewise.
(follow_die_sig): Likewise.
(get_signatured_type): Likewise.
(get_DW_AT_signature_type): Likewise.
(dwarf2_find_containing_comp_unit): Likewise.
(set_die_type): Likewise.
GCC PR83906 [1] is about a GCC/libstdc++ GDB/Python type printer
testcase failing randomly, as shown by running (in libstdc++'s
testsuite):
make check RUNTESTFLAGS=prettyprinters.exp=80276.cc
in a loop. Sometimes you get this:
FAIL: libstdc++-prettyprinters/80276.cc whatis p4
I.e., this:
type = std::unique_ptr<std::vector<std::unique_ptr<std::list<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >>[]>>[99]>
instead of this:
type = std::unique_ptr<std::vector<std::unique_ptr<std::list<std::string>[]>>[99]>
Jonathan Wakely tracked it on the printer side to this bit in
libstdc++'s type printer:
if self.type_obj == type_obj:
return strip_inline_namespaces(self.name)
This assumes the two types resolve to the same gdb.Type but some times
the comparison unexpectedly fails.
Running the testcase manually under Valgrind finds the problem in GDB:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
==6118== Conditional jump or move depends on uninitialised value(s)
==6118== at 0x4C35CB0: bcmp (vg_replace_strmem.c:1100)
==6118== by 0x6F773A: check_types_equal(type*, type*, VEC_type_equality_entry_d**) (gdbtypes.c:3515)
==6118== by 0x6F7B00: check_types_worklist(VEC_type_equality_entry_d**, bcache*) (gdbtypes.c:3618)
==6118== by 0x6F7C03: types_deeply_equal(type*, type*) (gdbtypes.c:3655)
==6118== by 0x4D5B06: typy_richcompare(_object*, _object*, int) (py-type.c:1007)
==6118== by 0x63D7E6C: PyObject_RichCompare (object.c:961)
==6118== by 0x646EAEC: PyEval_EvalFrameEx (ceval.c:4960)
==6118== by 0x646DC08: PyEval_EvalFrameEx (ceval.c:4519)
==6118== by 0x646DC08: PyEval_EvalFrameEx (ceval.c:4519)
==6118== by 0x646DC08: PyEval_EvalFrameEx (ceval.c:4519)
==6118== by 0x646DC08: PyEval_EvalFrameEx (ceval.c:4519)
==6118== by 0x646DC08: PyEval_EvalFrameEx (ceval.c:4519)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
That "bcmp" call is really a memcmp call in check_types_equal. The
problem is that gdb is memcmp'ing two objects that are equal in value:
(top-gdb) p *TYPE_RANGE_DATA (type1)
$1 = {low = {kind = PROP_CONST, data = {const_val = 0, baton = 0x0}}, high = {kind = PROP_CONST, data = {const_val = 15, baton = 0xf}}, flag_upper_bound_is_count = 0,
flag_bound_evaluated = 0}
(top-gdb) p *TYPE_RANGE_DATA (type2)
$2 = {low = {kind = PROP_CONST, data = {const_val = 0, baton = 0x0}}, high = {kind = PROP_CONST, data = {const_val = 15, baton = 0xf}}, flag_upper_bound_is_count = 0,
flag_bound_evaluated = 0}
but differ in padding. Notice the 4-byte hole:
(top-gdb) ptype /o range_bounds
/* offset | size */ type = struct range_bounds {
/* 0 | 16 */ struct dynamic_prop {
/* 0 | 4 */ dynamic_prop_kind kind;
/* XXX 4-byte hole */
/* 8 | 8 */ union dynamic_prop_data {
/* 8 */ LONGEST const_val;
/* 8 */ void *baton;
/* total size (bytes): 8 */
} data;
which is filled with garbage:
(top-gdb) x /40bx TYPE_RANGE_DATA (type1)
0x2fa7ea0: 0x01 0x00 0x00 0x00 0x43 0x01 0x00 0x00
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
0x2fa7ea8: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x2fa7eb0: 0x01 0x00 0x00 0x00 0xfe 0x7f 0x00 0x00
0x2fa7eb8: 0x0f 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x2fa7ec0: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
(top-gdb) x /40bx TYPE_RANGE_DATA (type2)
0x20379b0: 0x01 0x00 0x00 0x00 0xfe 0x7f 0x00 0x00
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
0x20379b8: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x20379c0: 0x01 0x00 0x00 0x00 0xfe 0x7f 0x00 0x00
0x20379c8: 0x0f 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x20379d0: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
(top-gdb) p memcmp (TYPE_RANGE_DATA (type1), TYPE_RANGE_DATA (type2), sizeof (*TYPE_RANGE_DATA (type1)))
$3 = -187
In some cases objects of type range_bounds are memset when allocated,
but then their dynamic_prop low/high fields are copied over from some
template dynamic_prop object that wasn't memset. E.g.,
create_static_range_type's low/high locals are left with garbage in
the padding, and then that padding is copied over to the range_bounds
object's low/high fields.
At first, I considered making sure to always memset range_bounds
objects, thinking that maybe type objects are being put in some bcache
instance somewhere. But then I hacked bcache/bcache_full to poison
non-pod types, and made dynamic_prop a non-pod, and GDB still
compiled.
So given that, it seems safest to not assume padding will always be
memset, and instead treat them as regular value types, implementing
(in)equality operators and using those instead of memcmp.
This fixes the random FAILs in GCC's testcase.
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83906
gdb/ChangeLog:
2018-01-24 Pedro Alves <palves@redhat.com>
GCC PR libstdc++/83906
* gdbtypes.c (operator==(const dynamic_prop &,
const dynamic_prop &)): New.
(operator==(const range_bounds &, const range_bounds &)): New.
(check_types_equal): Use them instead of memcmp.
* gdbtypes.h (operator==(const dynamic_prop &,
const dynamic_prop &)): Declare.
(operator!=(const dynamic_prop &, const dynamic_prop &)): Declare.
(operator==(const range_bounds &, const range_bounds &)): Declare.
(operator!=(const range_bounds &, const range_bounds &)): Declare.
The objfile argument to add_dyn_prop is redundant, so this patch
removes it.
2018-01-17 Tom Tromey <tom@tromey.com>
* gdbtypes.h (add_dyn_prop): Remove objfile parameter.
* gdbtypes.c (add_dyn_prop): Remove objfile parameter.
(create_array_type_with_stride): Update.
* dwarf2read.c (set_die_type): Update.
This patch adds support for DW_AT_byte_stride, using Ada as one
example of where this would be useful. However, the implementation
is language-agnostic.
Consider the following Ada code:
procedure Nested (L, U : Integer) is
subtype Small_Type is Integer range L .. U;
type Record_Type (I : Small_Type := L) is record
S : String (1 .. I);
end record;
type Array_Type is array (Integer range <>) of Record_Type;
A1 : Array_Type :=
(1 => (I => 0, S => <>),
2 => (I => 1, S => "A"),
3 => (I => 2, S => "AB"));
procedure Discard (R : Record_Type) is
begin
null;
end Discard;
begin
Discard (A1 (1)); -- STOP
end;
It defines an array A1 of Record_Type, which is a variant record
type whose maximum size actually depends on the value of the
parameters passed when calling Nested. As a result, the stride
of the array A1 cannot be known statically, which leads the compiler
to generate a dynamic DW_AT_byte_stride attribute for our type.
Here is what the debugging info looks like with GNAT:
.uleb128 0x10 # (DIE (0x14e) DW_TAG_array_type)
.long .LASF17 # DW_AT_name: "foo__nested__T18b"
.long 0x141 # DW_AT_byte_stride
.long 0xdc # DW_AT_type
.uleb128 0x11 # (DIE (0x15f) DW_TAG_subrange_type)
.long 0x166 # DW_AT_type
.byte 0x3 # DW_AT_upper_bound
.byte 0 # end of children of DIE 0x14e
There DW_AT_byte_stride is a reference to a local (internal)
variable:
.uleb128 0x9 # (DIE (0x141) DW_TAG_variable)
.long .LASF6 # DW_AT_name: "foo__nested__T18b___PAD___XVZ"
This patch enhances GDB to handle this dynamic byte stride attribute
by first adding a new dynamic_prop_node_kind (DYN_PROP_BYTE_STRIDE)
to store the array dynamic stride info (when dynamic). It then enhances
the dynamic type resolver to handle this dynamic property.
Before applying this patch, trying to print the value of some of
A1's elements after having stopped at the "STOP" comment does not
work. For instance:
(gdb) p a1(2)
Cannot access memory at address 0x80000268dec0
With this patch applied, GDB now prints the value of all 3 elements
correctly:
(gdb) print A1(1)
$1 = (i => 0, s => "")
(gdb) print A1(2)
$2 = (i => 1, s => "A")
(gdb) print A1(3)
$3 = (i => 2, s => "AB")
gdb/ChangeLog:
* gdbtypes.h (enum dynamic_prop_node_kind) <DYN_PROP_BYTE_STRIDE>:
New enum value.
(create_array_type_with_stride): Add byte_stride_prop parameter.
* gdbtypes.c (create_array_type_with_stride) <byte_stride_prop>:
New parameter. Update all callers in this file.
(array_type_has_dynamic_stride): New function.
(is_dynamic_type_internal, resolve_dynamic_array): Add handling
of arrays with dynamic byte strides.
* dwarf2read.c (read_array_type): Add support for dynamic
DW_AT_byte_stride attributes.
gdb/testsuite/ChangeLog:
* gdb.ada/dyn_stride: New testcase.
Tested on x86_64-linux.
GDB currently does not track types defined in classes. Consider:
class A
{
public:
class B
{
public:
class C { };
};
};
(gdb) ptype A
type = class A {
<no data fields>
}
This patch changes this behavior so that GDB records these nested types
and displays them to the user when he has set the (new) "print type"
option "nested-type-limit."
Example:
(gdb) set print type nested-type-limit 1
(gdb) ptype A
type = class A {
<no data fields>
class A::B {
<no data fields>
};
}
(gdb) set print type nested-type-limit 2
type = class A {
<no data fields>
class A::B {
<no data fields>
class A::B::C {
<no data fields>
};
};
}
By default, the code maintains the status quo, that is, it will not print
any nested type definitions at all.
Testing is carried out via cp_ptype_class which required quite a bit of
modification to permit recursive calling (for the nested types). This
was most easily facilitated by turning the ptype command output into a
queue. Upshot: the test suite now has stack and queue data structures that
may be used by test writers.
gdb/ChangeLog
* NEWS (New commands): Mention set/show print type nested-type-limit.
* c-typeprint.c (c_type_print_base): Print out nested types.
* dwarf2read.c (struct typedef_field_list): Rename to ...
(struct decl_field_list): ... this. Change all uses.
(struct field_info) <nested_types_list, nested_types_list_count>:
New fields.
(add_partial_symbol): Look for nested type definitions in C++, too.
(dwarf2_add_typedef): Rename to ...
(dwarf2_add_type_defn): ... this.
(type_can_define_types): New function.
Update assertion to use type_can_define_types.
Permit NULL for a field's name.
(process_structure_scope): Handle child DIEs of types that can
define types.
Copy the list of nested types into the type struct.
* gdbtypes.h (struct typedef_field): Rename to ...
(struct decl_field): ... this. Change all uses.
[is_protected, is_private]: New fields.
(struct cplus_struct_type) <nested_types, nested_types_count>: New
fields.
(TYPE_NESTED_TYPES_ARRAY, TYPE_NESTED_TYPES_FIELD)
(TYPE_NESTED_TYPES_FIELD_NAME, TYPE_NESTED_TYPES_FIELD_TYPE)
(TYPE_NESTED_TYPES_COUNT, TYPE_NESTED_TYPES_FIELD_PROTECTED)
(TYPE_NESTED_TYPES_FIELD_PRIVATE): New macros.
* typeprint.c (type_print_raw_options, default_ptype_flags): Add
default value for print_nested_type_limit.
(print_nested_type_limit): New static variable.
(set_print_type_nested_types, show_print_type_nested_types): New
functions.
(_initialize_typeprint): Register new commands for set/show
`print-nested-type-limit'.
* typeprint.h (struct type_print_options) [print_nested_type_limit]:
New field.
gdb/testsuite/ChangeLog
* gdb.cp/nested-types.cc: New file.
* gdb.cp/nested-types.exp: New file.
* lib/cp-support.exp: Load data-structures.exp library.
(debug_cp_test_ptype_class): New global.
(cp_ptype_class_verbose, next_line): New procedures.
(cp_test_ptype_class): Add and document new parameter `recursive_qid'.
Add and document new return value.
Switch the list of lines to a queue.
Add support for new `type' key for nested type definitions.
Add debugging/troubleshooting messages.
* lib/data-structures.exp: New file.
gdb/doc/ChangeLog
* gdb.texinfo (Symbols): Document "set print type nested-type-limit"
and "show print type nested-type-limit".
This patch introduces the new set of target floating-point handling routines
in target-float.{c,h}. In the end, the intention is that this file will
contain support for all operations in target FP format, fully replacing
both the current doublest.{c,h} and dfp.{c,h}.
To begin with, this patch only adds a target_float_is_zero routine,
which handles the equivalent of decimal_is_zero for both binary and
decimal FP. For the binary case, to avoid conversion to DOUBLEST,
this is implemented using the floatformat_classify routine.
However, it turns out that floatformat_classify actually has a bug
(it was not used to check for zero before), so this is fixed as well.
The new routine is used in both value_logical_not and valpy_nonzero.
There is one extra twist: the code previously used value_as_double
to convert to DOUBLEST and then compare against zero. That routine
performs an extra task: it detects invalid floating-point values
and raises an error. In any place where value_as_double is removed
in favor of some target-float.c routine, we need to replace that check.
To keep this check centralized in one place, I've added a new routine
is_floating_value, which returns a boolean determining whether a
value's type is floating point (binary or decimal), and if so, also
performs the validity check. Since we need to check whether a value
is FP before calling any of the target-float routines anyway, this
seems a good place to add the check without much code size overhead.
In some places where we only want to check for floating-point types
and not perform a validity check (e.g. for the *output* of an operation),
we can use the new is_floating_type routine (in gdbarch) instead.
The validity check itself is done by a new target_float_is_valid
routine in target-float, encapsulating floatformat_is_valid.
ChangeLog:
2017-11-06 Ulrich Weigand <uweigand@de.ibm.com>
* Makefile.c (SFILES): Add target-float.c.
(HFILES_NO_SRCDIR): Add target-float.h.
(COMMON_OBS): Add target-float.o.
* target-float.h: New file.
* target-float.c: New file.
* doublest.c (floatformat_classify): Fix detection of float_zero.
* gdbtypes.c (is_floating_type): New function.
* gdbtypes.h (is_floating_type): Add prototype.
* value.c: Do not include "floatformat.h".
(unpack_double): Use target_float_is_valid.
(is_floating_value): New function.
* value.h (is_floating_value): Add prototype-
* valarith.c: Include "target-float.h".
(value_logical_not): Use target_float_is_zero.
* python/py-value.c: Include "target-float.h".
(valpy_nonzero): Use target_float_is_zero.
We currently do not record access information for typedefs defined inside
classes. Consider:
struct foo
{
typedef int PUBLIC;
private:
typedef int PRIVATE;
PRIVATE b;
};
(gdb) ptype foo
type = struct foo {
private:
PRIVATE b;
typedef int PRIVATE;
typedef int PUBLIC;
}
This patch fixes this:
(gdb) ptype foo
type = struct foo {
private:
PRIVATE b;
typedef int PRIVATE;
public:
typedef int PUBLIC;
}
gdb/ChangeLog:
* c-typeprint.c (enum access_specifier): Moved here from
c_type_print_base.
(output_access_specifier): New function.
(c_type_print_base): Consider typedefs when assessing
whether access labels are needed.
Use output_access_specifier as needed.
Output access specifier for typedefs, if needed.
* dwarf2read.c (dwarf2_add_typedef): Record DW_AT_accessibility.
* gdbtypes.h (struct typedef_field) <is_protected, is_private>: New
fields.
(TYPE_TYPEDEF_FIELD_PROTECTED, TYPE_TYPEDEF_FIELD_PRIVATE): New
accessor macros.
gdb/testsuite/ChangeLog:
* gdb.cp/classes.cc (class_with_typedefs, class_with_public_typedef)
(class_with_protected_typedef, class_with_private_typedef)
(struct_with_public_typedef, struct_with_protected_typedef)
(struct_with_private_typedef): New classes/structs.
* gdb.cp/classes.exp (test_ptype_class_objects): Add tests for
typedefs and access specifiers.
For historical reasons, the TYPE_FLOATFORMAT element is still set to hold
an array of two floatformat structs, one for big-endian and the other for
little-endian. When accessing the element via floatformat_from_type,
the code would check the type's byte order and return the appropriate
floatformat.
However, these days this is quite unnecessary, since the type's byte order
is already known at the time the type is allocated and the floatformat is
installed into TYPE_FLOATFORMAT. Therefore, we can just install the correct
version here.
Also, moves the (now trivially simple) floatformat_from_type accessor to
gdbtypes.{c,h}, since it doesn't really need to be in doublest.c now.
gdb/ChangeLog
2017-09-27 Ulrich Weigand <uweigand@de.ibm.com>
* doublest.h (floatformat_from_type): Move to gdbtypes.h.
* doublest.c (floatformat_from_type): Move to gdbtypes.c.
* gdbtypes.h (union type_specific): Make field floatformat hold
just a single struct floatformat, not an array.
(floatformat_from_type): Move here.
* gdbtypes.c (floatformat_from_type): Move here. Update to
changed TYPE_FLOATFORMAT definition.
(verify_floatformat): Update to changed TYPE_FLOATFORMAT.
(recursive_dump_type): Likewise.
(init_float_type): Install correct floatformat for byte order.
(arch_float_type): Likewise.
This changes the interfaces to init_type and arch_type to take the
type length in bits as input (instead of as bytes). The routines
assert that the length is a multiple of TARGET_CHAR_BIT.
For consistency, arch_flags_type is changed likewise, so that now
all type creation interfaces always use length in bits.
All callers are updated in the straightforward manner.
The assert actually found a bug in read_range_type, where the
init_integer_type routine was called with a wrong argument (probably
a bug introduced with the conversion to use init_integer_type).
gdb/ChangeLog
2017-09-27 Ulrich Weigand <uweigand@de.ibm.com>
* gdbtypes.c (init_type): Change incoming argument from
length-in-bytes to length-in-bits. Assert length is a
multiple of TARGET_CHAR_BITS.
(arch_type, arch_flags_type): Likewise.
(init_integer_type): Update call to init_type.
(init_character_type): Likewise.
(init_boolean_type): Likewise.
(init_float_type): Likewise.
(init_decfloat_type): Likewise.
(init_complex_type): Likewise.
(init_pointer_type): Likewise.
(objfile_type): Likewise.
(arch_integer_type): Update call to arch_type.
(arch_character_type): Likewise.
(arch_boolean_type): Likewise.
(arch_float_type): Likewise.
(arch_decfloat_type): Likewise.
(arch_complex_type): Likewise.
(arch_pointer_type): Likewise.
(gdbtypes_post_init): Likewise.
* dwarf2read.c (dwarf2_init_float_type): Update call to init_type.
(read_base_type): Likewise.
* mdebugread.c (basic_type): Likewise.
* stabsread.c (dbx_init_float_type): Likewise.
(rs6000_builtin_type): Likewise.
(read_range_type): Likewise. Also, fix call to init_integer_type
with erroneous length argument.
* ada-lang.c (ada_language_arch_info): Update call to arch_type.
* d-lang.c (build_d_types): Likewise.
* f-lang.c (build_fortran_types): Likewise.
* go-lang.c (build_go_types): Likewise.
* opencl-lang.c (build_opencl_types): Likewise.
* jit.c (finalize_symtab): Likewise.
* gnu-v3-abi.c (build_gdb_vtable_type): Likewise.
(build_std_type_info_type): Likewise.
* target-descriptions.c (tdesc_gdb_type): Likewise. Also,
update call to arch_flags_type.
* linux-tdep.c (linux_get_siginfo_type_with_fields): Update call to
arch_type.
* fbsd-tdep.c (fbsd_get_siginfo_type): Likewise.
* windows-tdep.c (windows_get_tlb_type): Likewise.
* avr-tdep.c (avr_gdbarch_init): Update call to arch_type.
* ft32-tdep.c (ft32_gdbarch_init): Likewise.
* m32c-tdep.c (make_types): Likewise.
* rl78-tdep.c (rl78_gdbarch_init): Likewise.
(rl78_psw_type): Update call to arch_flags_type.
* m68k-tdep.c (m68k_ps_type): Update call to arch_flags_type.
* rx-tdep.c (rx_psw_type): Likewise.
(rx_fpsw_type): Likewise.
* sparc-tdep.c (sparc_psr_type): Likewise.
(sparc_fsr_type): Likewise.
* sparc64-tdep.c (sparc64_pstate_type): Likewise.
(sparc64_ccr_type): Likewise.
(sparc64_fsr_type): Likewise.
(sparc64_fprs_type): Likewise.
Trying to print a function local static variable of a const-qualified
method still doesn't work after the previous fixes:
(gdb) p 'S::method() const'::static_var
$1 = {i1 = 1, i2 = 2, i3 = 3}
(gdb) p S::method() const::static_var
No symbol "static_var" in specified context.
The reason is that the expression parser/evaluator loses the "const",
and the above unquoted case is just like trying to print a variable of
the non-const overload, if it exists, even. As if the above unquoted
case had been written as:
(gdb) p S::method()::static_var
No symbol "static_var" in specified context.
We can see the problem without static vars in the picture. With:
struct S
{
void method ();
void method () const;
};
Compare:
(gdb) print 'S::method(void) const'
$1 = {void (const S * const)} 0x400606 <S::method() const>
(gdb) print S::method(void) const
$2 = {void (S * const)} 0x4005d8 <S::method()> # wrong method!
That's what we need to fix. If we fix that, the function local static
case starts working.
The grammar production for function/method types is this one:
exp: exp '(' parameter_typelist ')' const_or_volatile
This results in a TYPE_INSTANCE expression evaluator operator. For
the example above, we get something like this ("set debug expression 1"):
...
0 TYPE_INSTANCE 1 TypeInstance: Type @0x560fda958be0 (void)
5 OP_SCOPE Type @0x560fdaa544d8 (S) Field name: `method'
...
While evaluating TYPE_INSTANCE, we end up in
value_struct_elt_for_reference, trying to find the method named
"method" that has the prototype recorded in TYPE_INSTANCE. In this
case, TYPE_INSTANCE says that we're looking for a method that has
"(void)" as parameters (that's what "1 TypeInstance: Type
@0x560fda958be0 (void)" above means. The trouble is that nowhere in
this mechanism do we communicate to value_struct_elt_for_reference
that we're looking for the _const_ overload.
value_struct_elt_for_reference only compared parameters, and the
non-const "method()" overload has matching parameters, so it's
considered the right match...
Conveniently, the "const_or_volatile" production in the grammar
already records "const" and "volatile" info in the type stack. The
type stack is not used in this code path, but we can borrow the
information. The patch converts the info in the type stack to an
"instance flags" enum, and adds that as another element in
TYPE_INSTANCE operators. This type instance flags is then applied to
the temporary type that is passed to value_struct_elt_for_reference
for matching.
The other side of the problem is that methods in the debug info aren't
marked const/volatile, so with that in place, the matching never finds
const/volatile-qualified methods.
The problem is that in the DWARF, there's no indication at all whether
a method is const/volatile qualified... For example (c++filt applied
to the linkage name for convenience):
<2><d3>: Abbrev Number: 6 (DW_TAG_subprogram)
<d4> DW_AT_external : 1
<d4> DW_AT_name : (indirect string, offset: 0x3df): method
<d8> DW_AT_decl_file : 1
<d9> DW_AT_decl_line : 58
<da> DW_AT_linkage_name: (indirect string, offset: 0x5b2): S::method() const
<de> DW_AT_declaration : 1
<de> DW_AT_object_pointer: <0xe6>
<e2> DW_AT_sibling : <0xec>
I see the same with both GCC and Clang. The patch works around this
by extracting the cv qualification from the "const" and "volatile" in
the demangled name. This will need further tweaking for "&" and
"const &" overloads, but we don't support them in the parser yet,
anyway.
The TYPE_CONST changes were necessary otherwise the comparisons in valops.c:
if (TYPE_CONST (intype) != TYPE_FN_FIELD_CONST (f, j))
continue;
would fail, because when both TYPE_CONST() TYPE_FN_FIELD_CONST() were
true, their values were different.
BTW, I'm recording the const/volatile-ness of methods in the
TYPE_FN_FIELD info because #1 - I'm not sure it's kosher to change the
method's type directly (vs having to call make_cv_type to create a new
type), and #2 it's what stabsread.c does:
...
case 'A': /* Normal functions. */
new_sublist->fn_field.is_const = 0;
new_sublist->fn_field.is_volatile = 0;
(*pp)++;
break;
case 'B': /* `const' member functions. */
new_sublist->fn_field.is_const = 1;
new_sublist->fn_field.is_volatile = 0;
...
After all this, this finally all works:
print S::method(void) const
$1 = {void (const S * const)} 0x400606 <S::method() const>
(gdb) p S::method() const::static_var
$2 = {i1 = 1, i2 = 2, i3 = 3}
gdb/ChangeLog:
2017-09-04 Pedro Alves <palves@redhat.com>
* c-exp.y (function_method, function_method_void): Add current
instance flags to TYPE_INSTANCE.
* dwarf2read.c (check_modifier): New.
(compute_delayed_physnames): Assert that only C++ adds delayed
physnames. Mark fn_fields as const/volatile depending on
physname.
* eval.c (make_params): New type_instance_flags parameter. Use
it as the new type's instance flags.
(evaluate_subexp_standard) <TYPE_INSTANCE>: Extract the instance
flags element and pass it to make_params.
* expprint.c (print_subexp_standard) <TYPE_INSTANCE>: Handle
instance flags element.
(dump_subexp_body_standard) <TYPE_INSTANCE>: Likewise.
* gdbtypes.h: Include "enum-flags.h".
(type_instance_flags): New enum-flags type.
(TYPE_CONST, TYPE_VOLATILE, TYPE_RESTRICT, TYPE_ATOMIC)
(TYPE_CODE_SPACE, TYPE_DATA_SPACE): Return boolean.
* parse.c (operator_length_standard) <TYPE_INSTANCE>: Adjust.
(follow_type_instance_flags): New function.
(operator_check_standard) <TYPE_INSTANCE>: Adjust.
* parser-defs.h (follow_type_instance_flags): Declare.
* valops.c (value_struct_elt_for_reference): const/volatile must
match too.
gdb/testsuite/ChangeLog:
2017-09-04 Pedro Alves <palves@redhat.com>
* gdb.base/func-static.c (S::method const, S::method volatile)
(S::method volatile const): New methods.
(c_s, v_s, cv_s): New instances.
(main): Call method() on them.
* gdb.base/func-static.exp (syntax_re, cannot_resolve_re): New variables.
(cannot_resolve): New procedure.
(cxx_scopes_list): Test cv methods. Add print-scope-quote and
print-quote-unquoted columns.
(do_test): Test printing each scope too.
The following patch fixes several outstanding overload resolution problems
with rvalue references and cv qualifiers in the test suite. The tests for
these problems typically passed with one compiler version and failed with
another. This behavior occurs because of the ordering of the overloaded
functions in the debug info. So the first best match "won out" over the
a subsequent better match.
One of the bugs addressed by this patch is the failure of rank_one_type to
account for type equality of two overloads based on CV qualifiers. This was
leading directly to problems evaluating rvalue reference overload quality,
but it is also highlighted in gdb.cp/oranking.exp, where two test KFAIL as
a result of this shortcoming.
I found the overload resolution code committed with the rvalue reference
patch (f9aeb8d49) needlessly over-complicated, and I have greatly simplified
it. This fixes some KFAILing tests in gdb.exp/rvalue-ref-overload.exp.
gdb/ChangeLog
* gdbtypes.c (LVALUE_REFERENCE_TO_RVALUE_BINDING_BADNESS)
DIFFERENT_REFERENCE_TYPE_BADNESS): Remove.
(CV_CONVERSION_BADNESS): Define.
(rank_one_type): Remove overly restrictive rvalue reference
rank checks.
Add cv-qualifier checks and subranks for type equality.
* gdbtypes.h (REFERENCE_CONVERSION_RVALUE,
REFERENCE_CONVERSION_CONST_LVALUE, CV_CONVERSION_BADNESS,
CV_CONVERSION_CONST, CV_CONVERSION_VOLATILE): Declare.
gdb/testsuite/ChangeLog
* gdb.cp/oranking.cc (test15): New function.
(main): Call test15 and declare additional variables for testing.
* gdb.cp/oranking.exp: Remove kfail status for "p foo4(&a)" and
"p foo101('abc')" tests.
* gdb.cp/rvalue-ref-overloads.exp: Remove kfail status for
"lvalue reference overload" test.
* gdb.cp/rvalue-ref-params.exp: Remove kfail status for
"print value of f1 on Child&& in f2" test.
GDB is currently not aware that wchar_t is a built-in type in C++
mode. This is usually not a problem because the debug info describes
the type, so when you have a program loaded, you don't notice this.
However, if you try expressions involving wchar_t before a program is
loaded, gdb errors out:
(gdb) p (wchar_t)-1
No symbol table is loaded. Use the "file" command.
(gdb) p L"hello"
No type named wchar_t.
(gdb) ptype L"hello"
No type named wchar_t.
This commit teaches gdb about the type. After:
(gdb) p (wchar_t)-1
$1 = -1 L'\xffffffff'
(gdb) p L"hello"
$2 = L"hello"
(gdb) ptype L"hello"
type = wchar_t [6]
Unlike char16_t/char32_t, unfortunately, the underlying type of
wchar_t is implementation dependent, both size and signness. So this
requires adding a couple new gdbarch hooks.
I grepped the GCC code base for WCHAR_TYPE and WCHAR_TYPE_SIZE, and it
seems to me that the majority of the ABIs have a 4-byte signed
wchar_t, so that's what I made the default for GDB too. And then I
looked for which ports have a 16-bit and/or unsigned wchar_t, and made
GDB follow suit.
gdb/ChangeLog:
2017-04-12 Pedro Alves <palves@redhat.com>
PR gdb/21323
* c-lang.c (cplus_primitive_types) <cplus_primitive_type_wchar_t>:
New enum value.
(cplus_language_arch_info): Register cplus_primitive_type_wchar_t.
* gdbtypes.h (struct builtin_type) <builtin_wchar>: New field.
* gdbtypes.c (gdbtypes_post_init): Create the "wchar_t" type.
* gdbarch.sh (wchar_bit, wchar_signed): New per-arch values.
* gdbarch.h, gdbarch.c: Regenerate.
* aarch64-tdep.c (aarch64_gdbarch_init): Override
gdbarch_wchar_bit and gdbarch_wchar_signed.
* alpha-tdep.c (alpha_gdbarch_init): Likewise.
* arm-tdep.c (arm_gdbarch_init): Likewise.
* avr-tdep.c (avr_gdbarch_init): Likewise.
* h8300-tdep.c (h8300_gdbarch_init): Likewise.
* i386-nto-tdep.c (i386nto_init_abi): Likewise.
* i386-tdep.c (i386_go32_init_abi): Likewise.
* m32r-tdep.c (m32r_gdbarch_init): Likewise.
* moxie-tdep.c (moxie_gdbarch_init): Likewise.
* nds32-tdep.c (nds32_gdbarch_init): Likewise.
* rs6000-aix-tdep.c (rs6000_aix_init_osabi): Likewise.
* sh-tdep.c (sh_gdbarch_init): Likewise.
* sparc-tdep.c (sparc32_gdbarch_init): Likewise.
* sparc64-tdep.c (sparc64_init_abi): Likewise.
* windows-tdep.c (windows_init_abi): Likewise.
* xstormy16-tdep.c (xstormy16_gdbarch_init): Likewise.
gdb/testsuite/ChangeLog:
2017-04-12 Pedro Alves <palves@redhat.com>
PR gdb/21323
* gdb.cp/wide_char_types.c: Include <wchar.h>.
(wchar): New global.
* gdb.cp/wide_char_types.exp (wide_char_types_program)
(do_test_wide_char, wide_char_types_no_program, top level): Add
wchar_t testing.
A while ago, back when GDB was a C program, the sect_offset and
cu_offset types were made structs in order to prevent incorrect mixing
of those offsets. Now that we require C++11, we can make them
integers again, while keeping the safety, by exploiting "enum class".
We can add a bit more safety, even, by defining operators that the
types _should_ support, helping making the suspicious uses stand out
more.
Getting at the underlying type is done with the new to_underlying
function added by the previous patch, which also helps better spot
where do we need to step out of the safety net. Mostly, that's around
parsing the DWARF, and when we print the offset for complaint/debug
purposes. But there are other occasional uses.
Since we have to define the sect_offset/cu_offset types in a header
anyway, I went ahead and generalized/library-fied the idea of "offset"
types, making it trivial to add more such types if we find a use. See
common/offset-type.h and the DEFINE_OFFSET_TYPE macro.
I needed a couple generaly-useful preprocessor bits (e.g., yet another
CONCAT implementation), so I started a new common/preprocessor.h file.
I included units tests covering the "offset" types API. These are
mostly compile-time tests, using SFINAE to check that expressions that
shouldn't compile (e.g., comparing unrelated offset types) really are
invalid and would fail to compile. This same idea appeared in my
pending enum-flags revamp from a few months ago (though this version
is a bit further modernized compared to what I had posted), and I plan
on reusing the "check valid expression" bits added here in that
series, so I went ahead and defined the CHECK_VALID_EXPR macro in its
own header -- common/valid-expr.h. I think that's nicer regardless.
I was borderline between calling the new types "offset" types, or
"index" types, BTW. I stuck with "offset" simply because that's what
we're already calling them, mostly.
gdb/ChangeLog:
2017-04-04 Pedro Alves <palves@redhat.com>
* Makefile.in (SUBDIR_UNITTESTS_SRCS): Add
unittests/offset-type-selftests.c.
(SUBDIR_UNITTESTS_OBS): Add offset-type-selftests.o.
* common/offset-type.h: New file.
* common/preprocessor.h: New file.
* common/traits.h: New file.
* common/valid-expr.h: New file.
* dwarf2expr.c: Include "common/underlying.h". Adjust to use
sect_offset and cu_offset strong typedefs throughout.
* dwarf2expr.h: Adjust to use sect_offset and cu_offset strong
typedefs throughout.
* dwarf2loc.c: Include "common/underlying.h". Adjust to use
sect_offset and cu_offset strong typedefs throughout.
* dwarf2read.c: Adjust to use sect_offset and cu_offset strong
typedefs throughout.
* gdbtypes.h: Include "common/offset-type.h".
(cu_offset): Now an offset type (strong typedef) instead of a
struct.
(sect_offset): Likewise.
(union call_site_parameter_u): Rename "param_offset" field to
"param_cu_off".
* unittests/offset-type-selftests.c: New file.
Parameterize lookup_reference_type() and make_reference_type() by the kind of
reference type we want to look up. Create two wrapper functions
lookup_{lvalue,rvalue}_reference_type() for lookup_reference_type() to simplify
the API. Change all callers to use the new API.
gdb/Changelog
PR gdb/14441
* dwarf2read.c (read_tag_reference_type): Use
lookup_lvalue_reference_type() instead of lookup_reference_type().
* eval.c (evaluate_subexp_standard): Likewise.
* f-exp.y: Likewise.
* gdbtypes.c (make_reference_type, lookup_reference_type):
Generalize with rvalue reference types.
(lookup_lvalue_reference_type, lookup_rvalue_reference_type): New
convenience wrappers for lookup_reference_type().
* gdbtypes.h (make_reference_type, lookup_reference_type): Add a
reference kind parameter.
(lookup_lvalue_reference_type, lookup_rvalue_reference_type): Add
wrappers for lookup_reference_type().
* guile/scm-type.c (gdbscm_type_reference): Use
lookup_lvalue_reference_type() instead of lookup_reference_type().
* guile/scm-value.c (gdbscm_value_dynamic_type): Likewise.
* parse.c (follow_types): Likewise.
* python/py-type.c (typy_reference, typy_lookup_type): Likewise.
* python/py-value.c (valpy_get_dynamic_type, valpy_getitem):
Likewise.
* python/py-xmethods.c (gdbpy_get_xmethod_result_type)
(gdbpy_invoke_xmethod): Likewise.
* stabsread.c: Provide extra argument to make_reference_type()
call.
* valops.c (value_ref, value_rtti_indirect_type): Use
lookup_lvalue_reference_type() instead of lookup_reference_type().
This patch introduces preliminal definitions regarding C++11 rvalue references
to the gdb type system. In addition to an enum type_code entry, a field in
struct type and an accessor macro for that which are created similarly to the
lvalue references counterparts, we also introduce a TYPE_REFERENCE convenience
macro used to check for both kinds of references simultaneously as they are
equivalent in many contexts.
gdb/Changelog
PR gdb/14441
* gdbtypes.h (enum type_code) <TYPE_CODE_RVALUE_REF>: New constant.
(TYPE_IS_REFERENCE): New macro.
(struct type): Add rvalue_reference_type field.
(TYPE_RVALUE_REFERENCE_TYPE): New macro.
This applies the second part of GDB's End of Year Procedure, which
updates the copyright year range in all of GDB's files.
gdb/ChangeLog:
Update copyright year range in all GDB files.
Now that init_type no longer takes a FLAGS argument, there is no user of
the TYPE_FLAGS_... enum values left. This commit removes them (and all
references to them in comments as well).
This is mostly a no-op, except for a change to the Python type printer,
which attempted to use them before. (As best as I can tell, this wasn't
really needed anyway, since it was only used to pretty-print type
*instance* flags, which only use the instance flags.)
gdb/ChangeLog:
* gdbtypes.h (enum type_flag_value): Remove.
Remove references to TYPE_FLAG_... in comments throughout.
* gdbtypes.c (recursive_dump_type): Do not print TYPE_FLAG_...
flags, print the corresponding TYPE_... access macro names.
Remove references to TYPE_FLAG_... in comments throughout.
* infcall.c: Remove references to TYPE_FLAG_... in comments.
* valprint.c: Likewise.
* gdb-gdb.py (class TypeFlag): No longer consider TYPE_FLAG_...
values, only TYPE_INSTANCE_FLAG_... values.
(class TypeFlagsPrinter): Likewise.
gdb/testsuite/ChangeLog:
* gdb.cp/hang.exp: Remove reference to TYPE_FLAG_STUB in comment.
Signed-off-by: Ulrich Weigand <ulrich.weigand@de.ibm.com>
This adds a number of helper routines for creating objfile-owned types;
these correspond 1:1 to the already existing helper routines for creating
gdbarch-owned types, and are intended to be used instead of init_type.
A shared fragment of init_float_type and arch_float_type is extracted into
a separate subroutine verify_subroutine.
The commit also brings the interface of init_type in line with the one for
arch_type. In particular, this means removing the FLAGS argument; callers
now set the required flags directly. (Since most callers use the new
helper routines, very few callers actually need to set any additional
flags directly any more.)
Note that this means all the TYPE_FLAGS_... defined are no longer needed
anywhere; they will be removed by a follow-on commit.
All users of init_type are changed to use on of the new helpers where
possible. No functional change intended.
gdb/ChangeLog:
* gdbtypes.h (init_type): Remove FLAGS argument. Move OBJFILE
argument to first position.
(init_integer_type): New prototype.
(init_character_type): Likewise.
(init_boolean_type): Likewise.
(init_float_type): Likewise.
(init_decfloat_type): Likewise.
(init_complex_type): Likewise.
(init_pointer_type): Likewise.
* gdbtypes.c (verify_floatflormat): New function.
(init_type): Remove FLAGS argument and processing. Move OBJFILE
argument to first position.
(init_integer_type): New function.
(init_character_type): Likewise.
(init_boolean_type): Likewise.
(init_float_type): Likewise.
(init_decfloat_type): Likewise.
(init_complex_type): Likewise.
(init_pointer_type): Likewise.
(arch_float_type): Use verify_floatflormat.
(objfile_type): Use init_..._type helpers instead of calling
init_type directly.
* dwarf2read.c (fixup_go_packaging): Update to changed init_type
prototype.
(read_namespace_type): Likewise.
(read_module_type): Likewise.
(read_typedef): Likewise.
(read_unspecified_type): Likewise.
(build_error_marker_type): Likewise.
(read_base_type): Use init_..._type helpers.
* mdebugread.c (basic_type): Use init_..._type helpers.
(parse_type): Update to changed init_type prototype.
(cross_ref): Likewise.
* stabsread.c (rs6000_builtin_type): Use init_..._type helpers.
(read_sun_builtin_type): Likewise.
(read_sun_floating_type): Likewise.
(read_range_type): Likewise. Also update to changed init_type
prototype.
Signed-off-by: Ulrich Weigand <ulrich.weigand@de.ibm.com>
gdbtypes provides a number of helper routines that can be called instead of
using arch_type directly to create a type of a particular kind. This patch
adds two additional such routines that have been missing so far, to allow
creation of TYPE_CODE_DECFLOAT and TYPE_CODE_POINTER types.
The patch also changes a number of places to use the new helper routines
instead of calling arch_type directly. No functional change intended.
gdb/ChangeLog:
* gdbtypes.h (arch_decfloat_type): New prototype.
(arch_pointer_type): Likewise.
* gdbtypes.c (arch_decfloat_type): New function.
(arch_pointer_type): Likewise.
(gdbtypes_post_init): Use arch_decfloat_type.
* avr-tdep.c (avr_gdbarch_init): Use arch_pointer_type.
* ft32-tdep.c (ft32_gdbarch_init): Likewise.
* m32c-tdep.c (make_types): Likewise.
* rl78-tdep.c (rl78_gdbarch_init): Likewise.
Signed-off-by: Ulrich Weigand <ulrich.weigand@de.ibm.com>
GDB computes structure byte offsets using a 32 bit integer. And,
first it computes the offset in bits and then converts to bytes. The
result is that any offset that if 512K bytes or larger overflows.
This patch changes GDB to use LONGEST for such calculations.
PR gdb/17520 Structure offset wrong when 1/4 GB or greater.
* c-lang.h: Change all parameters, variables, and struct or union
members used as struct or union fie3ld offsets from int to
LONGEST.
* c-valprint.c: Likewise.
* cp-abi.c: Likewise.
* cp-abi.h: Likewise.
* cp-valprint.c: Likewise.
* d-valprint.c: Likewise.
* dwarf2loc.c: Likewise.
* eval.c: Likewise.
* extension-priv.h: Likewise.
* extension.c: Likewise.
* extension.h: Likewise.
* findvar.c: Likewise.
* gdbtypes.h: Likewise.
* gnu-v2-abi.c: Likewise.
* gnu-v3-abi.c: Likewise.
* go-valprint.c: Likewise.
* guile/guile-internal.h: Likewise.
* guile/scm-pretty-print.c: Likewise.
* jv-valprint.c Likewise.
* opencl-lang.c: Likewise.
* p-lang.h: Likewise.
* python/py-prettyprint.c: Likewise.
* python/python-internal.h: Likewise.
* spu-tdep.c: Likewise.
* typeprint.c: Likewise.
* valarith.c: Likewise.
* valops.c: Likewise.
* valprint.c: Likewise.
* valprint.h: Likewise.
* value.c: Likewise.
* value.h: Likewise.
* p-valprint.c: Likewise.
* c-typeprint.c (c_type_print_base): When printing offset, use
plongest, not %d.
* gdbtypes.c (recursive_dump_type): Ditto.
While working on the Rust support, I happened to notice that arch_type
and related functions take "char *" arguments, where "const char *"
would be more correct. This patch fixes this oversight. Tested by
rebuilding.
2016-06-10 Tom Tromey <tom@tromey.com>
* gdbtypes.c (arch_type, arch_integer_type, arch_character_type)
(arch_boolean_type, arch_float_type, arch_complex_type)
(arch_flags_type, append_flags_type_field)
(append_flags_type_flag, arch_composite_type)
(append_composite_type_field_raw)
(append_composite_type_field_aligned)
(append_composite_type_field): Make "name" parameter const.
* gdbtypes.h (arch_type, arch_integer_type, arch_character_type)
(arch_boolean_type, arch_float_type, arch_complex_type)
(append_composite_type_field, append_composite_type_field_aligned)
(append_composite_type_field_raw, arch_flags_type)
(append_flags_type_field, append_flags_type_flag): Constify.
Fortran supports dynamic types for which bounds, size and location
can vary during their lifetime. As a result of the dynamic
behaviour, they have to be resolved at every query.
This patch will resolve the type of a structure field when it
is dynamic.
2016-04-26 Bernhard Heckel <bernhard.heckel@intel.com>
2016-04-26 Keven Boell <keven.boell@intel.com>
Before:
(gdb) print threev%ivla(1)
Cannot access memory at address 0x3
(gdb) print threev%ivla(5)
no such vector element
After:
(gdb) print threev%ivla(1)
$9 = 1
(gdb) print threev%ivla(5)
$10 = 42
gdb/Changelog:
* NEWS: Add new supported features for fortran.
* gdbtypes.c (remove_dyn_prop): New.
(resolve_dynamic_struct): Keep type length for fortran structs.
* gdbtypes.h: Forward declaration of new function.
* value.c (value_address): Return dynamic resolved location of a value.
(set_value_component_location): Adjust the value address
for single value prints.
(value_primitive_field): Support value types with a dynamic location.
(set_internalvar): Remove dynamic location property of
internal variables.
gdb/testsuite/Changelog:
* gdb.fortran/vla-type.f90: New file.
* gdb.fortran/vla-type.exp: New file.
Tom Tromey
Tom Tromey
Alan Hayward
Andrew Burgess
Keith Seitz
John Baldwin
Joel Brobecker
Pedro Alves
John Darrington
Simon Marchi
Ulrich Weigand
Artemiy Volkov
Jan Kratochvil
David Taylor
Bernhard Heckel
Doug Evans