From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 33749 invoked by alias); 9 Feb 2020 12:16:24 -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 33736 invoked by uid 89); 9 Feb 2020 12:16:23 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-5.3 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 spammy=HX-Languages-Length:642 X-HELO: simark.ca Received: from simark.ca (HELO simark.ca) (158.69.221.121) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 09 Feb 2020 12:16:22 +0000 Received: from [10.0.0.11] (unknown [192.222.164.54]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 01CE01ED42; Sun, 9 Feb 2020 07:16:19 -0500 (EST) Subject: Re: [PATCH][gdb] Mention CU offset for if verbose To: Tom de Vries , Christian Biesinger Cc: gdb-patches References: <20200207113429.GA6532@delia> <7a8ea599-5254-46be-95b3-fa2af134656d@simark.ca> <99e7c8e5-8662-5b66-9d05-6ec3581b08bd@suse.de> From: Simon Marchi Message-ID: Date: Sun, 09 Feb 2020 12:16:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.2 MIME-Version: 1.0 In-Reply-To: <99e7c8e5-8662-5b66-9d05-6ec3581b08bd@suse.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2020-02/txt/msg00255.txt.bz2 On 2020-02-09 6:48 a.m., Tom de Vries wrote: > I've done that now by using gdb::unique_xmalloc_ptr. [ FWIW, > there's some code in create_type_unit_group that does something similar, > but there we use std::string and string_printf. ] You could use std::string and string_printf here as well, but what you did is fine. The patch LGTM. Thanks! > > Also, I realized that the code was too deep in the call stack, and I've > brought it one level up, to process_psymtab_comp_unit_reader, to make > sure it doesn't trigger for f.i. create_type_unit_group. > > Thanks, > - Tom