aboutsummaryrefslogtreecommitdiff
path: root/gdb/varobj.c
AgeCommit message (Collapse)AuthorFilesLines
2024-04-25gdb: remove gdbcmd.hSimon Marchi1-1/+1
Most files including gdbcmd.h currently rely on it to access things actually declared in cli/cli-cmds.h (setlist, showlist, etc). To make things easy, replace all includes of gdbcmd.h with includes of cli/cli-cmds.h. This might lead to some unused includes of cli/cli-cmds.h, but it's harmless, and much faster than going through the 170 or so files by hand. Change-Id: I11f884d4d616c12c05f395c98bbc2892950fb00f Approved-By: Tom Tromey <tom@tromey.com>
2024-03-26gdb, gdbserver, gdbsupport: remove includes of early headersSimon Marchi1-1/+0
Now that defs.h, server.h and common-defs.h are included via the `-include` option, it is no longer necessary for source files to include them. Remove all the inclusions of these files I could find. Update the generation scripts where relevant. Change-Id: Ia026cff269c1b7ae7386dd3619bc9bb6a5332837 Approved-By: Pedro Alves <pedro@palves.net>
2024-01-12Update copyright year range in header of all files managed by GDBAndrew Burgess1-1/+1
This commit is the result of the following actions: - Running gdb/copyright.py to update all of the copyright headers to include 2024, - Manually updating a few files the copyright.py script told me to update, these files had copyright headers embedded within the file, - Regenerating gdbsupport/Makefile.in to refresh it's copyright date, - Using grep to find other files that still mentioned 2023. If these files were updated last year from 2022 to 2023 then I've updated them this year to 2024. I'm sure I've probably missed some dates. Feel free to fix them up as you spot them.
2023-11-21gdb: Use C++17's std::make_unique instead of gdb::make_uniqueLancelot Six1-1/+1
gdb::make_unique is a wrapper around std::make_unique when compiled with C++17. Now that C++17 is required, use std::make_unique directly in the codebase, and remove gdb::make_unique. Change-Id: I80b615e46e4b7c097f09d78e579a9bdce00254ab Approved-By: Tom Tromey <tom@tromey.com> Approved-By: Pedro Alves <pedro@palves.net
2023-09-07Fix bug in -var-evaluate-expressionTom Tromey1-0/+9
This bug points out that if one uses -var-set-visualizer with "None" -- to disable a pretty-printer for a varobj -- then -var-evaluate-expression will still use pretty-printing. This is a combination of bugs. First, setting the visualizer does not update the display text; and second, computing the display text should use "raw" when Python is available but no visualizer is desired. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=11738 Reviewed-by: Keith Seitz <keiths@redhat.com>
2023-09-07Remove variable_default_displayTom Tromey1-11/+1
variable_default_display has a single caller now, so remove it. Reviewed-by: Keith Seitz <keiths@redhat.com>
2023-09-07Remove dead code from varobj_set_display_formatTom Tromey1-14/+1
varobj_set_display_format takes an enum and exhaustively switches on the values -- but also has a default. This default case is dead code. Reviewed-by: Keith Seitz <keiths@redhat.com>
2023-09-07Allow pretty-printer 'children' method to return stringsTom Tromey1-0/+3
A user noticed that, while a pretty-printer can return Python strings from its "children" method, this does not really work for MI. I tracked this down to my_value_of_variable calling into c_value_of_variable, which specially handles arrays and structures -- not using the actual contents of the string. Now, this part of MI seems bad to me, but rather than change that, this applies the fix to only dynamic varobjs, which is the only scenario where a string like this can really be returned. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=18282 Reviewed-by: Keith Seitz <keiths@redhat.com>
2023-08-23gdb: add gdb::make_unique functionAndrew Burgess1-1/+1
While GDB is still C++11, lets add a gdb::make_unique template function that can be used to create std::unique_ptr objects, just like the C++14 std::make_unique. If GDB is being compiled with a C++14 compiler then the new gdb::make_unique function will delegate to the std::make_unique. I checked with gcc, and at -O1 and above gdb::make_unique will be optimised away completely in this case. If C++14 (or later) becomes our minimum, then it will be easy enough to go through the code and replace gdb::make_unique with std::make_unique later on. I've make use of this function in all the places I think this can easily be used, though I'm sure I've probably missed some. Should be no user visible changes after this commit. Approved-By: Tom Tromey <tom@tromey.com>
2023-06-05[gdb] Fix more typosTom de Vries1-1/+1
Fix some more typos: - distinquish -> distinguish - actualy -> actually - singe -> single - frash -> frame - chid -> child - dissassembler -> disassembler - uninitalized -> uninitialized - precontidion -> precondition - regsiters -> registers - marge -> merge - sate -> state - garanteed -> guaranteed - explictly -> explicitly - prefices (nonstandard plural) -> prefixes - bondary -> boundary - formated -> formatted - ithe -> the - arrav -> array - coresponding -> corresponding - owend -> owned - fials -> fails - diasm -> disasm - ture -> true - tpye -> type There's one code change, the name of macro SIG_CODE_BONDARY_FAULT changed to SIG_CODE_BOUNDARY_FAULT. Tested on x86_64-linux.
2023-06-03[gdb] Fix typosTom de Vries1-1/+1
Fix a few typos: - implemention -> implementation - convertion(s) -> conversion(s) - backlashes -> backslashes - signoring -> ignoring - (un)ambigious -> (un)ambiguous - occured -> occurred - hidding -> hiding - temporarilly -> temporarily - immediatelly -> immediately - sillyness -> silliness - similiar -> similar - porkuser -> pokeuser - thats -> that - alway -> always - supercede -> supersede - accomodate -> accommodate - aquire -> acquire - priveleged -> privileged - priviliged -> privileged - priviledges -> privileges - privilige -> privilege - recieve -> receive - (p)refered -> (p)referred - succesfully -> successfully - successfuly -> successfully - responsability -> responsibility - wether -> whether - wich -> which - disasbleable -> disableable - descriminant -> discriminant - construcstor -> constructor - underlaying -> underlying - underyling -> underlying - structureal -> structural - appearences -> appearances - terciarily -> tertiarily - resgisters -> registers - reacheable -> reachable - likelyhood -> likelihood - intepreter -> interpreter - disassemly -> disassembly - covnersion -> conversion - conviently -> conveniently - atttribute -> attribute - struction -> struct - resonable -> reasonable - popupated -> populated - namespaxe -> namespace - intialize -> initialize - identifer(s) -> identifier(s) - expection -> exception - exectuted -> executed - dungerous -> dangerous - dissapear -> disappear - completly -> completely - (inter)changable -> (inter)changeable - beakpoint -> breakpoint - automativ -> automatic - alocating -> allocating - agressive -> aggressive - writting -> writing - reguires -> requires - registed -> registered - recuding -> reducing - opeartor -> operator - ommitted -> omitted - modifing -> modifying - intances -> instances - imbedded -> embedded - gdbaarch -> gdbarch - exection -> execution - direcive -> directive - demanged -> demangled - decidely -> decidedly - argments -> arguments - agrument -> argument - amespace -> namespace - targtet -> target - supress(ed) -> suppress(ed) - startum -> stratum - squence -> sequence - prompty -> prompt - overlow -> overflow - memember -> member - languge -> language - geneate -> generate - funcion -> function - exising -> existing - dinking -> syncing - destroh -> destroy - clenaed -> cleaned - changep -> changedp (name of variable) - arround -> around - aproach -> approach - whould -> would - symobl -> symbol - recuse -> recurse - outter -> outer - freeds -> frees - contex -> context Tested on x86_64-linux. Reviewed-By: Tom Tromey <tom@tromey.com>
2023-05-01Remove evaluate_typeTom Tromey1-1/+1
Like evaluate_expression, evaluate_type is also just a simple wrapper. Removing it makes the code a little nicer.
2023-05-01Remove evaluate_expressionTom Tromey1-6/+6
evaluate_expression is just a little wrapper for a method on expression. Removing it also removes a lot of ugly (IMO) calls to get().
2023-04-25Use scoped_restore in varobj.cTom Tromey1-3/+2
One spot in varobj.c should use scoped_restore to save and restore input_radix. Note that the current code may fail to restore it on error, so this patch fixes a latent bug. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-03-28Put pretty-printers to_string output in varobj resultTom Tromey1-21/+8
PR mi/11335 points out that an MI varobj will not display the result of a pretty-printer's "to_string" method. Instead, it always shows "{...}". This does not seem very useful, and there have been multiple complaints about it over the years. This patch changes varobj to emit this string when possible, and updates the test suite. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=11335
2023-02-19Convert block_objfile to methodTom Tromey1-1/+1
This converts block_objfile to be a method. This was mostly written by script.
2023-02-13Rely on value_ref_ptr::operator->Tom Tromey1-7/+7
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>
2023-02-13Remove deprecated_lval_hackTom Tromey1-1/+1
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>
2023-02-13Turn value_fetch_lazy into a methodTom Tromey1-1/+1
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>
2023-02-13Turn value_lazy and set_value_lazy functions into methodsTom Tromey1-8/+8
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>
2023-02-13Turn value_type into methodTom Tromey1-6/+6
This changes value_type to be a method of value. Much of this patch was written by script. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-01-04Convert exp_uses_objfile to a method of expressionTom Tromey1-2/+1
This changes the exp_uses_objfile function to be a method of 'expression'. Reviewed-By: Lancelot Six <lancelot.six@amd.com>
2023-01-01Update copyright year range in header of all files managed by GDBJoel Brobecker1-1/+1
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.
2022-12-19Use bool constants for value_print_optionsTom Tromey1-1/+1
This changes the uses of value_print_options to use 'true' and 'false' rather than integers.
2022-10-10Change GDB to use frame_info_ptrTom Tromey1-4/+4
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>
2022-08-11gdb/varobj: Only re-evaluate invalid globals during re_setLancelot SIX1-13/+5
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.
2022-08-11gdb/varobj: Reset varobj after relocations have been computedTom de Vries1-14/+8
[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>
2022-08-11gdb/varobj: Do not invalidate locals in varobj_invalidate_iterLancelot SIX1-2/+0
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.
2022-08-03gdb: Fix regression in varobj recreationLancelot SIX1-2/+7
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
2022-07-26gdb/varobj: Fix varobj_invalidate_iterLancelot SIX1-7/+13
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
2022-07-26gdb/varobj: Fix use after free in varobjLancelot SIX1-1/+65
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>
2022-07-15Expose current 'print' settings to PythonTom Tromey1-4/+9
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
2022-06-06Simplify varobj "change" logicTom Tromey1-5/+2
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.
2022-04-27gdb: remove BLOCK_{START,END} macrosSimon Marchi1-2/+2
Replace with equivalent methods. Change-Id: I10a6c8a2a86462d9d4a6a6409a3f07a6bea66310
2022-03-29Unify gdb printf functionsTom Tromey1-4/+4
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.
2022-02-14Remove LA_PRINT_STRINGTom Tromey1-2/+2
This removes the LA_PRINT_STRING macro, in favor of using ordinary method calls.
2022-01-26gdb: add string_file::release methodSimon Marchi1-1/+1
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
2022-01-18Move gdb_regex to gdbsupportTom Tromey1-1/+1
This moves the gdb_regex convenience class to gdbsupport.
2022-01-01Automatic Copyright Year update after running gdb/copyright.pyJoel Brobecker1-1/+1
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.
2021-11-18gdbsupport: make gdb_assert_not_reached accept a format stringSimon Marchi1-2/+1
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
2021-08-02Avoid crash in varobj deletionTom Tromey1-2/+4
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
2021-01-28gdb: rename get_type_arch to type::archSimon Marchi1-1/+1
... and update all users. gdb/ChangeLog: * gdbtypes.h (get_type_arch): Rename to... (struct type) <arch>: ... this, update all users. Change-Id: I0e3ef938a0afe798ac0da74a9976bbd1d082fc6f
2021-01-01Update copyright year range in all GDB filesJoel Brobecker1-1/+1
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.
2020-12-15Introduce expression::first_opcodeTom Tromey1-3/+4
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.
2020-12-11install_variable cannot failTom Tromey1-9/+3
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.
2020-12-11Use gdbpy_ref in instantiate_pretty_printerTom Tromey1-8/+3
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.
2020-12-11Remove varobj_clear_saved_itemTom Tromey1-13/+1
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.
2020-12-11Change varobj_item::value to a value_ref_ptrTom Tromey1-16/+8
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.
2020-12-11Change varobj_dynamic::child_iter to unique_ptrTom Tromey1-8/+4
This changes varobj_dynamic::child_iter to be a unique_ptr, removing some manual management. gdb/ChangeLog 2020-12-11 Tom Tromey <tom@tromey.com> * varobj.c (struct varobj_dynamic) <child_iter>: Now unique_ptr. (varobj_get_iterator): Return unique_ptr. (update_dynamic_varobj_children, install_visualizer) (varobj::~varobj): Update. * python/python-internal.h (py_varobj_get_iterator): Return unique_ptr. * python/py-varobj.c (py_varobj_get_iterator): Return unique_ptr.
2020-12-11Change varobj_dynamic::saved_item to unique_ptrTom Tromey1-8/+4
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.