Re: [PATCH 2/4 v2] gdb/progspace: Add reverse safe iterator and template for unwrapping iterator

[Thiago Jung Bauermann <thiago.bauermann@linaro.org>]

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