gdb/doc/ChangeLog:
* gdb.texinfo (GDB/MI Variable Objects): Document what happens
to the children of a varobj and its update range when -var-update
returns that the varobj's type changed.
This patch introduces a new language-specific callback for varobj
objects, allowing us to move the language-specific bits of the
varobj_value_is_changeable_p routine to language-specific functions.
This is more elegant than testing for the varobj's language...
gdb/ChangeLog:
* varobj.c (default_value_is_changeable_p): New function,
extracted from varobj_value_is_changeable_p. Add declaration.
(ada_value_is_changeable_p): New function, extracted from
varobj_value_is_changeable_p. Add declaration.
(struct language_specific): New field "value_is_changeable_p".
(languages): Add entries for new field.
(varobj_create): Set language before calling install_new_value.
(varobj_value_is_changeable_p): Reimplement to call the varobj's
"value_is_changeable_p" language callback.
This patch adds varobj support for Ada variables. Most of the code
is implemented in a separate Ada-specific file called ada-varobj.c.
The only bits in varobj.c are the functions used as the hooks in
the language-specific varobj's vector.
gdb/ChangeLog:
* ada-varobj.h, ada-varobj.c: New files.
* Makefile.in (SFILES): Add ada-varobj.c.
(HFILES_NO_SRCDIR): Add ada-varobj.h.
(COMMON_OBS): Add ada-varobj.o.
This patch introduces the framework necessary to support type mutations.
The only language that currently provides a language-specific hook for
that feature is Ada, but the hook remain unimplemented for now. The
actual implementation is tied to the rest of the varobj code for Ada,
and thus will be provided then.
gdb/ChangeLog:
* varobj.c (ada_value_has_mutated): Add declaration. New function.
(struct language_specific): New field "value_has_mutated".
(languages): Set field "value_has_mutated" in each entry of array.
(varobj_value_has_mutated): New function.
(varobj_udpdate): Add handling of type mutation.
(value_of_root): Add handling of type mutation.
(ada_value_has_mutated): New function.
On ia64-linux, GDB sometimes prints the following error when trying
to switch to a different task:
(gdb) task 3
Register 0 is not available
This is a random failure that sometimes happens, sometimes does not.
The error comes from the fact that the libunwind library is requesting
the value of register 0 (zero): This eventually leads us to
ia64-linux-nat.c:ia64_linux_fetch_register.
This function relies on ia64_cannot_fetch_register to determine
whether or not we have access to the register's value. The ptrace
interface does not provide the r0 value, and so we end up telling
the regcache that this register's value is not available. And yet,
for r0, we do not need to ask ptrace for its value, since it is
always zero.
So, the fix was to add a special rule for supplying a nul value
when regnum == IA64_GR0_REGNUM.
gdb/ChangeLog:
* ia64-linux-nat.c (ia64_linux_fetch_register): Add special
handling for r0.
set_gdbarch_process_record.
Initialize `arm_swi_record' field.
* arm-tdep.c (arm_process_record): New function.
(deallocate_reg_mem): New function.
(decode_insn): New function.
(thumb_record_branch): New function.
(thumb_record_ldm_stm_swi(): New function.
(thumb_record_misc): New function.
(thumb_record_ld_st_stack): New function.
(thumb_record_ld_st_imm_offset): New function.
(thumb_record_ld_st_reg_offset(): New function.
(thumb_record_add_sub_cmp_mov): New function.
(thumb_record_shift_add_sub): New function.
(arm_record_coproc_data_proc): New function.
(arm_record_coproc): New function.
(arm_record_b_bl): New function.
(arm_record_ld_st_multiple): New function.
(arm_record_ld_st_reg_offset): New function.
(arm_record_ld_st_imm_offset): New function.
(arm_record_data_proc_imm): New function.
(arm_record_data_proc_misc_ld_str): New function.
(arm_record_extension_space): New function.
(arm_record_strx): New function.
(sbo_sbz): New function.
(struct insn_decode_record): New structure for arm insn record.
(REG_ALLOC): New macro for reg allocations.
(MEM_ALLOC): New macro for memory allocations.
* arm-tdep.h (struct gdbarch_tdep): New field 'arm_swi_record'
Python scripting: Add new method Value.referenced_value to
gdb.Value which can dereference pointer as well as reference
values.
* NEWS: Add entry under 'Python scripting' about the new method
Value.referenced_value on gdb.Value objects.
* python/py-value.c (valpy_referenced_value): New function
defining a new method on gdb.Value objects which can dereference
pointer and reference values.
* testsuite/gdb.python/py-value.cc: Add test case for
testing the methodology exposing C++ values to Python.
* testsuite/gdb.python/py-value-cc.exp: Add tests testing the
methodology exposing C++ values to Python.
* testsuite/gdb.python/Makefile.in: Add py-value-cc to
EXECUTABLES.
* docs/gdb.texinfo (Python API/Values From Inferior): Add
description about the new method Value.referenced_value. Add
description on how Value.dereference is different (and similar)
to Value.referenced_value.
To reproduce the problem, simply try the following with any program:
(gdb) maintenance agent-eval 1.0
Critical error handler: process [...] terminated due to access violation
(this is on Windows; on GNU/Linux, the libc copes better)
The problem is quite simple: gen_expr is given an expression that
contains an unrecognized operator (OP_DOUBLE in this case). When that
happens, it tries to report an error with a string image of the operator
in the error message. Conversion of the opcode into a string is done
using op_string which, despite its name, probably is not what the author
was looking for. This function returns NULL for a lot of the opcodes,
thus triggering the crash.
There is a function that corresponds to what we are looking for:
expprint.c:op_name. It was static, though, so I made it non-static,
and used it from ax-gdb.c:gen_expr.
gdb/ChangeLog:
* expression.h (op_name): Add declaration.
* expprint.c (op_name): Remove declaration. Make non-static.
* ax-gdb.c (gen_expr): Use op_name instead of op_string.
