[PATCH 2/4 v2] gdb/progspace: Add reverse safe iterator and template for unwrapping iterator
Thiago Jung Bauermann
thiago.bauermann@linaro.org
Tue Dec 26 17:09:35 GMT 2023
Aaron Merey <amerey@redhat.com> writes:
> v1: https://sourceware.org/pipermail/gdb-patches/2023-June/199984.html
>
> v2 removes unwrapping_reverse_objfile_iterator and adds
> basic_safe_reverse_range and basic_safe_reverse_iterator.
>
> Commit message:
>
> This patch changes progspace objfile_list insertion so that separate
> debug objfiles are placed into the list after the parent objfile,
> instead of before. Additionally qf_require_partial_symbols now returns
> a safe_range.
>
> These changes are intended to prepare gdb for on-demand debuginfo
> downloading and the downloading of .gdb_index sections.
>
> With on-demand downloading enabled, gdb might need to delete a
> .gdb_index quick_symbol_functions from a parent objfile while looping
> the objfile's list of quick_symbol_functions becasue the separate
*because
> debug objfile has just been downloaded. The use of a safe_range
> prevents this removal from causing iterator invalidation.
<snip>
> diff --git a/gdb/progspace.h b/gdb/progspace.h
> index a22e427400e..17bb1710ccf 100644
> --- a/gdb/progspace.h
> +++ b/gdb/progspace.h
> @@ -214,28 +214,32 @@ struct program_space
> unwrapping_objfile_iterator (objfiles_list.end ()));
> }
>
> - using objfiles_safe_range = basic_safe_range<objfiles_range>;
> + using objfiles_safe_range = iterator_range<objfile_list::iterator>;
Does objfile_safe_range still need the safe qualifier? Or should it
be called objfiles_range now?
> + using objfiles_safe_reverse_range
> + = basic_safe_reverse_range<objfiles_safe_range>;
<snip>
> diff --git a/gdb/testsuite/gdb.python/py-objfile.exp b/gdb/testsuite/gdb.python/py-objfile.exp
> index 61b9942de79..0bf49976b73 100644
> --- a/gdb/testsuite/gdb.python/py-objfile.exp
> +++ b/gdb/testsuite/gdb.python/py-objfile.exp
> @@ -135,7 +135,7 @@ gdb_test "p main" "= {<text variable, no debug info>} $hex <main>" \
> gdb_py_test_silent_cmd "python objfile.add_separate_debug_file(\"${binfile}\")" \
> "Add separate debug file file" 1
>
> -gdb_py_test_silent_cmd "python sep_objfile = gdb.objfiles()\[0\]" \
> +gdb_py_test_silent_cmd "python sep_objfile = gdb.objfiles()\[1\]" \
> "Get separate debug info objfile" 1
Does the fact that this testcase needed change mean that there was an
API break? In my opinion it doesn't and this patch is ok. I think it
would be too much to guarantee a specific ordering of the returned
objfiles.
But I'm mentioning it anyway because perhaps someone has a different
view?
--
Thiago
More information about the Gdb-patches
mailing list