Simon pointed out some spots were doing val.get()->mumble, where val
is a value_ref_ptr. These were introduced by the function-to-method
script, replacing older code that passed the result of .get() to a
function.
Now that value.h is using methods, we can instead rely on operator->.
This patch replaces all the newly-introduced instances of this.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
This removes deprecated_lval_hack and the VALUE_LVAL macro, replacing
all uses with a call to value::lval.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
This changes value_fetch_lazy to be a method of value. A few helper
functions are converted as well, to avoid problems in later patches
when the data members are all made private.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
This changes the value_lazy and set_value_lazy functions to be methods
of value. Much of this patch was written by script.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
This commit is the result of running the gdb/copyright.py script,
which automated the update of the copyright year range for all
source files managed by the GDB project to be updated to include
year 2023.
This changes GDB to use frame_info_ptr instead of frame_info *
The substitution was done with multiple sequential `sed` commands:
sed 's/^struct frame_info;/class frame_info_ptr;/'
sed 's/struct frame_info \*/frame_info_ptr /g' - which left some
issues in a few files, that were manually fixed.
sed 's/\<frame_info \*/frame_info_ptr /g'
sed 's/frame_info_ptr $/frame_info_ptr/g' - used to remove whitespace
problems.
The changed files were then manually checked and some 'sed' changes
undone, some constructors and some gets were added, according to what
made sense, and what Tromey originally did
Co-Authored-By: Bruno Larsen <blarsen@redhat.com>
Approved-by: Tom Tomey <tom@tromey.com>
When doing varobj_re_set, we currently try to recreate floating varobj.
This was introduced by 4e969b4f0128 "Re-evaluate floating varobj as part
of varobj_invalidate" to deal with use a after free issue. However
since bc20e562ec0 "Fix use after free in varobj" we now ensure that we
never have dangling pointers so this all recreation is not strictly
needed anymore for floating varobjs.
This commit proposes to remove this recreation process for floating
varobjs.
Tested on x86_64-linux.
[This patch is a followup to the discussion in
https://sourceware.org/pipermail/gdb-patches/2022-August/191188.html]
PR/29426 shows failures when running the gdb.mi/mi-var-invalidate-shlib
test when using a compiler which does not produce a PIE executable by
default.
In the testcase, a varobj is created to track a global variable, and
then the main binary is reloaded in GDB (using the file command).
During the load of the new binary, GDB tries to recreate the varobj to
track the global in the new binary (varobj_invalidate_iter). At this
point, the old process is still in flight. So when we try to access to
the value of the global, in a PIE executable we only have access to the
unrelocated address (the objfile's text_section_offset () is 0). As a
consequence down the line read_value_memory fails to read the unrelated
address, so cannot evaluate the value of the global. Note that the
expression used to access to the global’s value is valid, so the varobj
can be created. When using a non PIE executable, the address of the
global GDB knows about at this point does not need relocation, so
read_value_memory can access the (old binary’s) value.
So at this point, in the case of a non-PIE executable the value field is
set, while it is cleared in the case of PIE executable. Later when the
test issues a "-var-update global_var", the command sees no change in
the case of the non-PIE executable, while in the case of the PIE
executable install_new_value sees that value changes, leading to a
different output.
This patch makes sure that, as we do for breakpoints, we wait until
relocation has happened before we try to recreate varobjs. This way we
have a consistent behavior between PIE and non-PIE binaries.
Tested on x86_64-linux.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29426
Co-authored-by: Lancelot SIX <lancelot.six@amd.com>
The varobj_invalidate_iter function has logic to invalidate any local
varobj it can find. However since bc20e562ec0 "gdb/varobj: Fix use
after free in varobj" all varobj containing references to an objfile are
cleared when the objfile goes out of scope. This means that at this
point any local varobj seen by varobj_invalidate_iter either has
already been invalidated by varobj_invalidate_if_uses_objfile or only
contains valid references and there is no reason to invalidate it.
This patch proposes to remove this unnecessary invalidation and adds a
testcase which exercises a scenario where a local varobj can legitimately
survive a call to varobj_invalidate_iter.
At this point the varobj_invalidate and varobj_invalidate_iter seem
misnamed since they deal with re-creating invalid objects and do not do
invalidation, but this will be fixed in a following patch.
Tested on x86_64-linux.
Commit bc20e562ec0 "Fix use after free in varobj" introduced a
regression. This commit makes sure that the varobj object does not
keeps stale references to object being freed when we unload an objfile.
This includes the "valid_block" field which is reset to nullptr if the
pointed to block is tied to an objfile being freed.
However, at some point varobj_invalidate_iter might try to recreate
varobjs tracking either floating or globals. Varobj tracking globals
are identified as having the "valid_block" field set nullptr, but as
bc20e562ec0 might clear this field, we have lost the ability to
distinguish between varobj referring to globals and non globals.
Fix this by introducing a "global" flag which tracks if a given varobj
was initially created as tracking a global.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29426
The varobj_invalidate function is meant to be called when restarting a
process, and check at this point if some of the previously existing
varobj can be recreated in the context of the new process.
Two kind of varobj are subject to re-creation: global varobj (i.e.
varobj which reference a global variable), and floating varobj (i.e.
varobj which are always re-evaluated in the context of whatever is
the currently selected frame at the time of evaluation).
However, in the re-creation process, the varobj_invalidate_iter
recreates floating varobj as non-floating, due to an invalid parameter.
This patches fixes this and adds an assertion to check that if a varobj
is indeed recreated, it matches the original varobj "floating" property.
Another issue is that if at this recreation time the expression watched
by the floating varobj is not in scope, then the varobj is marked as
invalid. If later the user selects a frame where the expression becomes
valid, the varobj remains invalid and this is wrong. This patch also
make sure that floating varobj are not invalidated if they cannot be
evaluated.
The last important thing to note is that due to the previous patch, when
varobj_invalidate is executed (in the context of a new process), any
global var have already been invalidated (this has been done when the
objfile it referred to got invalidated). As a consequence,
varobj_invalidate tries to recreate vars which are already marked as
invalid. This does not entirely feels right, but I keep this behavior
for backward compatibility.
Tested on x86_64-linux
Varobj object contains references to types, variables (i.e. struct
variable) and expression. All of those can reference data on an
objfile's obstack. It is possible for this objfile to be deleted (and
the obstack to be feed), while the varobj remains valid. Later, if the
user uses the varobj, this will result in a use-after-free error. With
address sanitizer build, this leads to a plain error. For non address
sanitizer build we might see undefined behaviour, which manifest
themself as assertion failures when accessing data backed by feed
memory.
This can be observed if we create a varobj that refers to ta symbol in a
shared library, after either the objfile gets reloaded (using the `file`
command) or after the shared library is unloaded (with a call to dlclose
for example).
This patch fixes those issues by:
- Adding cleanup procedure to the free_objfile observable. When
activated this observer clears expressions referencing the objfile
being freed, and removes references to blocks belonging to this
objfile.
- Adding varobj support in the `preserve_values` (gdb.value.c). This
ensures that before the objfile is unloaded, any type owned by the
objfile referenced by the varobj is replaced by an equivalent type
not owned by the objfile. This process is done here instead of in the
free_objfile observer in order to reuse the type hash table already
used for similar purpose when replacing types of values kept in the
value history.
This patch also makes sure to keep a reference to the expression's
gdbarch and language_defn members when the varobj->root->exp is
initialized. Those structures outlive the objfile, so this is safe.
This is done because those references might be used initialize a python
context even after exp is invalidated. Another approach could have been
to initialize the python context with default gdbarch and language_defn
(i.e. nullptr) if expr is NULL, but since we might still try to display
the value which was obtained by evaluating exp when it was still valid,
keeping track of the context which was used at this time seems
reasonable.
Tested on x86_64-Linux.
Co-Authored-By: Pedro Alves <pedro@palves.net>
PR python/17291 asks for access to the current print options. While I
think this need is largely satisfied by the existence of
Value.format_string, it seemed to me that a bit more could be done.
First, while Value.format_string uses the user's settings, it does not
react to temporary settings such as "print/x". This patch changes
this.
Second, there is no good way to examine the current settings (in
particular the temporary ones in effect for just a single "print").
This patch adds this as well.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=17291
varobj used to store 'print_value' as a C string, where NULL was a
valid value, and so it had logic to handle this situation. However,
at some point this was changed to be a std::string, and so the code
can be simplified in this spot.
Now that filtered and unfiltered output can be treated identically, we
can unify the printf family of functions. This is done under the name
"gdb_printf". Most of this patch was written by script.
A common pattern for string_file is to want to move out the internal
string buffer, because it is the result of the computation that we want
to return. It is the reason why string_file::string returns a non-const
reference, as explained in the comment. I think it would make sense to
have a dedicated method for that instead and make string_file::string
return a const reference.
This allows removing the explicit std::move in the typical case. Note
that compile_program::compute was missing a move, meaning that the
resulting string was copied. With the new version, it's not possible to
forget to move.
Change-Id: Ieaefa35b73daa7930b2f3a26988b6e3b4121bb79
This commit brings all the changes made by running gdb/copyright.py
as per GDB's Start of New Year Procedure.
For the avoidance of doubt, all changes in this commits were
performed by the script.
Change gdb_assert_not_reached to accept a format string plus
corresponding arguments. This allows giving more precise messages.
Because the format string passed by the caller is prepended with a "%s:"
to add the function name, the callers can no longer pass a translated
string (`_(...)`). Make the gdb_assert_not_reached include the _(),
just like the gdb_assert_fail macro just above.
Change-Id: Id0cfda5a57979df6cdaacaba0d55dd91ae9efee7
PR varobj/28131 points out a crash in the varobj deletion code. It
took a while to reproduce this, but essentially what happens is that a
top-level varobj deletes its root object, then deletes the "dynamic"
object. However, deletion of the dynamic object may cause
~py_varobj_iter to run, which in turn uses gdbpy_enter_varobj:
gdbpy_enter_varobj::gdbpy_enter_varobj (const struct varobj *var)
: gdbpy_enter (var->root->exp->gdbarch, var->root->exp->language_defn)
{
}
However, because var->root has already been destroyed, this is
invalid.
I've added a new test case. This doesn't reliably crash, but the
problem can easily be seen under valgrind (and, I presume, with ASAN,
though I did not try this).
Tested on x86-64 Fedora 32. I also propose putting this on the GDB 11
branch, with a suitable ChangeLog entry of course.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28131
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 adds a new helper method, expression::first_opcode, that extracts
the outermost opcode of an expression. This simplifies some patches
in the expression rewrite series.
Note that this patch requires the earlier patch to avoid manual
dissection of OP_TYPE operations.
2020-12-15 Tom Tromey <tom@tromey.com>
* varobj.c (varobj_create): Use first_opcode.
* value.c (init_if_undefined_command): Use first_opcode.
* typeprint.c (whatis_exp): Use first_opcode.
* tracepoint.c (validate_actionline): Use first_opcode.
(encode_actions_1): Use first_opcode.
* stack.c (return_command): Use first_opcode.
* expression.h (struct expression) <first_opcode>: New method.
* eval.c (parse_and_eval_type): Use first_opcode.
* dtrace-probe.c (dtrace_process_dof_probe): Use first_opcode.
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.
Remove TYPE_CODE, changing all the call sites to use type::code
directly. This is quite a big diff, but this was mostly done using sed
and coccinelle. A few call sites were done by hand.
gdb/ChangeLog:
* gdbtypes.h (TYPE_CODE): Remove. Change all call sites to use
type::code instead.
With the removal of the old VEC mechanism from the code base, update
comments that still make reference to VECs. There should be no user
visible changes after this commit.
gdb/ChangeLog:
* linespec.c (decode_digits_ordinary): Update comment.
* make-target-delegates: No longer need to handle VEC case.
* memrange.c (normalize_mem_ranges): Update comment.
* namespace.c (add_using_directive): Update comment.
* objc-lang.c (uniquify_strings): Update comment.
* ppc-linux-nat.c (struct thread_points): Update comment.
* probe.h (find_probes_in_objfile): Update comment.
* target.h (enum flash_preserve_mode): Update comment.
* varobj.c (varobj_restrict_range): Update comment.
* varobj.h (varobj_list_children): Update comment.
Change-Id: Iefd2e903705c3e79cd13b43395c7a1c167f9a088
