This commits the result of running gdb/copyright.py as per our Start
of New Year procedure...
gdb/ChangeLog
Update copyright year range in copyright header of all GDB files.
This commit adjusts GDB's copyright.py script, following two past changes:
- gdb/gdbserver/ being move to the toplevel directory;
- gdb/common/ being renamed to gdbsupport/.
gdb/ChangeLog:
* copyright.py (get_update_list): Add "gdbserver" and "gdbsupport"
to the list of directories to update.
As a results of the rotation, this introduces a new file which
needed to be added to DJGPP's fnchange.lst.
gdb/ChangeLog
* config/djgpp/fnchange.lst: Add entry for gdb/ChangeLog-2020.
While "set $0, $0" works, that's not the documented instruction to do
nothing for MMIX. However, I'm not changing it for "nop_type 5" as
seen in gas.exp and org-1.s, because "set $0, $0" seems like it could
be re-used there, for some future ISA.
gas/
* config/tc-mmix.h (md_single_noop_insn): Change to "swym 0".
Rust 1.49 was released today, and it includes some library changes
which caused some gdb.rust tests to fail. This patch adapts the test
suite to the new output. I also verified that this continues to work
with Rust 1.48.
gdb/testsuite/ChangeLog
2020-12-31 Tom Tromey <tom@tromey.com>
* gdb.rust/simple.exp: Update output for Rust 1.49.
binutils/
PR 27128
* nm.c (print_symname): Append version string to symbol name
before printing the lot under control of "form". Append version
to demangled names too.
ld/
PR 27128
* testsuite/ld-elf/pr27128.s: New file.
* testsuite/ld-elf/pr27128.t: Likewise.
* testsuite/ld-elf/pr27128a.d: Likewise.
* testsuite/ld-elf/pr27128b.d: Likewise.
* testsuite/ld-elf/pr27128c.d: Likewise.
* testsuite/ld-elf/pr27128d.d: Likewise.
* testsuite/ld-elf/pr27128e.d: Likewise.
Fix a bug in the test where we were missing "additional_flags=",
causing -gstatement-frontiers not to be passed to the compiler.
The issue was introduced in
eb24648c45 ("Fix gdb.cp/step-and-next-inline.exp with Clang").
gdb/testsuite:
2020-12-31 Bernd Edlinger <bernd.edlinger@hotmail.de>
* gdb.cp/step-and-next-inline.exp: Fix test case.
Use with_test_prefix to de-duplicate test names.
gdb/testsuite/ChangeLog:
* gdb.python/py-frame-args.exp: De-duplicate test names.
Change-Id: I5cc8bee692a0d071cb78258aca80ea642e00e7a8
Pass osabi to reconcat to get
Usage: elfedit <option(s)> elffile(s)
...
--input-osabi [none|HPUX|NetBSD|GNU|Linux|Solaris|AIX|Irix|FreeBSD|TRU64|Modesto|OpenBSD|OpenVMS|NSK|AROS|FenixOS]
Set input OSABI
instead of
--input-osabi [|FenixOS]
Set input OSABI
* elfedit (usage): Pass osabi to reconcat.
The objects returned by FrameDecorator.frame_args need to implement a
method named symbol, not argument.
gdb/doc/ChangeLog:
2020-12-29 Hannes Domani <ssbssa@yahoo.de>
* python.texi (Frame Decorator API): Fix method name.
Use the newly built assembler and linker in test_gnu_debuglink by passing
$gcc_gas_flag to target_compile.
* testsuite/binutils-all/compress.exp (test_gnu_debuglink): Pass
$gcc_gas_flag to target_compile.
The MULTI_SUBSCRIPT code in evaluate_subexp_standard has a comment
saying that perhaps the EVAL_SKIP handling is incorrect. This patch
simplifies this code. In particular, it precomputes all the indices
in a separate loop and removes some complicated flow-control.
Tested using the gdb.modula2 and gdb.dlang test suites, as these are
the only parsers that emit MULTI_SUBSCRIPT.
gdb/ChangeLog
2020-12-27 Tom Tromey <tom@tromey.com>
* eval.c (evaluate_subexp_standard) <case MULTI_SUBSCRIPT>:
Simplify.
Update 80387 floating point 's' suffix to read:
* Integer constructors are '.word', '.long' or '.int', and '.quad'
for the 16-, 32-, and 64-bit integer formats. The corresponding
instruction mnemonic suffixes are 's' (short), 'l' (long), and 'q'
(quad).
instead of 's' (single).
PR gas/27106
* doc/c-i386.texi: Update 80387 floating point 's' suffix
In PR gdb/27059 an issue was discovered where GDB would sometimes
trigger undefined behaviour in the form of signed integer overflow.
The problem here is that GDB was reading random garbage from the
inferior memory space, assuming this data was valid, and performing
arithmetic on it.
This bug raises an interesting general problem with GDB's DWARF
expression evaluator, which is this:
We currently assume that the DWARF expressions being evaluated are
well formed, and well behaving. As an example, this is the expression
that the bug was running into problems on, this was used as the
expression for a DW_AT_byte_stride of a DW_TAG_subrange_type:
DW_OP_push_object_address;
DW_OP_plus_uconst: 88;
DW_OP_deref;
DW_OP_push_object_address;
DW_OP_plus_uconst: 32;
DW_OP_deref;
DW_OP_mul
Two values are read from the inferior and multiplied together. GDB
should not assume that any value read from the inferior is in any way
sane, as such the implementation of DW_OP_mul should be guarding
against overflow and doing something semi-sane here.
However, it turns out that the original bug PR gdb/27059, is hitting a
more specific case, which doesn't require changes to the DWARF
expression evaluator, so I'm going to leave the above issue for
another day.
In the test mentioned in the bug GDB is actually trying to resolve the
dynamic type of a Fortran array that is NOT allocated. A
non-allocated Fortran array is one that does not have any data
allocated for it yet, and even the upper and lower bounds of the array
are not yet known.
It turns out that, at least for gfortran compiled code, the data
fields that describe the byte-stride are not initialised until the
array is allocated.
This leads me to the following conclusion: GDB should not try to
resolve the bounds, or stride information for an array that is not
allocated (or not associated, a similar, but slightly different
Fortran feature). Instead, each of these properties should be set to
undefined if the array is not allocated (or associated).
That is what this commit does. There's a new flag that is passed
around during the dynamic array resolution. When this flag is true
the dynamic properties are resolved using the DWARF expressions as
they currently are, but when this flag is false the expressions are
not evaluated, and instead the properties are set to undefined.
gdb/ChangeLog:
PR gdb/27059
* eval.c (evaluate_subexp_for_sizeof): Handle not allocated and
not associated arrays.
* f-lang.c (fortran_adjust_dynamic_array_base_address_hack): Don't
adjust arrays that are not allocated/associated.
* gdbtypes.c (resolve_dynamic_range): Update header comment. Add
new parameter which is used to sometimes set dynamic properties to
undefined.
(resolve_dynamic_array_or_string): Update header comment. Add new
parameter which is used to guard evaluating dynamic properties.
Resolve allocated/associated properties first.
gdb/testsuite/ChangeLog:
PR gdb/27059
* gdb.dwarf2/dyn-type-unallocated.c: New file.
* gdb.dwarf2/dyn-type-unallocated.exp: New file.
Adds the allocated and associated dynamic properties into the output
of the 'maintenance print type' command.
gdb/ChangeLog:
* gdbtypes (recursive_dump_type): Include allocated and associated
properties.
When called with an array type of unknown dimensions,
is_scalar_type_recursive ended up comparing uninitialized values.
This was picked up by the following compiler warning:
CXX gdbtypes.o
/binutils-gdb/gdb/gdbtypes.c: In function int is_scalar_type_recursive(type*):
/binutils-gdb/gdb/gdbtypes.c:3670:38: warning: high_bound may be used uninitialized in this function [-Wmaybe-uninitialized]
3670 | return high_bound == low_bound && is_scalar_type_recursive (elt_type);
| ~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/binutils-gdb/gdb/gdbtypes.c:3670:38: warning: low_bound may be used uninitialized in this function [-Wmaybe-uninitialized]
This patch makes sure that when dealing with an array of unknown size
(or an array of more than 1 element), is_scalar_type_recursive returns
false.
gdb/ChangeLog:
* gdbtypes.c (is_scalar_type_recursive): Prevent comparison
between uninitialized values.
Change-Id: Ifc005ced166aa7a065fef3e652977bae67625bf4
I really don't think anyone cares about underflow of vms time values,
but the potential segfault on a gmtime failure is worth fixing.
* readelf.c (INT64_MIN): Define if not already defined.
(print_vms_time): Catch 64-bit overflow when converting from
vms time to posix time. Don't segfault if gmtime returns NULL.
The failure on this PR is due to using the same bfd section for
multiple output sections. Commit 21401fc7bf managed to create
duplicate linker script output section statements, but not the actual
bfd sections.
PR 27100
* ldlang.h (lang_output_section_statement_type): Add dup_output.
* ldlang.c (lang_output_section_statement_lookup): Set dup_output.
(init_os): Test dup_output rather than constraint.
* testsuite/ld-scripts/pr27100.d,
* testsuite/ld-scripts/pr27100.s,
* testsuite/ld-scripts/pr27100.t: New test.
* testsuite/ld-scripts/data.exp: Run it. Don't exclude aout here.
* testsuite/ld-scripts/data.d: Do so here instead.
* testsuite/ld-scripts/fill.d: Likewise.
* testsuite/ld-scripts/fill16.d: Likewise.
This commit removes some, but not all, uses of LA_PRINT_STRING. In
this commit I've removed those uses where there is an obvious language
object on which I can instead call the printstr method.
In the remaining 3 uses it is harder to know if the correct thing is
to call printstr on the current language, or on a specific language.
Currently obviously, we always call on the current language (as that's
what LA_PRINT_STRING does), and clearly this behaviour is good enough
right now, but is it "right"? I've left them for now and will give
them more thought in the future.
gdb/ChangeLog:
* expprint.c (print_subexp_standard): Replace uses of
LA_PRINT_STRING.
* f-valprint.c (f_language::value_print_inner): Likewise.
* guile/scm-pretty-print.c (ppscm_print_string_repr): Likewise.
* p-valprint.c (pascal_language::value_print_inner): Likewise.
* python/py-prettyprint.c (print_string_repr): Likewise.
Move the rust_language class declaration into the rust-lang.h header
file. This allows for the function implementations called directly in
rust-lang.c and rust-exp.y without the need for trampoline functions.
There should be no user visible changes after this commit.
gdb/ChangeLog:
* rust-exp.y (rust_parse): Rename to...
(rust_language::parser): ...this.
* rust-lang.c (-rust_printstr): Rename to...
(rust_language::printstr): ...this.
(rust_value_print_inner): Delete declaration.
(val_print_struct): Rename to...
(rust_language::val_print_struct): ...this. Update calls to
member functions.
(rust_print_enum): Rename to...
(rust_language::print_enum): ...this. Update calls to member
functions.
(rust_value_print_inner): Rename to...
(rust_language::value_print_inner): ...this. Update calls to
member functions.
(exp_descriptor_rust): Rename to...
(rust_language::exp_descriptor_tab): ...this.
(class rust_language): Move to rust-lang.h.
(rust_language::language_arch_info): Implementation moved to here
from class declaration.
(rust_language::print_type): Likewise.
(rust_language::emitchar): Likewise.
(rust_language::is_string_type_p): Likewise.
* rust-lang.h: Add 'demangle.h', 'language.h', 'value.h', and
'c-lang.h' includes.
(rust_parse): Delete declaration.
(class rust_language): Class declaration moved here from
rust-lang.c.
In this commit:
commit b7c6e27dbb
Date: Tue Aug 4 17:07:59 2020 +0100
gdb: Convert language_data::la_op_print_tab to a method
A bug was introduced, the objc language now returns the wrong op_print
table. Fixed in this commit.
gdb/ChangeLog:
* objc-lang.c (objc_language::opcode_print_table): Return
objc_op_print_tab.
Move the pascal_language class declaration into the p-lang.h header
file. This allows for the function implementations to be spread over
the different p-*.c files without the need for global trampoline
functions.
As a consequence of this change many of the Pascal value and type
printing helper functions have become member functions within the
pascal_language class.
There should be no user visible changes after this commit.
gdb/ChangeLog:
* p-exp.y (exp): Update call to pascal_is_string_type.
(pascal_parse): Rename to...
(pascal_language::parser): ...this.
* p-lang.c (is_pascal_string_type): Rename to...
(pascal_is_string_type): ...this.
(pascal_one_char): Rename to...
(pascal_language::print_one_char): ...this.
(pascal_printchar): Rename to...
(pascal_language::printchar): ...this. Update call to
print_one_char member function.
(pascal_op_print_tab): Rename to...
(pascal_language::op_print_tab): ...this.
(class pascal_language): Moved to p-lang.h.
(pascal_language::language_arch_info): Function implementation
moved out of class declaration.
(pascal_language::printstr): Likewise.
* p-lang.h (pascal_parse): Delete declaration.
(pascal_is_string_type): Declare.
(pascal_print_type): Delete declaration.
(pascal_print_typedef): Delete declaration.
(pascal_value_print_inner): Delete declaration.
(pascal_value_print): Delete declaration.
(pascal_type_print_method_args): Delete declaration.
(is_pascal_string_type): Delete declaration.
(pascal_printchar): Delete declaration.
(pascal_builtin_types): Delete declaration.
(pascal_type_print_base): Delete declaration.
(pascal_type_print_varspec_prefix): Delete declaration.
(class pascal_language): Moved here from p-lang.c.
* p-typeprint.c (pascal_type_print_varspec_suffix): Delete
declaration.
(pascal_type_print_derivation_info): Delete declaration.
(pascal_print_type): Rename to...
(pascal_language::print_type): ...this. Update calls to member
functions.
(pascal_print_typedef): Rename to...
(pascal_language::print_typedef): ...this. Update calls to member
functions.
(pascal_type_print_derivation_info): Rename to...
(pascal_language::type_print_derivation_info): ...this.
(pascal_type_print_method_args): Rename to...
(pascal_language::type_print_method_args): ...this.
(pascal_type_print_varspec_prefix): Rename to...
(pascal_language::type_print_varspec_prefix): ...this. Update
calls to member functions.
(pascal_print_func_args): Rename to...
(pascal_language::print_func_args): ...this. Update calls to
member functions.
(pascal_type_print_func_varspec_suffix): Rename to...
(pascal_language::type_print_func_varspec_suffix): ...this.
Update calls to member functions.
(pascal_type_print_varspec_suffix): Rename to...
(pascal_language::type_print_varspec_suffix): ...this. Update
calls to member functions.
(pascal_type_print_base): Rename to...
(pascal_language::type_print_base): ...this. Update calls to
member functions.
* p-valprint.c (pascal_value_print_inner): Rename to...
(pascal_language::value_print_inner): ...this. Update calls to
member functions.
(pascal_value_print): Rename to...
(pascal_language::value_print): ...this. Update calls to member
functions.
Move the go_language class into go-lang.h, this allows us to have
member functions implemented directly in the different go-*.c files
instead of having to trampoline out to global functions.
There should be no user visible changes after this commit.
gdb/ChangeLog:
* go-exp.y (go_parse): Rename to...
(go_language::parser): ...this.
* go-lang.c (go_demangle): Rename to...
(go_language::demangle_symbol): ...this.
(go_language::expression_ops): Implementation moved here out of
class declaration.
(go_op_print_tab): Rename to...
(go_language::op_print_tab): ...this, update comment.
(class go_language): Declaration moved to go-lang.h.
(go_language::language_arch_info): Implementation moved here out
of class declaration.
* go-lang.h (go_parse): Delete declaration.
(go_demangle): Delete declaration.
(go_print_type): Delete declaration.
(go_value_print_inner): Delete declaration.
(class go_language): Declaration moved here from go-lang.c.
* go-typeprint.c (go_print_type): Rename to...
(go_language::print_type): ...this.
* go-valprint.c (go_value_print_inner): Rename to...
(go_language::value_print_inner): ...this.
* symtab.c (demangle_for_lookup): Call demangle_symbol method on
the go_language object.
Now that every use of the LA_EMIT_CHAR macro is within a language_defn
member function we can simply call the emitchar member function
directly instead of using the LA_EMIT_CHAR macro.
If we are ever inside a language object, for example, cplus_language,
while current_language points at something other than cplus_language
then this commit will result in a change in behaviour. However, I
believe if we did have such a difference then this would be a bug in
GDB. AS such I'm going to claim there _should_ be no user visible
changes from this commit.
gdb/ChangeLog:
* c-lang.c (language_defn::printchar): Call emitchar, not
LA_EMIT_CHAR.
* f-lang.h (f_language::printchar): Likewise.
* language.h (LA_EMIT_CHAR): Delete macro.
* rust-lang.c (rust_language::printchar): Call emitchar, not
LA_EMIT_CHAR.
This commit removes the global function c_printchar and moves the
implementation into language_defn::printchar.
There should be no user visible changes after this commit.
gdb/ChangeLog:
* c-lang.c (c_printchar): Rename to...
(language_defn::printchar): ...this.
* c-lang.h (c_printchar): Delete declaration.
* language.c (language_defn::printchar): Delete this
implementation. Is now implemented in c-lang.c.
The function c_printchar is called from two places; it provides the
implementation of language_defn::printchar and it is called from
dwarf2_compute_name.
It would be nice to rename c_printchar as language_defn::printchar and
so avoid the trampoline.
To achieve this, instead of calling c_printchar directly from the
DWARF code, I lookup the C++ language object and call the printchar
member function.
In a later commit I can then rename c_printchar.
There should be no user visible changes after this commit.
gdb/ChangeLog:
* dwarf2/read.c (dwarf2_compute_name): Call methods on C++
language object instead of calling global functions directly.
Spotted that print_char_chars appears to be unused, delete it. There
should be no user visible changes after this commit.
gdb/ChangeLog:
* valprint.c (print_char_chars): Delete definition.
* valprint.h (print_char_chars): Delete declaration.
gnu-nat.c was getting the inclusion of vm_param.h only by luck. We need
to explicitly include it to be sure to get the definitions of
VM_MIN/MAX_ADDRESS.
gdb/ChangeLog:
* gnu-nat.c: Include <mach/vm_param.h>.
