From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 95133 invoked by alias); 30 Mar 2018 05:47:13 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 95124 invoked by uid 89); 30 Mar 2018 05:47:13 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-25.0 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy= X-HELO: smtp.polymtl.ca Received: from smtp.polymtl.ca (HELO smtp.polymtl.ca) (132.207.4.11) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 30 Mar 2018 05:47:12 +0000 Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id w2U5l512016986 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 30 Mar 2018 01:47:10 -0400 Received: by simark.ca (Postfix, from userid 112) id 36DB51E77E; Fri, 30 Mar 2018 01:47:05 -0400 (EDT) Received: from simark.ca (localhost [127.0.0.1]) by simark.ca (Postfix) with ESMTP id 14BFD1E030; Fri, 30 Mar 2018 01:47:04 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 30 Mar 2018 05:47:00 -0000 From: Simon Marchi To: Tom Tromey Cc: gdb-patches@sourceware.org Subject: Re: [RFA 2/2] Remove some clanups from solib-svr4.c In-Reply-To: <20180328042424.15276-3-tom@tromey.com> References: <20180328042424.15276-1-tom@tromey.com> <20180328042424.15276-3-tom@tromey.com> Message-ID: <1638a6c7e170673422428af140ca6903@polymtl.ca> X-Sender: simon.marchi@polymtl.ca User-Agent: Roundcube Webmail/1.3.4 X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Fri, 30 Mar 2018 05:47:05 +0000 X-IsSubscribed: yes X-SW-Source: 2018-03/txt/msg00605.txt.bz2 "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 > > * 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 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? The patch LGTM with or without those changes. Simon