The test gdb.base/continue-after-aborted-step-over.exp fails on ROCm GDB
[1] when using the unix board (when debugging a standard x86-64/Linux
program), with:
(gdb) b *0^M
Breakpoint 2 at 0x0^M
Warning:^M
Cannot insert breakpoint 2.^M
Cannot access memory at address 0x0^M
^M
(gdb) FAIL: gdb.base/continue-after-aborted-step-over.exp: displaced-stepping=off: b *0
This happens because that build of GDB defaults to "set breakpoint
always-inserted on", for reasons that are unrelevant to explain here.
As soon as the breakpoint is created, GDB tries to insert it and
(expectedly) fails. This causes more text to be output than what the
pattern expects.
It is actually be relevant to run the test with both "set breakpoint
always-inserted" on and off. With it on, it mimics what happens when
running in non-stop mode, with other threads running. This is relevant
for upstream even outside of the ROCm port, so here's a patch for it.
Add this other axis and adjust the "b *0" test to handle the extra
output when it is on.
[1] https://github.com/ROCm-Developer-Tools/ROCgdb
gdb/testsuite/ChangeLog:
* gdb.base/continue-after-aborted-step-over.exp: Add "breakpoint
always-inserted" axis.
(do_test): Add breakpoint_always_inserted parameter.
Change-Id: I95126cae563a0b9a72f4a99627809fc34340cd5e
A recent BFD change caused a build failure for a Windows->PPC cross:
ld.exe: ../bfd/libbfd.a(coff-rs6000.o):coff-rs6000.c:(.text+0x4571): undefined reference to `getuid'
ld.exe: ../bfd/libbfd.a(coff-rs6000.o):coff-rs6000.c:(.text+0x457e): undefined reference to `getgid'
This patch fixes the problem by moving the replacement definitions of
getuid and getgid to system.h.
bfd/ChangeLog
2020-11-11 Tom Tromey <tromey@adacore.com>
* archive.c (getuid, getgid): Move...
* sysdep.h (getuid, getgid): ...here.
Extends riscv_dwarf_reg_to_regnum to add the ability to convert the
DWARF register numbers for CSRs into GDB's internal numbers.
gdb/ChangeLog:
* riscv-tdep.c (riscv_dwarf_reg_to_regnum): Decode DWARF CSR
numbers.
* riscv-tdep.h (RISCV_DWARF_FIRST_CSR, RISCV_DWARF_LAST_CSR): New
enum values.
The help text for the --disable-packet option was missing one of the
possible values.
As this option is for maintainers only it is explicitly not documented
in gdb/doc/gdb.texinfo, so no update is needed there.
gdbserver/ChangeLog:
* server.cc (gdbserver_usage): Add missing option to usage text.
(gdbserver_show_disableable): Likewise.
This changes internalvar_name to return a const char *.
gdb/ChangeLog
2020-11-10 Tom Tromey <tom@tromey.com>
* value.h (internalvar_name): Update.
* value.c (internalvar_name): Make return type const.
This changes a few spots in ax-gdb.c to use a "const char *" rather
than a non-const one.
gdb/ChangeLog
2020-11-10 Tom Tromey <tom@tromey.com>
* ax-gdb.c (gen_struct_elt_for_reference, gen_namespace_elt)
(gen_maybe_namespace_elt, gen_aggregate_elt_ref, gen_expr): Use
const.
This changes the "ptr" parameter to value_nsstring to be const.
gdb/ChangeLog
2020-11-10 Tom Tromey <tom@tromey.com>
* objc-lang.h (value_nsstring): Update.
* objc-lang.c (value_nsstring): Make "ptr" const.
A recent commit caused pathstuff.cc to fail to compile on mingw, like:
../../binutils-gdb/gdbsupport/pathstuff.cc:324:1: error: no previous declaration for 'std::string find_gdb_home_config_file(const char*, _stati64*)' [-Werror=missing-declarations]
Some newly-added #includes were changing which "stat" was being seen
by the compiler. This patch moves the includes to the header, so that
the declaration and definition now agree.
2020-11-10 Tom Tromey <tromey@adacore.com>
PR build/26848:
* pathstuff.h: Move include block here...
* pathstuff.cc: ... from here.
While working on a different bug in the Ada support, I found that the
gdb.ada/bias.exp test is slightly incorrect. In particular, it is
using a range type, which it then overflows during an operation.
This patch changes the test so that the computed values remain in
range.
gdb/testsuite/ChangeLog
2020-11-10 Tom Tromey <tromey@adacore.com>
* gdb.ada/bias.exp: Update.
* gdb.ada/bias/bias.adb (X): Change value.
The "vla_optimized_out" procedure in gdb.base/vla-optimized-out.exp
accepts a "sizeof_result" argument which is substituted into the
regular expression used to check the result of printing the sizeof
a VLA. The -O3 test variants, however, pass a regular expression
fragment as that argument, which expands into a regular expression
that matches any result with a "6" in it. This commit wraps the
substitution with parentheses to prevent these false matches.
gdb/testsuite/ChangeLog:
* gdb.base/vla-optimized-out.exp (p sizeof (a)): Wrap supplied
regexp fragment in parentheses to prevent false matching.
The function f1 in gdb.base/vla-optimized-out.c sets various
attributes to prevent its being inlined, but Clang inlines it
anyway, causing the test that uses it to fail. This commit
adds the "weak" attribute to cause Clang to keep the function
fully out of line so the test can operate as it should.
gdb/testsuite/ChangeLog:
* gdb.base/vla-optimized-out.c (f1): Add __attribute__ ((weak)).
Clang fails to compile gdb.cp/step-and-next-inline.cc, with the
following error:
clang-12: error: unknown argument: '-gstatement-frontiers'
compiler exited with status 1
This commit fixes the testcase by only passing -gstatement-frontiers
when building with GCC. This commit also alters two checks marked as
known failures, to mark them as known failures only when built using
GCC.
gdb/testsuite/ChangeLog:
* gdb.cp/step-and-next-inline.exp: Only require
-gstatement-frontiers when building with GCC.
Only setup KFAIL's for GCC issues when using
a GCC-built executable.
include * opcode/pru.h: Add LMBD (left-most bit detect) opcode index
opcodes * pru-opc.c: Add opcode description for LMBD (left-most bit detect)
gas * testsuite/gas/pru/misc.s: Add tests for lmbd (left-most bit detect)
* testsuite/gas/pru/misc.d: Add tests for lmbd (left-most bit
This patch:
+ Adds new ACCDATA_EL1 (Accelerator Data) system register, see [0].
+ Adds LS64 instruction tests.
+ Update LS64 feature test with new register.
+ Fix comment for AARCH64_OPND_Rt_LS64.
[0] https://developer.arm.com/docs/ddi0595/i/aarch64-system-registers/accdata_el1
Note: as this is register only extension we do not want to hide these
registers behind -march flag going forward (they should be enabled by
default).
Atomic 64-byte load/store instructions limit Rt register number to
values matching below condition (register <Xt> number must be even
and <= 22):
if Rt<4:3> == '11' || Rt<0> == '1' then UNDEFINED;
This patch adds check if Rt fulfills above requirement.
For more details regarding atomic 64-byte load/store instruction for
Armv8.7 please refer to Arm A64 Instruction set documentation for
Armv8-A architecture profile, see document page 157 for load
instruction, and pages 414-418 for store instructions of [0].
[0]: https://developer.arm.com/docs/ddi0596/i
elfedit.c:904:15: error: 'osabi' may be used uninitialised in this function [-Werror=maybe-uninitialized]
904 | osabi = concat (osabi, "|", osabis[i].name, NULL);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
* elfedit (usage): Avoid false positive "may be used uninitialised".
Don't leak memory.
This patch fixes fails adding library dependencies for xcoff, and
improves the error message should stat fail for an archive member.
"tmpdir/artest.a: File not found" is plainly wrong.
Fixes these fails:
powerpc-aix5.1 +FAIL: ar adding library dependencies
powerpc-aix5.2 +FAIL: ar adding library dependencies
rs6000-aix4.3.3 +FAIL: ar adding library dependencies
rs6000-aix5.1 +FAIL: ar adding library dependencies
rs6000-aix5.2 +FAIL: ar adding library dependencies
* archive.c (bfd_ar_hdr_from_filesystem): Use bfd_set_input_error
when stat of archive member fails.
* coff-rs6000.c (xcoff_write_archive_contents_old),
(xcoff_write_archive_contents_big): Likewise, and handle in-memory
bfd.
This feature doesn't actually require plugin support, that was a
mistake in the previous patch. Fixes these fails:
hppa-hp-hpux10 +FAIL: ar adding library dependencies
i386-bsd +FAIL: ar adding library dependencies
i386-msdos +FAIL: ar adding library dependencies
ns32k-netbsd +FAIL: ar adding library dependencies
ns32k-pc532-mach +FAIL: ar adding library dependencies
pdp11-dec-aout +FAIL: ar adding library dependencies
* ar.c (main): Use plugin_target rather than "target" when
resetting libdeps_bfd target.
Originally, if the -mabi option isn't set, then assembler will set the
abi according to the architecture string in the riscv_after_parse_args.
But we should also check and reset the abi later since the architecture
string may be reset by the elf attributes. Therefore, set the abi to
the elf_flags in the riscv_after_parse_args seems too early. Besides,
we have to set the abi_xlen before assembling any instruction, so it
should be safe to call riscv_set_abi_by_arch at the place that we set
start_assemble to TRUE. However, one minor case is that we won't call
the md_assemble when we are assembling an file without any instruction.
It seems that we still need to set the abi in riscv_elf_final_processing,
to make sure that abi can be updated according to the elf arch attributes.
For the rv32i and most elf toolchains, this patch can fix the mis-matched
ABI errors for Run pr26391-5 and Run pr26391-6 testcases. Besides, it
also correct the elf header flags of the output objects. Consider the
new testcases, mabi-fail-02 and mabi-noabi-attr-[01|02|03], they are
failed before applying this patch.
But I still get the mis-matched ABI errors for the following toolchains
when runnung the riscv-gnu-toolchain regressions,
newlib-rv32imafc-ilp32f-[medlow|medany]
linux-rv32imac-ilp32-[medlow|medany]
linux-rv32imafdc-ilp32-[medlow|medany}
linux-rv64imac-lp64-[medlow|medany]
linux-rv64imafdc-lp64-[medlow|medany}
For the newlib-rv32imafc-ilp32f, although we try to choose the abi
according to the elf attributes, we will use FLOAT_ABI_SOFT rather
than the FLOAT_ABI_SINGLE for the assmebly file wihtout setting the
-mabi, but compiler will set the abi to FLOAT_ABI_SINGLE for the
C files.
As for the linux toolchains, we also get fails for Run pr26391-5 and
Run pr26391-6 testcases. Since the linux toolchain won't generate elf
attributes to correct the ISA, and the --with-arch configure option
isn't set, assembler will try to set the default arch to rv[32|64]g,
which means the FLOAT_ABI_DOUBLE will be choosed, and may be conflict
with the abi set by the toolchain.
Therefore, I would suggest that it's is more safe to set the --with-arch
when building binutils, but it may break some testcases. For example,
ld-scripts/fill and ld-scripts/empty-address-2 may be broken when c-ext
is set. We might insert R_RISCV_ALIGN to make sure the 4-byte alignment,
but the dump result will be a bit different from what the testcase expected.
However, this patch only fix the problem - the abi, elf_flags and the
instruction, which is generated according to the abi_xlen, are all fixed
once the elf attributes are set for most elf toolchains. Other mis-matched
ABI problems should be fixed when we always build the binutils with the
--with-arch= configure option.
gas/
* config/tc-riscv.c (explicit_mabi): New boolean to indicate if
the -mabi= option is explictly set.
(md_parse_option): Set explicit_mabi to TRUE if -mabi is set.
(riscv_set_abi_by_arch): New function. If the -mabi option isn't
set, then we set the abi according to the architecture string.
Otherwise, check if there are conflicts between architecture
and abi setting.
(riscv_after_parse_args): Move the abi setting to md_assemble nad
riscv_elf_final_processing.
(md_assemble): Call the riscv_set_abi_by_arch when we set the
start_assemble to TRUE.
(riscv_elf_final_processing): Likewise, in case the file without
any instruction.
* testsuite/gas/riscv/mabi-attr-01.s: New testcase.
* testsuite/gas/riscv/mabi-attr-02.s: Likewise.
* testsuite/gas/riscv/mabi-attr-03.s: Likewise.
* testsuite/gas/riscv/mabi-fail-01.d: Likewise.
* testsuite/gas/riscv/mabi-fail-01.l: Likewise.
* testsuite/gas/riscv/mabi-fail-02.d: Likewise.
* testsuite/gas/riscv/mabi-fail-02.l: Likewise.
* testsuite/gas/riscv/mabi-noabi-attr-01a.d: Likewise.
* testsuite/gas/riscv/mabi-noabi-attr-01b.d: Likewise.
* testsuite/gas/riscv/mabi-noabi-attr-02a.d: Likewise.
* testsuite/gas/riscv/mabi-noabi-attr-02b.d: Likewise.
* testsuite/gas/riscv/mabi-noabi-attr-03a.d: Likewise.
* testsuite/gas/riscv/mabi-noabi-attr-03b.d: Likewise.
* testsuite/gas/riscv/mabi-noabi-march-01.d: Likewise.
* testsuite/gas/riscv/mabi-noabi-march-02.d: Likewise.
* testsuite/gas/riscv/mabi-noabi-march-03.d: Likewise.
class Plugin_manager has
// A pointer to the current plugin. Used while loading plugins.
Plugin_list::iterator current_;
The same iterator is shared by all threads. It is OK to use it to load
plugins since only one thread loads plugins. Avoid sharing Plugin_list
iterator in all other cases.
PR gold/26200
* plugin.cc (Plugin_manager::claim_file): Don't share Plugin_list
iterator.
(Plugin_manager::all_symbols_read): Likewise.
(Plugin_manager::cleanup): Likewise.
In commit:
commit 6d81691950
CommitDate: Sat Sep 19 09:44:58 2020 +0100
gdb/fortran: Move Fortran expression handling into f-lang.c
A bug was introduced that broke GDB's ability to perform debug dumps
of expressions containing function calls. For example this would no
longer work:
(gdb) set debug expression 1
(gdb) print call_me (&val)
Dump of expression @ 0x4eced60, before conversion to prefix form:
Language c, 12 elements, 16 bytes each.
Index Opcode Hex Value String Value
0 OP_VAR_VALUE 40 (...............
1 OP_M2_STRING 79862864 P...............
2 unknown opcode: 224 79862240 ................
3 OP_VAR_VALUE 40 (...............
4 OP_VAR_VALUE 40 (...............
5 OP_RUST_ARRAY 79861600 `...............
6 UNOP_PREDECREMENT 79861312 @...............
7 OP_VAR_VALUE 40 (...............
8 UNOP_ADDR 61 =...............
9 OP_FUNCALL 46 ................
10 BINOP_ADD 1 ................
11 OP_FUNCALL 46 ................
Dump of expression @ 0x4eced60, after conversion to prefix form:
Expression: `call_me (&main::val, VAL(Aborted (core dumped)
The situation was even worse for Fortran function calls, or array
indexes, which both make use of the same expression opcode.
The problem was that in a couple of places the index into the
expression array was handled incorrectly causing GDB to interpret
elements incorrectly. These issues are fixed in this commit.
There are already some tests to check GDB when 'set debug expression
1' is set, these can be found in gdb.*/debug-expr.exp. Unfortunately
the cases above were not covered.
In this commit I have cleaned up all of the debug-expr.exp files a
little, there was a helper function that had clearly been copied into
each file, this is now moved into lib/gdb.exp.
I've added a gdb.fortran/debug-expr.exp test file, and extended
gdb.base/debug-expr.exp to cover the function call case.
gdb/ChangeLog:
* expprint.c (print_subexp_funcall): Increment expression position
after reading argument count.
* f-lang.c (print_subexp_f): Skip over opcode before calling
common function.
(dump_subexp_body_f): Likewise.
gdb/testsuite/ChangeLog:
* gdb.base/debug-expr.c: Add extra function to allow for an
additional test.
* gdb.base/debug-expr.exp (test_debug_expr): Delete, replace calls
to this proc with gdb_test_debug_expr. Add an extra test.
* gdb.cp/debug-expr.exp (test_debug_expr): Delete, replace calls
to this proc with gdb_test_debug_expr, give the tests names
* gdb.dlang/debug-expr.exp (test_debug_expr): Delete, replace
calls to this proc with gdb_test_debug_expr, give the tests names
* gdb.fortran/debug-expr.exp: New file.
* gdb.fortran/debug-expr.f90: New file.
* lib/gdb.exp (gdb_test_debug_expr): New proc.
When creating a .debug_ranges section using the testsuite's DWARF
assembler, it currently looks like this:
ranges {
sequence {
{base ...}
{range ...}
{range ...}
}
}
The sub-tree of sequence is manually traversed as a list of lists. I
think it would be nicer if `base` and `range` where procedure, just like
the other levels:
ranges {
sequence {
base ...
range ...
range ...
}
}
That makes the implementation more robust, and the usage a bit nicer
(less special characters). It also allows having comments in between
the range list entries:
ranges {
sequence {
base ...
range ...
# Hello world.
range ...
}
}
... which doesn't work with the current approach.
gdb/testsuite/ChangeLog:
* lib/dwarf.exp (ranges): Handle "base" and "range" as
proceduresu.
* gdb.dwarf/dw2-bad-elf.exp: Adjust.
* gdb.dwarf2/dw2-inline-many-frames.exp: Adjust.
* gdb.dwarf2/dw2-inline-stepping.exp: Adjust.
* gdb.dwarf2/dw2-ranges-base.exp: Adjust.
* gdb.dwarf2/dw2-ranges-func.exp: Adjust.
* gdb.dwarf2/dw2-ranges-overlap.exp: Adjust.
* gdb.dwarf2/dw2-ranges-psym.exp: Adjust.
* gdb.dwarf2/enqueued-cu-base-addr.exp: Adjust.
Change-Id: I0b2af480faff54d0fd4214e0cc8d042d9583a865
In python 3, itertools is a builtin module, so whether or not the
python you link against is a shared or a static one, importing it
works.
Change the import test to use ctypes which is a dynamic module in both
python 2 and 3.
gdb/ChangeLog:
PR python/26832
* configure: Regenerate.
* configure.ac: Check for python modules ctypes instead of
itertools.
GDB currently fails to build with (at least) Clang 10 and 11, due to:
$ make
CXX macroexp.o
../../src/gdb/macroexp.c:125:3: error: definition of implicit copy constructor for 'macro_buffer' is deprecated because it has a user-declared destructor [-Werror,-Wdeprecated-copy-dtor]
~macro_buffer ()
^
Now, we could just add the copy constructor, like we already have a
copy assignment operator. And like that assignment operator, we would
assert that only shared buffers can be copied from.
However, it is hard to see why only shared buffers need to be copied.
I mean, it must be true, otherwise macro support would be broken,
since currently GDB is relying on the default implementation of the
copy constructor, which just copies the fields, which can't work
correctly for the non-shared version. Still, it's not easy to tell
from the code that that is indeed correct, that there isn't some
corner case that would require copying a non-shared buffer.
Or to put it simply - the tangling of shared and non-shared buffers in
the same macro_buffer struct makes this structure hard to understand.
My reaction was -- try splitting the macro_buffer class into two
classes, one for non-shared buffers, and another for shared buffers.
Comments and asserts like these:
...
SRC must be a shared buffer; DEST must not be one. */
static void
scan (struct macro_buffer *dest,
struct macro_buffer *src,
struct macro_name_list *no_loop,
const macro_scope &scope)
{
gdb_assert (src->shared);
gdb_assert (! dest->shared);
... made me suspect it should be possible. Then after the split it
should be easier to reimplement either of the classes if we want.
So I decided to try splitting the struct in two distinct types, and
see where that leads. It turns out that there is really no good
reason for a single struct, no code that wants to work with either
shared or non-shared buffers. It's always shared for input being
parsed, and non-shared for output.
This commit is the result. I named the new classes
shared_macro_buffer and growable_macro_buffer.
A future direction could be for example to make shared_macro_buffer
wrap a string_view and growable_macro_buffer a std::string. With that
in mind, other than text/len, only the 'last_token' field is common to
both classes. I didn't feel like creating a base class just for that
single field.
I constified shared_macro_buffer's 'text' field, which of course had
some knock-on effects, fixed in the patch.
On the original warning issued by Clang -- now it is clear that only
the shared version needs to be copied. Since this class doesn't need
a user-declared destructor, the default implementations of the copy
assign/ctor can be used, and Clang no longer warns.
The growable version doesn't need to be copied, so I disabled
copy/assign for it.
gdb/ChangeLog:
* macroexp.c (struct macro_buffer): Split in two classes. Add
uses adjusted.
(struct shared_macro_buffer): New, factored out from struct
macro_buffer.
(struct growable_macro_buffer): New, factored out from struct
macro_buffer.
(set_token, get_comment, get_identifier, get_pp_number)
(get_character_constant, get_string_literal, get_punctuator)
(get_next_token_for_substitution): Constify parameters.
(substitute_args): Constify locals.
Change-Id: I5712e30e826d949715703b2e9172adf04e63b152
* lexsup.c (parse_args): Add more checks of the mapfile. If it is
a directory use the basename of the output file as the file
component. If the % character is present, replace it with the
full output filepath.
* testsuite/ld-scripts/map-address.exp: Add test of %
functionality.
* ld.texi: Document the new behaviour.
Update elfedit message to
$ elfedit --help
Usage: elfedit <option(s)> elffile(s)
Update the ELF header of ELF files
The options are:
--input-mach [none|i386|iamcu|l1om|k1om|x86_64]
Set input machine type
--output-mach [none|i386|iamcu|l1om|k1om|x86_64]
Set output machine type
--input-type [none|rel|exec|dyn]
Set input file type
--output-type [none|rel|exec|dyn]
Set output file type
--input-osabi [none|HPUX|NetBSD|GNU|Linux|Solaris|AIX|Irix|FreeBSD|TRU64|Modesto|OpenBSD|OpenVMS|NSK|AROS|FenixOS]
Set input OSABI
--output-osabi [none|HPUX|NetBSD|GNU|Linux|Solaris|AIX|Irix|FreeBSD|TRU64|Modesto|OpenBSD|OpenVMS|NSK|AROS|FenixOS]
Set output OSABI
--enable-x86-feature [ibt|shstk]
Enable x86 feature
--disable-x86-feature [ibt|shstk]
Disable x86 feature
-h --help Display this information
-v --version Display the version number of elfedit
Report bugs to <http://www.sourceware.org/bugzilla/>
* elfedit.c: Include "libiberty.h".
(usage): Update help message.
Extract PAC (Pointer Authentication) feature from Armv8.3-A.
Please note that PAC stays a Armv8.3-A feature but now can be
assigned to other architectures or CPUs.
In a longer series that I am working on, I needed to remove the
objfile parameter from abbrev_table::read. It seemed to me that this
was a simple and relatively harmless patch, so I'm sending it now.
gdb/ChangeLog
2020-11-05 Tom Tromey <tom@tromey.com>
* dwarf2/read.c (read_cutu_die_from_dwo)
(cutu_reader::cutu_reader, cutu_reader::cutu_reader)
(build_type_psymtabs_1): Update.
* dwarf2/abbrev.h (struct abbrev_table): Remove objfile
parameter.
* dwarf2/abbrev.c (abbrev_table::read): Remove objfile parameter.
Don't read section. Add assert.
This patch:
+ updates RAS feature system registers with new RAS 1.1 regs.
+ extends RAS/RAS 1.1 support for all architecture levels of Armv8-A.
Please note that early Armv8-A architectures do not officially support RAS
extension.
Rationale of the patch:
To ease development so that user-friendly RAS system registers operands can be
used. Certain use cases require developers to enable only more generic
architecture (e.g. -march=armv8-a) during system development. Users must use
RAS extension registers bearing in mind that system they use must support it.
The RAS (Reliability, Availability, Serviceability) extension is a
system-level extension that defines a number of system registers.
RAS 1.1 (FEAT_RASv1p1) introduces five new system registers:
ERXPFGCTL_EL1, ERXPFGCDN_EL1, ERXMISC2_EL1, ERXMISC3_EL1 and
ERXPFGF_EL1.
For details see [0].
[0] https://developer.arm.com/docs/ddi0595/i/
Sometimes the Ada compiler will emit an "__XVL" name for a field. The
Ada compiler describes:
-- Second, the variable-length fields themselves are represented by
-- replacing the type by a special access type. The designated type of
-- this access type is the original variable-length type, and the fact
-- that this field has been transformed in this way is signalled by
-- encoding the field name as:
-- field___XVL
Currently gdb describes such fields as having "access" type, but this
is inaccurate. This patch changes gdb to avoid printing "access" in
this case.
gdb/ChangeLog
2020-11-04 Tom Tromey <tromey@adacore.com>
* ada-typeprint.c (ada_print_type): Handle __XVL fields.
gdb/testsuite/ChangeLog
2020-11-04 Tom Tromey <tromey@adacore.com>
* gdb.ada/funcall_ref.exp: Update.
* gdb.ada/var_rec_arr.exp: Update.
In some cases the name of an Ada type cannot be decoded by
decoded_type_name. For example, the name
"p__complex_variable_record_type__T9s" in the included test case is
rejected due to the "T". This causes ptype to display the full
contents of a record type -- when in fact the name is available and
ought to be printed.
Fixing this in decoded_type_name isn't possible because the "__T" name
is not the real name of the type -- it is just a compiler-assigned
name of convenience.
This patch fixes the problem by using the resolved type's name when
the original type's name isn't suitable.
gdb/ChangeLog
2020-11-04 Tom Tromey <tromey@adacore.com>
* ada-typeprint.c (ada_print_type): Handle __T types.
gdb/testsuite/ChangeLog
2020-11-04 Tom Tromey <tromey@adacore.com>
* gdb.ada/rec_ptype.exp: New file.
* gdb.ada/rec_ptype/main.adb: New file.
* gdb.ada/rec_ptype/p.ads: New file.
With -fgnat-encodings=minimal, Gnat will emit DW_TAG_array_type that
has a name -- and this is the only time the name is emitted for the
type. (For comparison, in C a typedef would be emitted in this
situation.)
This patch changes gdb to recognize the name of an array type. This
is limited to Ada, to avoid any potential problems if some rogue DWARF
happens to name an array type in some other language, and to avoid
loading unnecessary partial DIEs.
gdb/ChangeLog
2020-11-04 Tom Tromey <tromey@adacore.com>
* dwarf2/read.c (add_partial_symbol, process_die):
Handle DW_TAG_array_type.
(is_type_tag_for_partial): Add "lang" parameter.
(load_partial_dies, new_symbol): Handle DW_TAG_array_type.
gdb/testsuite/ChangeLog
2020-11-04 Tom Tromey <tromey@adacore.com>
* gdb.ada/tick_length_array_enum_idx.exp: Add ptype test.
* gdb.ada/tick_length_array_enum_idx/foo_n207_004.adb
(PT_Full): New variable.
* gdb.ada/tick_length_array_enum_idx/pck.adb
(Full_PT): New type.
Testing with -fgnat-encodings=minimal showed that the Ada code failed
to use the bit stride of an array when taking a slice. This patch
fixes the oversight.
gdb/ChangeLog
2020-11-04 Tom Tromey <tromey@adacore.com>
* ada-lang.c (ada_value_slice_from_ptr): Use bit size.
gdb/testsuite/ChangeLog
2020-11-04 Tom Tromey <tromey@adacore.com>
* gdb.ada/array_of_variant.exp: New file.
* gdb.ada/array_of_variant/p.adb: New file.
* gdb.ada/array_of_variant/pck.ads: New file.
* gdb.ada/array_of_variant/pck.adb: New file.
