Consider this Fortran type:
type :: some_type
integer, allocatable :: array_one (:,:)
integer :: a_field
integer, allocatable :: array_two (:,:)
end type some_type
And a variable declared:
type(some_type) :: some_var
Now within GDB we try this:
(gdb) set $a = some_var
(gdb) p $a
$1 = ( array_one =
../../src/gdb/value.c:3968: internal-error: Unexpected lazy value type.
Normally, when an internalvar ($a in this case) is created, it is
non-lazy, the value is immediately copied out of the inferior into
GDB's memory.
When printing the internalvar ($a) GDB will extract each field in
turn, so in this case `array_one`. As the original internalvar is
non-lazy then the extracted field will also be non-lazy, with its
contents immediately copied from the parent internalvar.
However, when the field has a dynamic type this is not the case, in
value_primitive_field we see that any field with dynamic type is
always created lazy. Further, the content of this field will usually
not have been captured in the contents buffer of the original value, a
field with dynamic location is effectively a pointer value contained
within the parent value, with rules in the DWARF for how to
dereference the pointer.
So, we end up with a lazy lval_internalvar_component representing a
field within an lval_internalvar. This eventually ends up in
value_fetch_lazy, which currently does not support
lval_internalvar_component, and we see the error above.
My original plan for how to handle this involved extending
value_fetch_lazy to handle lval_internalvar_component. However, when
I did this I ran into another error:
(gdb) set $a = some_var
(gdb) p $a
$1 = ( array_one = ((1, 1) (1, 1) (1, 1)), a_field = 5, array_two = ((0, 0, 0) (0, 0, 0)) )
(gdb) p $a%array_one
$2 = ((1, 1) (1, 1) (1, 1))
(gdb) p $a%array_one(1,1)
../../src/gdb/value.c:1547: internal-error: void set_value_address(value*, CORE_ADDR): Assertion `value->lval == lval_memory' failed.
The problem now is inside set_value_component_location, where we
attempt to set the address for a component if the original parent
value has a dynamic location. GDB does not expect to ever set the
address on anything other than an lval_memory value (which seems
reasonable).
In order to resolve this issue I initially thought about how an
internalvar should "capture" the value of a program variable at the
moment the var is created. In an ideal world (I think) GDB would be
able to do this even for values with dynamic type. So in our above
example doing `set $a = some_var` would capture the content of
'some_var', but also the content of 'array_one', and also 'array_two',
even though these content regions are not contained within the region
of 'some_var'.
Supporting this would require GDB values to be able to carry around
multiple non-contiguous regions of memory as content in some way,
which sounds like a pretty huge change to a core part of GDB.
So, I wondered if there was some other solution that wouldn't require
such a huge change.
What if values with a dynamic location were though of like points with
automatic dereferencing? Given this C structure:
struct foo_t {
int *val;
}
struct foo_t my_foo;
Then in GDB:
(gdb) $a = my_foo
We would expect GDB to capture the pointer value in '$a', but not the
value pointed at by the pointer. So maybe it's not that unreasonable
to think that given a dynamically typed field GDB will capture the
address of the content, but not the actual content itself.
That's what this patch does.
The approach is to catch this case in set_value_component_location.
When we create a component location (of an lval_internalvar) that has
a dynamic data location, the lval_internalvar_component is changed
into an lval_memory. After this, both of the above issues are
resolved. In the first case, the lval_memory is still lazy, but
value_fetch_lazy knows how to handle that. In the second case, when
we access an element of the array we are now accessing an element of
an lval_memory, not an lval_internalvar_component, and calling
set_value_address on an lval_memory is fine.
gdb/ChangeLog:
* value.c (set_value_component_location): Adjust the VALUE_LVAL
for internalvar components that have a dynamic location.
gdb/testsuite/ChangeLog:
* gdb.fortran/intvar-dynamic-types.exp: New file.
* gdb.fortran/intvar-dynamic-types.f90: New file.
PR 27129
* aarch64-dis.c (determine_disassembling_preference): Move call to
aarch64_match_operands_constraint outside of the assertion.
* aarch64-asm.c (aarch64_ins_limm_1): Remove call to assert.
Replace with a return of FALSE.
The function create_exception_master_breakpoint in gdb/breakpoint.c attempts
to set a master exception breakpoint in each objfile. It tries this using
a libgcc/unwind probe, and if that fails then using the
_Unwind_DebugHook symbol:
...
for (objfile *objfile : current_program_space->objfiles ())
{
/* Try using probes. */
if (/* successful */)
continue;
/* Try using _Unwind_DebugHook */
}
...
The preference scheme works ok both if the objfile has debug info, and if it's
stripped.
But it doesn't work when the objfile has a .gnu_debuglink to a .debug file
(and the .debug file is present). What happens is that:
- we first encounter objfile libgcc.debug
- we try using probes, and this fails
- so we try _Unwind_DebugHook, which succeeds
- next we encounter objfile libgcc
- we try using probes, and this succeeds.
So, we end up with a master exception breakpoint in both libgcc (using probes)
and libgcc.debug (using _Unwind_DebugHook).
This eventually causes:
...
(gdb) PASS: gdb.cp/nextoverthrow.exp: post-check - next over a throw 3
next^M
src/gdb/infrun.c:6384: internal-error: \
void process_event_stop_test(execution_control_state*): \
Assertion `ecs->event_thread->control.exception_resume_breakpoint != NULL' \
failed.^M
A problem internal to GDB has been detected,^M
further debugging may prove unreliable.^M
Quit this debugging session? (y or n) FAIL: gdb.cp/nextoverthrow.exp: next
past catch (GDB internal error)
...
To trigger this internal-error, we need to use gcc-10 or later to compile the
test-case, such that it contains the fix for gcc PR97774 - "Incorrect line
info for try/catch".
Fix this by only trying to install the master exception breakpoint in
libgcc.debug using the _Unwind_DebugHook method, if the install using probes
in libgcc failed.
Tested on x86_64-linux.
gdb/ChangeLog:
2021-01-08 Tom de Vries <tdevries@suse.de>
PR gdb/26881
* breakpoint.c (create_exception_master_breakpoint_probe)
(create_exception_master_breakpoint_hook): Factor out
of ...
(create_exception_master_breakpoint): ... here. Only try to install
the master exception breakpoint in objfile.debug using the
_Unwind_DebugHook method, if the install using probes in objfile
failed.
Since this commit:
commit a5c641b57b
Date: Thu Oct 8 16:45:59 2020 +0100
gdb/fortran: Add support for Fortran array slices at the GDB prompt
A bug was introduced into GDB. Consider this Fortan array:
integer, dimension (1:10) :: array
array = 1
Now inside GDB:
(gdb) set $var = array
(gdb) set $var(1) = 2
Left operand of assignment is not an lvalue.
The problem is that the new code for slicing Fortran arrays now does
not set the lval type correctly for arrays that are not in memory.
This is easily fixed by making use of value_from_component.
After this the above example behaves as you'd expect.
gdb/ChangeLog:
* f-lang.c (fortran_value_subarray): Call value_from_component.
gdb/testsuite/ChangeLog:
* gdb.fortran/intvar-array.exp: New file.
* gdb.fortran/intvar-array.f90: New file.
We don't want arch-specific entries in the common ChangeLog files.
Most arches do this already, so clean up the recent additions, and
move some older entries down to help avoid confusing newcomers.
PR ld/13900
Linking this test crashes the linker, so disable it. The crash
was reported about 9 years ago but haven't made progress, so lets
avoid the failures in test runs.
Building the C tests with a cris-elf toolchain (gcc-10.2 &
newlib-4.1.0) currently fail due to warnings it emits:
cris-elf-ld: libc.a(lib_a-closer.o): in function `_close_r':
newlib/libc/reent/closer.c:47: warning: _close is not implemented and will always fail
This is because the default target for cris-elf is bare metal, not
the simulator. For that, we need -sim. So add it for elf targets.
We don't add it for all targets as the simulator (and testsuite)
run both libgloss programs as well as Linux userspace programs.
This is in preparation for converting h8300 over to the common memory
framework. It's not clear how much of a speed gain this was providing
in the first place -- a naive test of ~400k insns (using shlr.s) shows
that this code actually slowed things down a bit.
If anyone really cares about h8300 anymore, they can migrate to the
common insn caching logic.
This allows gdb to quickly dump & process the memory map that the sim
knows about. This isn't fully accurate, but is largely limited by the
gdb memory map format. While the sim supports RWX bits, gdb can only
handle RW or RO regions.
An earlier patch to ada-lang.c:do_full_match introduced a subtle
change to the semantics. The previous code did:
- if (strncmp (sym_name, search_name, search_name_len) == 0
- && is_name_suffix (sym_name + search_name_len))
- return true;
-
- if (startswith (sym_name, "_ada_")
whereas the new code unconditionally skips a leading "_ada_".
The difference occurs if the lookup name itself starts with "_ada_".
In this case, the symbol won't match.
Normally this doesn't seem to be a problem. However, it caused a
regression on one particular (internal) test case on one particular
platform.
This patch changes the code to handle this case. I don't know how to
write a reliable test case for this, so no test is included.
2021-01-07 Tom Tromey <tromey@adacore.com>
* ada-lang.c (do_full_match): Conditionally skip "_ada_" prefix.
A recent upstream patch of mine caused a regression in aggregate
assignment. The bug was that add_component_interval didn't properly
update the array contents in one resize case.
I found furthermore that there was no test case that would provoke
this failure. This patch fixes the bug and introduces a test.
gdb/ChangeLog
2021-01-07 Tom Tromey <tromey@adacore.com>
* ada-lang.c (add_component_interval): Start loop using vector's
updated size.
gdb/testsuite/ChangeLog
2021-01-07 Tom Tromey <tromey@adacore.com>
* gdb.ada/assign_arr.exp: Add 'others' test.
When doing a gdbserver build with CFLAGS/CXXFLAGS/LDFLAGS=-fsanitize=address
we run into:
...
ld: ../libiberty/libiberty.a(safe-ctype.o):
relocation R_X86_64_32 against `.data' can not be used when making a
shared object; recompile with -fPIC
collect2: error: ld returned 1 exit status
make[1]: *** [libinproctrace.so] Error 1
...
This started with commit 9664849417 "gdbsupport: make use of safe-ctype
functions from libiberty", which introduced a dependency of libinproctrace.so
on libiberty.
Fix this in gdbserver/Makefile.in by using a setup similar to what is done in
gcc-repo/src/libcc1/Makefile.am, such that ../libiberty/noasan/libiberty.a is
used instead.
Build on x86_64-linux, both with and without -fsanitize=address.
gdbserver/ChangeLog:
2021-01-07 Tom de Vries <tdevries@suse.de>
* Makefile.in (LIBIBERTY_NORMAL, LIBIBERTY_NOASAN, LIBIBERTY_PIC):
(LIBIBERTY_FOR_SHLIB): New var.
(LIBIBERTY): Set using $(LIBIBERTY_NORMAL).
(IPA_LIB): Use LIBIBERTY_FOR_SHLIB instead of LIBIBERTY in target rule.
Add support for the pause hint instruction, as specified in the
Zihintpause extension. The pause instruction is encoded as a
special form of a memory fence (which is available as part of the
base instruction set). The chosen encoding does not mandate any
particular memory ordering and therefore is a true hint.
bfd/
* elfxx-riscv.c (riscv_std_z_ext_strtab): Added zihintpause.
gas/
* config/tc-riscv.c (riscv_multi_subset_supports): Added
INSN_CLASS_ZIHINTPAUSE.
* testsuite/gas/riscv/pause.d: New testcase. Adding coverage for
the pause hint instruction.
* testsuite/gas/riscv/pause.s: Likewise.
include/
* opcode/riscv-opc.h: Added MATCH_PAUSE, MASK_PAUSE and DECLARE_INSN
for pause hint instruction.
* opcode/riscv.h (enum riscv_insn_class): Added INSN_CLASS_ZIHINTPAUSE.
opcodes/
* riscv-opc.c (riscv_opcodes): Add pause hint instruction.
For now we have supported the riscv big endian targets, so
xfail riscv64*-*-* for ld-scripts/empty-address-2 tests, to
cover both little endian and big endian targets.
ld/
* testsuite/ld-scripts/empty-address-2a.d: xfail riscv64*-*-*.
* testsuite/ld-scripts/empty-address-2b.d: Likewise.
Make sure we include unistd.h for getpid prototypes to fix build
warnings/errors with newer compilers & C libraries.
Doing that for close in openpf highlights these were using the
wrong function -- need to use fclose on FILE*, not close.
These tests pass again with a cris-elf toolchain.
In fact rev8/orc.b/zext.h are the aliases of grevi/gorci/pack[w], so we
should update them to INSN_ALIAS when we have supported their true instruction
in the future. Though we still use the [MATCH|MAKS]_[GREVI|GORCI|PACK|PACKW]
to encode them. Besides, the orc.b has the same encoding both in rv32 and
rv64, so we just keep one of them in the opcode table.
This patch is implemented according to the following link,
https://github.com/riscv/riscv-bitmanip/pull/101
2021-01-07 Claire Xenia Wolf <claire@symbioticeda.com>
Jim Wilson <jimw@sifive.com>
Andrew Waterman <andrew@sifive.com>
Maxim Blinov <maxim.blinov@embecosm.com>
Kito Cheng <kito.cheng@sifive.com>
Nelson Chu <nelson.chu@sifive.com>
bfd/
* elfxx-riscv.c (riscv_std_z_ext_strtab): Added zba, zbb and zbc.
gas/
* config/tc-riscv.c (riscv_multi_subset_supports): Handle INSN_CLASS_ZB*.
(riscv_get_default_ext_version): Do not check the default_isa_spec when
the version defined in the riscv_opcodes table is ISA_SPEC_CLASS_DRAFT.
* testsuite/gas/riscv/bitmanip-insns-32.d: New testcase.
* testsuite/gas/riscv/bitmanip-insns-64.d: Likewise.
* testsuite/gas/riscv/bitmanip-insns.s: Likewise.
include/
* opcode/riscv-opc.h: Added MASK/MATCH/DECLARE_INSN for ZBA/ZBB/ZBC.
* opcode/riscv.h (riscv_insn_class): Added INSN_CLASS_ZB*.
(enum riscv_isa_spec_class): Added ISA_SPEC_CLASS_DRAFT for the
frozen extensions.
opcodes/
* riscv-opc.c (riscv_opcodes): Add ZBA/ZBB/ZBC instructions.
(MASK_RVB_IMM): Used for rev8 and orc.b encoding.
$ ./config.sub powerpc-eabivle
Invalid configuration `powerpc-eabivle': OS `eabivle' not recognized
$ ./config.sub powerpc-unknown-eabivle
Invalid configuration `powerpc-unknown-eabivle': OS `eabivle' not recognized
Also powerpc-eabisim and probably some arm configurations.
* config.sub: Accept OS of eabi* and gnueabi*.
Testing showed that gdb was not correctly handling some fixed-point
binary operations correctly.
Addition and subtraction worked by casting the result to the type of
left hand operand. So, "fixed+int" had a different type -- and
different value -- from "int+fixed".
Furthermore, for multiplication and division, it does not make sense
to first cast both sides to the fixed-point type. For example, this
can prevent "f * 1" from yielding "f", if 1 is not in the domain of
"f". Instead, this patch changes gdb to use the value. (This is
somewhat different from Ada semantics, as those can yield a "universal
fixed point".)
This includes a new test case. It is only run in "minimal" mode, as
the old-style fixed point works differently, and is obsolete, so I
have no plans to change it.
gdb/ChangeLog
2021-01-06 Tom Tromey <tromey@adacore.com>
* ada-lang.c (ada_evaluate_subexp) <BINOP_ADD, BINOP_SUB>:
Do not cast result.
* valarith.c (fixed_point_binop): Handle multiplication
and division specially.
* valops.c (value_to_gdb_mpq): New function.
(value_cast_to_fixed_point): Use it.
gdb/testsuite/ChangeLog
2021-01-06 Tom Tromey <tromey@adacore.com>
* gdb.ada/fixed_points/pck.ads (Delta4): New constant.
(FP4_Type): New type.
(FP4_Var): New variable.
* gdb.ada/fixed_points/fixed_points.adb: Update.
* gdb.ada/fixed_points.exp: Add tests for binary operators.
Commit 3ec3145c5d ("gdb: introduce scoped debug prints") updated some
tests using "set debug infrun" to handle the fact that a debug print is
now shown after the prompt, after an inferior stop. The same issue
happens in gdb.threads/signal-while-stepping-over-bp-other-thread.exp.
If I run it in a loop, it eventually fails like these other tests.
The problem is that the testsuite expects to see $gdb_prompt followed by
the end of the buffer. It happens that expect reads $gdb_prompt and the
debug print at the same time, in which case the regexp never matches and
we get a timeout.
The fix is the same as was done in 3ec3145c5d, make the testsuite
believe that the prompt is the standard GDB prompt followed by that
debug print.
Since that test uses gdb_test_sequence, and the expected prompt is in
gdb_test_sequence, add a -prompt switch to gdb_test_sequence to override
the prompt used for that call.
gdb/testsuite/ChangeLog:
* lib/gdb.exp (gdb_test_sequence): Accept -prompt switch.
* gdb.threads/signal-while-stepping-over-bp-other-thread.exp:
Pass prompt containing debug print to gdb_test_sequence.
Change-Id: I33161c53ddab45cdfeadfd50b964f8dc3caa9729
These fail on v850 due to that target using different .tbss section flags.
* testsuite/ld-scripts/rgn-at10.d: xfail v850.
* testsuite/ld-scripts/rgn-at11.d: Likewise.
These fail on tic30 due to that target using a different comment char.
* testsuite/gas/macros/app1.d: xfail tic30.
* testsuite/gas/macros/app2.d: Likewise.
* testsuite/gas/macros/app3.d: Likewise.
* testsuite/gas/macros/app4.d: Likewise.
RISC-V instruction/code is always little endian, but data might be
big-endian. Therefore, we can not use the original bfd_get/bfd_put
to get/put the code for big endian targets. Add new riscv_get_insn
and riscv_put_insn to always get/put code as little endian can resolve
the problem. Just remember to update them once we have supported
the 48-bit/128-bit instructions in the future patches.
bfd/
* config.bfd: Added targets riscv64be*-*-*, riscv32be*-*-* and
riscvbe*-*-*. Also added riscv_elf[32|64]_be_vec.
* configure.ac: Handle riscv_elf[32|64]_be_vec.
* configure: Regenerate.
* elfnn-riscv.c: Include <limits.h> and define CHAR_BIT for
riscv_is_insn_reloc.
(riscv_get_insn): RISC-V instructions are always little endian, but
bfd_get may be used for big-endian, so add new riscv_get_insn to handle
the insturctions.
(riscv_put_insn): Likewsie.
(riscv_is_insn_reloc): Check if we are relocaing an instruction.
(perform_relocation): Call riscv_is_insn_reloc to decide if we should
use riscv_[get|put]_insn or bfd_[get|put].
(riscv_zero_pcrel_hi_reloc): Use riscv_[get|put]_insn, bfd_[get|put]l32
or bfd_[get|put]l16 for code.
(riscv_elf_relocate_section): Likewise.
(riscv_elf_finish_dynamic_symbol): Likewise.
(riscv_elf_finish_dynamic_sections): Likewise.
(_bfd_riscv_relax_call): Likewise.
(_bfd_riscv_relax_lui): Likewise.
(_bfd_riscv_relax_align): Likewise.
(_bfd_riscv_relax_pc): Likewise.
(riscv_elf_object_p): Handled for big endian.
(TARGET_BIG_SYM, TARGET_BIG_NAME): Defined.
* targets.c: Add riscv_elf[32|64]_be_vec.
(_bfd_target_vector): Likewise.
gas/
* config/tc-riscv.c (riscv_target_format): Add elf64-bigriscv and
elf32-bigriscv.
(install_insn): Always write instructions as little endian.
(riscv_make_nops): Likewise.
(md_convert_frag_branch): Likewise.
(md_number_to_chars): Write data in target endianness.
(options, md_longopts): Add -mbig-endian and -mlittle-endian options.
(md_parse_option): Handle the endian options.
* config/tc-riscv.h: Only define TARGET_BYTES_BIG_ENDIAN if not
already defined.
* configure.tgt: Added riscv64be*, riscv32be*, riscvbe*.
ld/
* configure.tgt: Added riscvbe-*-*, riscv32be*-*-*, riscv64be*-*-*,
riscv32be*-*-linux*, and riscv64be*-*-linux*.
* Makefile.am: Added eelf32briscv.c, eelf32briscv_ilp32f.c and
eelf32briscv_ilp32.c.
* Makefile.in: Regenerate.
* emulparams/elf32briscv.sh: Added.
* emulparams/elf32briscv_ilp32.sh: Likewise.
* emulparams/elf32briscv_ilp32f.sh: Likewise.
* emulparams/elf64briscv.sh: Likewise.
* emulparams/elf64briscv_lp64.sh: Likewise.
* emulparams/elf64briscv_lp64f.sh: Likewise.
Looking through the history, it doesn't seem like the fr30 port was
ever merged. There used to be a testsuite/fr30-elf/ dir, but that
was punted back in 2005 as being dead too. Since there's no refs
and the dir hasn't been touched since 1999, lets assume no one will
ever notice or care.
These tests all fail to assemble when targeting the h8300 or h8300h
cpu variants with errors like:
rotl.s:242: Warning: Opcode `rotl.b' with these operand types not available in H8/300H mode
rotl.s:242: Error: invalid operands
It's been this way for years and no one seems to care, so disable
them for those targets since the assembler thinks it's impossible.
We don't need to manually enumerate every test. Use a glob function
like every other port and rely on the (already existing) #mach headers
in each file to filter out targets we don't care about.
