Re: [RFA 2/2] Remove some clanups from solib-svr4.c

[Simon Marchi <simon dot marchi at polymtl dot ca>]

"clanups" in the title.

On 2018-03-28 00:24, Tom Tromey wrote:
> This removes a few cleanups from solib-svr4.c in a straightforward
> way.
>
> gdb/ChangeLog
> 2018-03-26  Tom Tromey  <tom@tromey.com>
>
> 	* solib-svr4.c (lm_info_read): Use gdb::byte_vector.
> 	(svr4_keep_data_in_core): Use gdb::unique_xmalloc_ptr.
> ---
>  gdb/ChangeLog    |  5 +++++
>  gdb/solib-svr4.c | 47 ++++++++++-------------------------------------
>  2 files changed, 15 insertions(+), 37 deletions(-)
>
> diff --git a/gdb/solib-svr4.c b/gdb/solib-svr4.c
> index d8d047d394..c2170891e5 100644
> --- a/gdb/solib-svr4.c
> +++ b/gdb/solib-svr4.c
> @@ -172,14 +172,11 @@ static lm_info_svr4 *
>  lm_info_read (CORE_ADDR lm_addr)
>  {
>    struct link_map_offsets *lmo = svr4_fetch_link_map_offsets ();
> -  gdb_byte *lm;
>    lm_info_svr4 *lm_info;
> -  struct cleanup *back_to;
>
> -  lm = (gdb_byte *) xmalloc (lmo->link_map_size);
> -  back_to = make_cleanup (xfree, lm);
> +  gdb::byte_vector lm (lmo->link_map_size);
>
> -  if (target_read_memory (lm_addr, lm, lmo->link_map_size) != 0)
> +  if (target_read_memory (lm_addr, lm.data (), lmo->link_map_size) != 
> 0)
>      {
>        warning (_("Error reading shared library list entry at %s"),
>  	       paddress (target_gdbarch (), lm_addr)),
> @@ -203,8 +200,6 @@ lm_info_read (CORE_ADDR lm_addr)
>  					       ptr_type);
>      }
>
> -  do_cleanups (back_to);
> -
>    return lm_info;
>  }
>
> @@ -958,8 +953,6 @@ svr4_keep_data_in_core (CORE_ADDR vaddr, unsigned 
> long size)
>  {
>    struct svr4_info *info;
>    CORE_ADDR ldsomap;
> -  struct so_list *newobj;
> -  struct cleanup *old_chain;
>    CORE_ADDR name_lm;
>
>    info = get_svr4_info ();
> @@ -973,13 +966,8 @@ svr4_keep_data_in_core (CORE_ADDR vaddr, unsigned
> long size)
>    if (!ldsomap)
>      return 0;
>
> -  newobj = XCNEW (struct so_list);
> -  old_chain = make_cleanup (xfree, newobj);
> -  lm_info_svr4 *li = lm_info_read (ldsomap);
> -  newobj->lm_info = li;
> -  make_cleanup (xfree, newobj->lm_info);
> +  gdb::unique_xmalloc_ptr<lm_info_svr4> li (lm_info_read (ldsomap));

This is not an error because lm_info_svr4 is trivially destructible, but 
since we allocate it with "new", we might as well use a unique_ptr, it's 
more future-proof.  At least, with the xfree poisoning, adding something 
that does not destruct trivially to lm_info_svr4 would warn us not to 
use unique_xmalloc_ptr here.

How about making lm_info_read return an std::unique_ptr<lm_info_svr4>?

The patch LGTM with or without those changes.

Simon