gdb/ChangeLog:
* infrun.h (debug_infrun): Make a bool.
* infrun.c (debug_infrun): Make a bool.
(_initialize_infrun): Use add_setshow_boolean_cmd to define "set
debug infrun".
Change-Id: If934106a6d3f879b93d265855eb705b1d606339a
The same pattern happens often to define a "debug_printf" macro:
#define displaced_debug_printf(fmt, ...) \
do \
{ \
if (debug_displaced) \
debug_prefixed_printf ("displaced", __func__, fmt, ##__VA_ARGS__); \
} \
while (0)
Move this pattern behind a helper macro, debug_prefixed_printf_cond and
update the existing macros to use it.
gdb/ChangeLog:
* displaced-stepping.h (displaced_debug_printf): Use
debug_prefixed_printf_cond.
* dwarf2/read.c (dwarf_read_debug_printf): Likewise.
(dwarf_read_debug_printf_v): Likewise.
* infrun.h (infrun_debug_printf): Likewise.
* linux-nat.c (linux_nat_debug_printf): Likewise.
gdbsupport/ChangeLog:
* common-debug.h (debug_prefixed_printf_cond): New.
* event-loop.h (event_loop_debug_printf): Use
debug_prefixed_printf_cond.
Change-Id: I1ff48b98b8d1cc405d1c7e8da8ceadf4e3a17f99
When running test-case gdb.arch/i386-mpx-call.exp with target board unix/-m32,
we run into:
...
(gdb) continue^M
Continuing.^M
(gdb) FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd0: continue to a bnd violation
...
Let's look first for reference at -m64, where the test passes.
The test-case uses -mmpx -fcheck-pointer-bounds to generate pointer checks in
the exec. Effectively, -fcheck-pointer-bounds modifies the calling ABI: a
call passes pointer bounds as well as arguments. The call to upper (with
four pointer arguments and an int argument, passed in 5 registers) is modified
like this:
...
lea -0xa0(%rbp),%rcx
lea -0x80(%rbp),%rdx
lea -0x60(%rbp),%rsi
lea -0x40(%rbp),%rax
mov $0x0,%r8d
+ bndmov -0x110(%rbp),%bnd3
+ bndmov -0x100(%rbp),%bnd2
+ bndmov -0xf0(%rbp),%bnd1
+ bndmov -0xe0(%rbp),%bnd0
mov %rax,%rdi
- callq <upper>
+ bnd callq <upper>
...
passsing the four pointer bounds in bounds registers BND0-3.
The top-level mechanism of the test is as follows:
- run the exec to after all mallocs are done, such that all pointer variables
are valid
- do inferior calls, similar to those present in the program
The inferior call mechanism doesn't differentiate between a call to a function
compiled with -fcheck-pointer-bounds, and one without. It merely resets the
bound registers to all-allowed state (see amd64_push_dummy_call), to make sure
the checks don't trigger during the inferior call. [ This is the same as what
happens when executing a call without bnd prefix when the BNDPRESERVE bit of
the BNDCFG register is set to 0, a provision for calling an instrumented
function using a non-instrumented call. ]
First, two inferior calls are done (default_run and verify_default_values)
with the bound registers unmodified by the test. So, the memory accesses are
performed with the bounds registers set by amd64_push_dummy_call to
all-allowed, and the bounds checks do not trigger.
Then we try to do an inferior call with modified bounds registers, set to
none-allowed. In order to do that, we set a breakpoint at *upper before
doing the inferior call. Once we hit the breakpoint during the inferior call,
the bounds registers are set to none-allowed, and we continue expecting to run
into an triggered bounds check, which takes the shape of a sigsegv.
Back to -m32. Here, the pointer arguments are passed in memory rather than
registers, so with -fcheck-pointer-bounds, the pointer bounds are placed in
the Bounds Table using bndstx:
...
movl $0x0,0x10(%eax)
lea -0x70(%ebp),%edx
mov %edx,0xc(%eax)
lea -0x5c(%ebp),%edx
mov %edx,0x8(%eax)
lea -0x48(%ebp),%edx
mov %edx,0x4(%eax)
lea -0x34(%ebp),%edx
mov %edx,(%eax)
lea 0xc(%eax),%edx
mov 0xc(%eax),%ecx
bndmov -0xa8(%ebp),%bnd1
bndstx %bnd1,(%edx,%ecx,1)
lea 0x8(%eax),%edx
mov 0x8(%eax),%ecx
bndmov -0xa0(%ebp),%bnd3
bndstx %bnd3,(%edx,%ecx,1)
lea 0x4(%eax),%edx
mov 0x4(%eax),%ecx
bndmov -0x98(%ebp),%bnd1
bndstx %bnd1,(%edx,%ecx,1)
mov (%eax),%edx
bndmov -0x90(%ebp),%bnd3
bndstx %bnd3,(%eax,%edx,1)
bnd call 804893f <upper>
...
Again, the bounds registers are reset at the start of the inferior call by
amd64_push_dummy_call, and modified by the test-case, but neither has any
effect. The code in upper reads the pointer bounds from the Bounds Table, not
from the bounds registers.
Note that for a test.c with an out-of-bounds access:
...
$ cat test.c
void foo (int *a) { volatile int v = a[1]; }
int main (void) { int a; foo (&a); return 0; }
$ gcc test.c -mmpx -fcheck-pointer-bounds -g -m32
$ ./a.out
Saw a #BR! status 1 at 0x804848d
...
and inferior call foo (&a) right before "bnd call foo" (at the point that the
bounds for a are setup in the bounds table) doesn't trigger a bounds violation:
...
(gdb) call foo (&a)
(gdb)
...
This is because the bounds table doesn't associate a pointer with bounds, but
rather a pair of pointer and pointer location. So, the bound is setup for &a,
with as location the pushed argument in the frame. The inferior call however
executes in a dummy frame, so the bound is checked for &a with as location the
pushed argument in the dummy frame, which is different, so the bounds check
doesn't trigger.
In conclusion, this is expected behaviour.
Update the test-case to not expect to override effective pointer bounds using
the bounds registers when the bounds passing is done via the Bounds Table.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-12-11 Tom de Vries <tdevries@suse.de>
PR testsuite/26991
* gdb.arch/i386-mpx-call.exp: Don't expect to trigger bounds
violations by setting bounds registers if the bounds are passed in the
Bounds Table.
I noticed that some of the lexers were calling write_dollar_variable
from the lexer. This seems like a bad practice, so this patch moves
the side effects into the parsers.
I tested this by re-running gdb.fortran and gdb.modula2; the Pascal
compiler on my machine seems not to work, so I couldn't test
gdb.pascal.
I note that the type-tracking in the Pascal is also incorrect, in that
a convenience variable's type may change between parsing and
evaluation (or even during the course of evaluation).
gdb/ChangeLog
2020-12-11 Tom Tromey <tom@tromey.com>
* p-exp.y (intvar): Remove global.
(DOLLAR_VARIABLE): Change type.
(start): Update.
(exp): Call write_dollar_variable here...
(yylex): ... not here.
* m2-exp.y (DOLLAR_VARIABLE): Change type.
(variable): Call write_dollar_variable here...
(yylex): ... not here.
* f-exp.y (DOLLAR_VARIABLE): Change type.
(exp): Call write_dollar_variable here...
(yylex): ... not here.
I noticed that install_variable will never return false, so this patch
changes the return type to void. I couldn't find a spot in history
where it did return false, maybe it's always been like this.
gdb/ChangeLog
2020-12-11 Tom Tromey <tom@tromey.com>
* varobj.c (varobj_create): Update.
(install_variable): Return void.
This changes instantiate_pretty_printer to use gdbpy_ref, removing a
call to Py_DECREF.
gdb/ChangeLog
2020-12-11 Tom Tromey <tom@tromey.com>
* varobj.c (instantiate_pretty_printer): Use gdbpy_ref.
One call to varobj_clear_saved_item is from the varobj destructor.
This is no longer needed, so this patch removes the call; then inlines
the function into the sole remaining caller.
gdb/ChangeLog
2020-12-11 Tom Tromey <tom@tromey.com>
* varobj.c (varobj_clear_saved_item): Remove.
(update_dynamic_varobj_children): Update.
(varobj::~varobj): Don't call varobj_clear_saved_item.
This changes varobj_item::value to be a value_ref_ptr, removing some
manual management.
gdb/ChangeLog
2020-12-11 Tom Tromey <tom@tromey.com>
* varobj.c (install_dynamic_child, varobj_clear_saved_item)
(update_dynamic_varobj_children, create_child)
(create_child_with_value): Update.
* varobj-iter.h (struct varobj_item) <value>: Now a
value_ref_ptr.
* python/py-varobj.c (py_varobj_iter::next): Call release_value.
This changes varobj_dynamic::saved_item to be a unique_ptr.
gdb/ChangeLog
2020-12-11 Tom Tromey <tom@tromey.com>
* varobj.c (struct varobj_dynamic) <saved_item>: Now unique_ptr.
(varobj_clear_saved_item, update_dynamic_varobj_children):
Update.
This changes varobj_iter::next to return a unique_ptr. This fits in
with the ongoing theme of trying to express these ownership transfers
via the type system.
gdb/ChangeLog
2020-12-11 Tom Tromey <tom@tromey.com>
* varobj.c (update_dynamic_varobj_children): Update.
* varobj-iter.h (struct varobj_iter) <next>: Change return type.
* python/py-varobj.c (struct py_varobj_iter) <next>: Change return
type.
(py_varobj_iter::next): Likewise.
This changes the varobj iteration code to use a C++ class rather than
a C struct with a separate "ops" structure. The only implementation
is updated to use inheritance. This simplifies the code quite nicely.
gdb/ChangeLog
2020-12-11 Tom Tromey <tom@tromey.com>
* varobj.c (update_dynamic_varobj_children, install_visualizer)
(varobj::~varobj): Update.
* varobj-iter.h (struct varobj_iter): Change to interface class.
(struct varobj_iter_ops): Remove.
(varobj_iter_next, varobj_iter_delete): Remove.
* python/py-varobj.c (struct py_varobj_iter): Derive from
varobj_iter. Add constructor, destructor. Rename members.
(py_varobj_iter::~py_varobj_iter): Rename from
py_varobj_iter_dtor.
(py_varobj_iter::next): Rename from py_varobj_iter_next.
(py_varobj_iter_ops): Remove.
(py_varobj_iter): Rename from py_varobj_iter_ctor.
(py_varobj_iter_new): Remove.
(py_varobj_get_iterator): Update.
This changes all_root_varobjs to take a function_view. This
simplifies some of the callers, in particular we can remove a data
type that only existed to be passed through.
gdb/ChangeLog
2020-12-11 Tom Tromey <tom@tromey.com>
* varobj.h (all_root_varobjs): Take a function_view.
* varobj.c (all_root_varobjs): Take a function_view.
(varobj_invalidate_iter): Remove unused parameter.
(varobj_invalidate): Update.
* mi/mi-cmd-var.c (struct mi_cmd_var_update): Remove.
(mi_cmd_var_update_iter): Change parameters.
This changes varobj.c:rootlist to be a std::list. This lets us remove
some code. std::list is chosen because its iterator invalidation
approach suits the all_root_varobjs API.
I considered replacing all_root_varobjs with "external iteration", but
haven't gotten around to doing so.
gdb/ChangeLog
2020-12-11 Tom Tromey <tom@tromey.com>
* varobj.c (struct varobj_root) <next>: Remove.
(struct vlist): Remove.
(rootlist): Now a std::list.
(install_variable, uninstall_variable, all_root_varobjs): Update.
varobj.c currently has its own hash table implementation. This patch
replaces it with htab_t, simplifying the code.
gdb/ChangeLog
2020-12-11 Tom Tromey <tom@tromey.com>
* varobj.c (VAROBJ_TABLE_SIZE): Remove.
(varobj_table): Now htab_t.
(varobj_get_handle, install_variable, uninstall_variable):
Update.
(hash_varobj, eq_varobj_and_string): New functions.
(hash_varobj): Update.
This changes bp_location to derive from refcounted_object, introduces
a ref_ptr specialization for this type, and then changes
bpstats::bp_location_at to use that specialization. This removes some
manual reference counting and simplifies the code.
gdb/ChangeLog
2020-12-11 Tom Tromey <tom@tromey.com>
* inline-frame.c (stopped_by_user_bp_inline_frame): Update.
* ada-lang.c (check_status_exception): Update.
* breakpoint.c (free_bp_location): Remove.
(decref_bp_location): Use bp_location_ref_policy.
(bpstats::bpstats): Don't call incref_bp_location.
(bpstats::~bpstats): Remove.
(bpstats::bpstats): Update.
(bpstat_check_watchpoint, bpstat_check_breakpoint_conditions)
(bp_location::bp_location): Update.
(incref_bp_location): Remove.
(bkpt_print_it): Update.
* breakpoint.h (class bp_location): Derive from
refcounted_object.
(struct bpstats): Remove destructor.
<bp_location_at>: Now a bp_location_ref_ptr.
<refc>: Remove.
(bp_location_ref_ptr): New typedef.
(struct bp_location_ref_policy): New.
We can remove scoped_inc_dec_ref by changing the sole user to instead
keep a vector of thread_info_ref objects. This removes some manual
reference counting and simplifies the code a bit.
gdb/ChangeLog
2020-12-11 Tom Tromey <tom@tromey.com>
* thread.c (class scoped_inc_dec_ref): Remove.
(tp_array_compar_ascending, tp_array_compar_descending): Change
parameter types.
(thread_apply_all_command): Use thread_info_ref.
This changes stop_context to use a thread_info_ref, removing some
manual reference counting.
gdb/ChangeLog
2020-12-11 Tom Tromey <tom@tromey.com>
* infrun.c (struct stop_context) <thread>: Now a thread_info_ref.
(stop_context::stop_context): Update.
(stop_context::~stop_context): Remove.
This changes current_inferior_ to be an inferior_ref, removing some
manual reference counting.
gdb/ChangeLog
2020-12-11 Tom Tromey <tom@tromey.com>
* inferior.c (current_inferior_): Change type.
(current_inferior, set_current_inferior, initialize_inferiors):
Update.
This changes enable_thread_stack_temporaries to use a thread_info_ref,
removing some manual reference counting.
gdb/ChangeLog
2020-12-11 Tom Tromey <tom@tromey.com>
* gdbthread.h (class enable_thread_stack_temporaries) <m_thr>:
Change type.
The Ravenscar support assumes that the thread ID is the same as the
CPU ID that appears in the Ada task structure. However, on some
systems, gdbserver will report thread IDs that are off by some
constant. This can happen, e.g., with qemu in a scenario where there
is an additional (unreported) CPU in the emulation.
The Ada Ravenscar runtimes have been modified to store this offset in
a global variable. This patch changes gdb to read this variable, when
it exists, and apply the offset to the base CPU ID. This fixes some
crashes that otherwise occur.
2020-12-11 Tom Tromey <tromey@adacore.com>
* ada-tasks.c (struct ada_tasks_pspace_data) <cpu_id_offset>: New
field.
(ada_get_tcb_types_info): Look for __gnat_gdb_cpu_first_id.
(read_atcb): Use cpu_id_offset.
When configuring gdb using --with-mpfr=no and running test-case
gdb.base/float128.exp, we run into:
...
FAIL: gdb.base/float128.exp: print large128 (GDB may be missing MPFR support!)
...
Fix this by detecting that gdb was build without mpfr using the show
configuration command, and changing the FAIL into UNSUPPORTED.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-12-11 Tom de Vries <tdevries@suse.de>
PR testsuite/26954
* gdb.base/float128.exp: Detect and handle no mpfr support.
That test fails intermittently for me. The problem is a race condition
between the exec syscall and GDB resuming threads.
The initial situation is that we have two threads, let's call them
"leader" and "other". Leader is the one who is going to do the exec.
We stop at the breakpoint on the all_started function, so both threads
are stopped. When resuming, GDB resumes leader first and other second.
However, between resuming the two threads, leader has time to run and do
its exec, making other disappear. When GDB tries to resume other, it is
ino longer there. We get some "Couldn't get registers: No such
process." messages, and the state is a bit messed up.
The issue can be triggered consistently by adding a small delay after
the resume syscall:
diff --git a/gdb/inf-ptrace.c b/gdb/inf-ptrace.c
index d5a062163c7..9540339a9da 100644
--- a/gdb/inf-ptrace.c
+++ b/gdb/inf-ptrace.c
@@ -308,6 +308,8 @@ inf_ptrace_target::resume (ptid_t ptid, int step, enum gdb_signal signal)
gdb_ptrace (request, ptid, (PTRACE_TYPE_ARG3)1, gdb_signal_to_host (signal));
if (errno != 0)
perror_with_name (("ptrace"));
+ for (int i = 0 ; i < 100; i++)
+ usleep (10000);
}
/* Wait for the child specified by PTID to do something. Return the
This patch is about fixing the test to avoid this, since the test is not
about testing this particular corner case. Handling of multi-threaded
program doing execs should be improved too, but that's not the goal of
this patch.
Fix it by adding a synchronization point in the test to make sure both
threads were resumed by GDB before doing the exec. I added two
pthread_barrier_wait calls in each thread (for a total of three). I
think adding one call in each thread would not be enough, because this
could happen:
- both threads reach the first barrier
- the "other" thread is scheduled so has time to run and hit the second
barrier
- the "leader" thread hits the all_started function breakpoint, causing
both threads to be stopped by GDB
- GDB resumes the "leader" thread
- Since the "other" thread has already reached the second barrier, the
"leader" thread is free to run past its second barrier and do the
exec, while GDB still hasn't resumed the second one
By adding two barrier calls in each thread, I think we are good. The test
passes consistently for me, even with the artificial delay added.
gdb/testsuite/ChangeLog:
PR gdb/24694
* gdb.multi/multi-arch-exec.c (thread_start, main): Add barrier
calls.
Change-Id: I25c8ea9724010b6bf20b42691c716235537d0e27
In commit 4d91ddd342 "[gdb/testsuite] Fix unbalanced braces in
gdb.tui/new-layout.exp", I tried to fix a problem with test-case
gdb.tui/new-layout.exp when running with tcl 8.5.
However, at that point I only had access to the log containing the failure,
and unfortunately my patch turned out not to be effective.
So, finally fix this problem by guarding the problematic code with:
...
if { [tcl_version_at_least 8 6] } { ... }
...
Tested on x86_64-linux, specifically SLE-11 where I ran into the failure.
gdb/testsuite/ChangeLog:
2020-12-10 Tom de Vries <tdevries@suse.de>
PR testsuite/26947
* gdb.tui/new-layout.exp: Don't execute tests with unbalanced curly
braces for tcl 8.5 and earlier.
I noticed a spurious newline on infrun debugging output. The following patch
fixes that. I'll push as obvious.
gdb/ChangeLog:
2020-12-10 Luis Machado <luis.machado@linaro.org>
* breakpoint.c (should_be_inserted): Don't output newline.
The FPSIMD dump in signal frames and ptrace FPSIMD dump in the SVE context
structure follows the target endianness, whereas the SVE dumps are
endianness-independent (LE).
Therefore, when the system is in BE mode, we need to reverse the bytes
for the FPSIMD data.
Given the V registers are larger than 64-bit, I've added a way for value
bytes to be set, as opposed to passing a 64-bit fixed quantity. This fits
nicely with the unwinding *_got_bytes function and makes the trad-frame
more flexible and capable of saving larger registers.
The memory for the bytes is allocated via the frame obstack, so it gets freed
after we're done inspecting the frame.
gdb/ChangeLog:
2020-12-10 Luis Machado <luis.machado@linaro.org>
* aarch64-linux-tdep.c (aarch64_linux_restore_vreg) New function.
(aarch64_linux_sigframe_init): Call aarch64_linux_restore_vreg.
* aarch64-tdep.h (V_REGISTER_SIZE): Move to ...
* arch/aarch64.h: ... here.
* nat/aarch64-sve-linux-ptrace.c: Include endian.h.
(aarch64_maybe_swab128): New function.
(aarch64_sve_regs_copy_to_reg_buf)
(aarch64_sve_regs_copy_from_reg_buf): Adjust FPSIMD entries.
* trad-frame.c (trad_frame_reset_saved_regs): Initialize
the data field.
(TF_REG_VALUE_BYTES): New enum value.
(trad_frame_value_bytes_p): New function.
(trad_frame_set_value_bytes): New function.
(trad_frame_set_reg_value_bytes): New function.
(trad_frame_get_prev_register): Handle register values saved as bytes.
* trad-frame.h (trad_frame_set_reg_value_bytes): New prototype.
(struct trad_frame_saved_reg) <data>: New field.
(trad_frame_set_value_bytes): New prototype.
(trad_frame_value_bytes_p): New prototype.
This function allows to create a BFD handle using an accessible memory
range in a target memory. It is currently contained in a JIT module but
this functionality may be of wider usefullness - for example, reading
ELF binaries contained within a core dump.
gdb/ChangeLog:
2020-12-07 Mihails Strasuns <mihails.strasuns@intel.com>
* jit.c (mem_bfd*, bfd_open_from_target_memory): Removed.
* gdb_bfd.h (gdb_bfd_open_from_target_memory): New function.
* gdb_bfd.c (mem_bfd*, gdb_bfd_open_from_target_memory): New functions.
https://github.com/riscv/riscv-asm-manual/pull/61
We aleady have sext.w, so just add sext.b, sext.h, zext.b, zext.h
and zext.w. In a certain sense, zext.b is not a pseudo - It is an
alias of andi. Similarly, sext.b and sext.h are aliases of other
rvb instructions, when we enable b extension; But they are pseudos
when we just enable rvi. However, this patch does not consider the
rvb cases. Besides, zext.w is only valid in rv64.
gas/
* config/tc-riscv.c (riscv_ext): New function. Use md_assemblef
to expand the zext and sext pseudos, to give them a chance to be
expanded into c-ext instructions.
(macro): Handle M_ZEXTH, M_ZEXTW, M_SEXTB and M_SEXTH.
* testsuite/gas/riscv/ext.s: New testcase.
* testsuite/gas/riscv/ext-32.d: Likewise.
* testsuite/gas/riscv/ext-64.d: Likewise.
include/
* opcode/riscv.h (M_ZEXTH, M_ZEXTW, M_SEXTB, M_SEXTH.): Added.
opcodes/
* riscv-opc.c (riscv_opcodes): Add sext.[bh] and zext.[bhw].
opcodes/
* disassemble.h (riscv_get_disassembler): Declare.
* disassemble.c (disassembler): Changed to riscv_get_disassembler.
* riscv-dis.c (riscv_get_disassembler): Check the elf privileged spec
attributes before calling print_insn_riscv.
(parse_riscv_dis_option): Same as the assembler, the priority of elf
attributes are higher than the options. If we find the privileged
attributes, but the -Mpriv-spec= is different, then output error/warning
and still use the elf attributes set.
bfd/
* elfxx-riscv.c (riscv_ext_dont_care_version): New function. Return
TRUE if we don't care the versions of the extensions. These extensions
are added to the subset list for special purposes, with the explicit
versions or the RISCV_UNKNOWN_VERSION versions.
(riscv_parse_add_subset): If we do care the versions of the extension,
and the versions are unknown, then report errors for the non-implicit
extensions, and return directly for the implicit one.
(riscv_arch_str1): Do not output i extension after e, and the extensions
which versions are unknown.
gas/
* config/tc-riscv.c (riscv_multi_subset_supports): Handle INSN_CLASS_ZICSR
and INSN_CLASS_ZIFENCEI.
* testsuite/gas/riscv/march-imply-i.s: New testcase.
* testsuite/gas/riscv/march-imply-i2p0-01.d: New testcase. The version
of i is less than 2.1, and zi* are supported in the chosen spec, so
enable the fence.i and csr instructions, also output the implicit zi* to
the arch string.
* testsuite/gas/riscv/march-imply-i2p0-02.d: Likewise, but the zi* are
not supported in the spec 2.2. Enable the related instructions since
i's version is less than 2.1, but do not output them.
* testsuite/gas/riscv/march-imply-i2p1-01.d: New testcase. The version
of i is 2.1, so don't add it's implicit zi*, and disable the related
instructions.
* testsuite/gas/riscv/march-imply-i2p1-01.l: Likewise.
* testsuite/gas/riscv/march-imply-i2p1-02.d: Likewise, and set the zi*
explicitly, so enable the related instructions.
* testsuite/gas/riscv/march-imply-i2p0.d: Removed.
* testsuite/gas/riscv/march-imply-i2p1.d: Removed.
include/
* opcode/riscv.h: Add INSN_CLASS_ZICSR and INSN_CLASS_ZIFENCEI.
opcodes/
* riscv-opc.c (riscv_opcodes): Control fence.i and csr instructions by
zifencei and zicsr.
Joel recently pointed out add_angle_brackets to me. This patch
changes one spot in ada-lang.c to use this function rather than doing
it on its own.
gdb/ChangeLog
2020-12-09 Tom Tromey <tromey@adacore.com>
* ada-lang.c (ada_lookup_encoded_symbol): Use add_angle_brackets.
In some cases, GNAT can emit 128-bit constants for fixed-point types.
This patch changes gdb to handle this scenario, by changing the
low-level rational-reading functions in dwarf2/read.c to work directly
with gdb_mpz values. (I'm not sure offhand if these 128-bit patches
have gone into upstream GCC yet -- but they will eventually, and
meanwhile I think it should be clear that this patch is otherwise
harmless.)
gdb/ChangeLog
2020-12-09 Tom Tromey <tromey@adacore.com>
* dwarf2/read.c (get_dwarf2_rational_constant): Change "numerator"
and "denominator" to gdb_mpz. Handle block forms.
(get_dwarf2_unsigned_rational_constant): Change "numerator" and
"denominator" to gdb_mpz.
(finish_fixed_point_type): Update.
(has_zero_over_zero_small_attribute): Update.
This removes ada-operator.def and fortran-operator.def, merging their
contents into std-operator.def.
Note that the comment for OP_EXTENDED0 is a bit wrong. IMO this
constant could be removed, as it is only used for a single assert that
does not provide much value. However, I haven't done so here.
gdb/ChangeLog
2020-12-09 Tom Tromey <tromey@adacore.com>
* expprint.c (op_name): Update.
* expression.h (enum exp_opcode): Update.
* std-operator.def: Add more opcodes.
* ada-operator.def, fortran-operator.def: Remove, moving contents
into std-operator.def.
I forgot to include fixes for review comments I got before pushing the
previous commits (or I pushed the wrong commits). This one fixes it.
- Return {} instead of false in get_discrete_low_bound and
get_discrete_high_bound.
- Compute high bound after confirming low bound is valid in
get_discrete_bounds.
gdb/ChangeLog:
* gdbtypes.c (get_discrete_low_bound, get_discrete_high_bound):
Return {} instead of false.
(get_discrete_bounds): Compute high bound only if low bound is
valid.
Change-Id: I5f9a66b3672adfac9441068c899ab113ab2c331a
Since commit 7c6f271296 ("gdb: make get_discrete_bounds check for
non-constant range bounds"), subscripting flexible array member fails:
struct no_size
{
int n;
int items[];
};
(gdb) p *ns
$1 = {n = 3, items = 0x5555555592a4}
(gdb) p ns->items[0]
Cannot access memory at address 0xfffe555b733a0164
(gdb) p *((int *) 0x5555555592a4)
$2 = 101 <--- we would expect that
(gdb) p &ns->items[0]
$3 = (int *) 0xfffe5559ee829a24 <--- wrong address
Since the flexible array member (items) has an unspecified size, the array type
created for it in the DWARF doesn't have dimensions (this is with gcc 9.3.0,
Ubuntu 20.04):
0x000000a4: DW_TAG_array_type
DW_AT_type [DW_FORM_ref4] (0x00000038 "int")
DW_AT_sibling [DW_FORM_ref4] (0x000000b3)
0x000000ad: DW_TAG_subrange_type
DW_AT_type [DW_FORM_ref4] (0x00000031 "long unsigned int")
This causes GDB to create a range type (TYPE_CODE_RANGE) with a defined
constant low bound (dynamic_prop with kind PROP_CONST) and an undefined
high bound (dynamic_prop with kind PROP_UNDEFINED).
value_subscript gets both bounds of that range using
get_discrete_bounds. Before commit 7c6f271296, get_discrete_bounds
didn't check the kind of the dynamic_props and would just blindly read
them as if they were PROP_CONST. It would return 0 for the high bound,
because we zero-initialize the range_bounds structure. And it didn't
really matter in this case, because the returned high bound wasn't used
in the end.
Commit 7c6f271296 changed get_discrete_bounds to return a failure if
either the low or high bound is not a constant, to make sure we don't
read a dynamic prop that isn't a PROP_CONST as a PROP_CONST. This
change made get_discrete_bounds start to return a failure for that
range, and as a result would not set *lowp and *highp. And since
value_subscript doesn't check get_discrete_bounds' return value, it just
carries on an uses an uninitialized value for the low bound. If
value_subscript did check the return value of get_discrete_bounds, we
would get an error message instead of a bogus value. But it would still
be a bug, as we wouldn't be able to print the flexible array member's
elements.
Looking at value_subscript, we see that the low bound is always needed,
but the high bound is only needed if !c_style. So, change
value_subscript to use get_discrete_low_bound and
get_discrete_high_bound separately. This fixes the case described
above, where the low bound is known but the high bound isn't (and is not
needed). This restores the original behavior without accessing a
dynamic_prop in a wrong way.
A test is added. In addition to the case described above, a case with
an array member of size 0 is added, which is a GNU C extension that
existed before flexible array members were introduced. That case
currently fails when compiled with gcc <= 8. gcc <= 8 produces DWARF
similar to the one shown above, while gcc 9 adds a DW_AT_count of 0 in
there, which makes the high bound known. A case where an array member
of size 0 is the only member of the struct is also added, as that was
how PR 28675 was originally reported, and it's an interesting corner
case that I think could trigger other funny bugs.
Question about the implementation: in value_subscript, I made it such
that if the low or high bound is unknown, we fall back to zero. That
effectively makes it the same as it was before 7c6f271296. But should
we instead error() out?
gdb/ChangeLog:
PR 26875, PR 26901
* gdbtypes.c (get_discrete_low_bound): Make non-static.
(get_discrete_high_bound): Make non-static.
* gdbtypes.h (get_discrete_low_bound): New declaration.
(get_discrete_high_bound): New declaration.
* valarith.c (value_subscript): Only fetch high bound if
necessary.
gdb/testsuite/ChangeLog:
PR 26875, PR 26901
* gdb.base/flexible-array-member.c: New test.
* gdb.base/flexible-array-member.exp: New test.
Change-Id: I832056f80e6c56f621f398b4780d55a3a1e299d7
get_discrete_bounds is not flexible for ranges (TYPE_CODE_RANGE), in the
sense that it returns true (success) only if both bounds are present and
constant values.
This is a problem for code that only needs to know the low bound and
fails unnecessarily if the high bound is unknown.
Split the function in two, get_discrete_low_bound and
get_discrete_high_bound, that both return an optional. Provide a new
implementation of get_discrete_bounds based on the two others, so the
callers don't have to be changed.
gdb/ChangeLog:
* gdbtypes.c (get_discrete_bounds): Implement with
get_discrete_low_bound and get_discrete_high_bound.
(get_discrete_low_bound): New.
(get_discrete_high_bound): New.
Change-Id: I986b5e9c0dd969800e3fb9546af9c827d52e80d0
get_discrete_bounds currently has three possible return values (see its
current doc for details). It appears that for all callers, it would be
sufficient to have a boolean "worked" / "didn't work" return value.
Change the return type of get_discrete_bounds to bool and adjust all
callers. Doing so simplifies the following patch.
gdb/ChangeLog:
* gdbtypes.h (get_discrete_bounds): Return bool, adjust all
callers.
* gdbtypes.c (get_discrete_bounds): Return bool.
Change-Id: Ie51feee23c75f0cd7939742604282d745db59172
Instead of returning a boolean status and returning the value through a
pointer, return an optional that does both jobs. This helps in the
following patches, and I think it is an improvement in general.
gdb/ChangeLog:
* ada-lang.c (ada_value_slice_from_ptr): Adjust.
(ada_value_slice): Adjust.
(pos_atr): Adjust.
* gdbtypes.c (get_discrete_bounds): Adjust.
(discrete_position): Return optional.
* gdbtypes.h (discrete_position): Return optional.
Change-Id: I758dbd8858b296ee472ed39ec35db1dbd624a5ae
For
.globl foo2
.section .data.foo,"aR"
.align 4
.type foo2, @object
.size foo2, 4
foo2:
.long 2
.globl foo1
.section .data.foo
.align 4
.type foo1, @object
.size foo1, 4
foo1:
.long 1
generate a new section if the SHF_GNU_RETAIN bit doesn't match.
* config/obj-elf.c (SEC_ASSEMBLER_SHF_MASK): New.
(get_section_by_match): Also check if SEC_ASSEMBLER_SHF_MASK of
sh_flags matches. Rename info to sh_info.
(obj_elf_change_section): Don't check previous SHF_GNU_RETAIN.
Rename info to sh_info.
(obj_elf_section): Rename info to sh_info. Set sh_flags for
SHF_GNU_RETAIN.
* config/obj-elf.h (elf_section_match): Rename info to sh_info.
Add sh_flags.
* testsuite/gas/elf/elf.exp: Run section27.
* testsuite/gas/elf/section24b.d: Updated.
* testsuite/gas/elf/section27.d: New file.
* testsuite/gas/elf/section27.s: Likewise.
Use the LOCALAPPDATA environment variable to determine the cache dir
when running on Windows with native command line, otherwise nasty
warning "Couldn't determine a path for index cached directory" appears.
Change-Id: I77903f9f0cb4743555866b8aea892cef55132589
Redo fix committed in commit 67748e0f66 "[gdb/testsuite] Make
gdb.arch/amd64-gs_base.exp unsupported for i386" using is_amd64_regs_target.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-12-08 Tom de Vries <tdevries@suse.de>
* gdb.arch/amd64-gs_base.exp: Undo commit 67748e0f66, reimplement
using is_amd64_regs_target.
When running test-case gdb.ada/mi_task_arg.exp with target board unix/-m32, I
run into:
...
(gdb) ^M
Expecting: ^(-stack-list-arguments 1[^M
]+)?(\^done,stack-args=\[ \
frame={level="0",args=\[\]}, \
frame={level="1",args=\[{name="<_task>",value="0x[0-9A-Fa-f]+"}\]}, \
frame={level="2",args=\[({name="self_id",value="0x[0-9A-Fa-f]+"})?\]},.*[^M
]+[(]gdb[)] ^M
[ ]*)
-stack-list-arguments 1^M
^done,stack-args=[ \
frame={level="0",args=[]}, \
frame={level="1",args=[{name="<_task>",value="0x808abf0"}]}, \
frame={level="2",args=[{name="self_id",value="<optimized out>"}]}, \
frame={level="3",args=[]},frame={level="4",args=[]}]^M
(gdb) ^M
FAIL: gdb.ada/mi_task_arg.exp: -stack-list-arguments 1 (unexpected output)
...
The problem is that we're expecting a $hex for the value of self_id, but
instead get <optimized out>.
Looking at the debug info for self_id:
...
<1><12a1f>: Abbrev Number: 84 (DW_TAG_subprogram)
<12a20> DW_AT_name : system__tasking__stages__task_wrapper
...
<2><12a35>: Abbrev Number: 61 (DW_TAG_formal_parameter)
<12a36> DW_AT_name : self_id
<12a40> DW_AT_location : 0x459e (location list)
...
it refers to location information here:
...
0000459e 08053060 080531ac (DW_OP_fbreg: 0)
000045aa 0805327c 080532a5 (DW_OP_fbreg: 0)
000045b6 08053320 08053324 (DW_OP_fbreg: 0)
...
while the pc used to retrieve the location information is 0x080531c5:
...
$ gdb -batch outputs/gdb.ada/mi_task_arg/task_switch \
-ex "break 57" -ex run -ex bt
...
#0 task_switch.break_me () at task_switch.adb:57
#1 0x0804aaae in task_switch.caller (<_task>=0x808abf0) \
at task_switch.adb:51
#2 0x080531c5 in system.tasking.stages.task_wrapper \
(self_id=<optimized out>) at s-tassta.adb:1295
...
which indeed falls outside of the ranges listed in the location info.
Fix this by accepting <optimized out> as valid value of self_id.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-12-08 Tom de Vries <tdevries@suse.de>
* gdb.ada/mi_task_arg.exp: Accept <optimized out> as valid value of
self_id.
