From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 6jdcL/OiBmcWjQcAWB0awg (envelope-from ) for ; Wed, 09 Oct 2024 11:36:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1728488179; bh=gTjntxXq4dO5+XtyMqT2hygq15B5XO9dv+TCIIM6Jkw=; h=Date:Subject:To:References:From:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=mjMQA46MF5qTe6tWIknuSENj1dmeEbNW3eF3FH2PUmhCSl7+7fEL+Rn16WS0MzegG soFVNPtcRN+hJN4PP0Hc8ZnLsNXuM7m3tjD4WGu3sBuTXchk/th+SpHb2O4LuEOeo2 tiIOdRe2OIjPjngJJwl0QXItp1w5GJ6ueAM1rW5g= Received: by simark.ca (Postfix, from userid 112) id A49AF1E356; Wed, 9 Oct 2024 11:36:19 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-6.8 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_BLOCKED,RCVD_IN_VALIDITY_CERTIFIED,RCVD_IN_VALIDITY_RPBL, RCVD_IN_VALIDITY_SAFE,URIBL_BLOCKED,URIBL_DBL_BLOCKED_OPENDNS autolearn=unavailable autolearn_force=no version=4.0.0 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=uLLXxCXD; dkim=pass (1024-bit key) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=Fz6nKxDk; dkim-atps=neutral Received: from server2.sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id C388F1E05C for ; Wed, 9 Oct 2024 11:36:18 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 5150F385020B for ; Wed, 9 Oct 2024 15:36:18 +0000 (GMT) Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id BB48B38650F3 for ; Wed, 9 Oct 2024 15:35:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org BB48B38650F3 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark.ca ARC-Filter: OpenARC Filter v1.0.0 sourceware.org BB48B38650F3 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=158.69.221.121 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1728488160; cv=none; b=af/y/S7sC7/s64XTiUD5pyVFSyL9PYib2D5AW3D+QQF+dQ5tKz6EklDiiRmcMKPrF26M+oAG514U582nGIBHQJh6gYmb26d6u0rJ4MuM1g3J5RhLb4TgWJ8a1Ny7zJesN+ejCNXU5RuoUhC4YyZoG7ke9hOHBvXl09P3bkjbKts= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1728488160; c=relaxed/simple; bh=gTjntxXq4dO5+XtyMqT2hygq15B5XO9dv+TCIIM6Jkw=; h=DKIM-Signature:DKIM-Signature:Message-ID:Date:MIME-Version: Subject:To:From; b=x3X1mTQ/9hE07nFz+c5GoVSj5HTdVQ4udcMKamWcRQkRrswBdYuHTKvs6v7GKKWcKTN2CoALAJw+MR8WIcwTMjPrWjsYjCo2Uh7/tO79ua+60Q7X7zNKSsc+Kp3/0o3lzeEbunkLJ7sgcKODwrmJ4iCIU2AP60maNMm6OtCVnpc= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1728488158; bh=gTjntxXq4dO5+XtyMqT2hygq15B5XO9dv+TCIIM6Jkw=; h=Date:Subject:To:References:From:In-Reply-To:From; b=uLLXxCXDI+yW6hOmDVllDFE3KH2eL30aw6NhDyK19EBu9GNdqd3PGPEM/XliUIs1W ieSGHrcxkSWt+4pPXz5qv8UEewt263lDuOW8w+6KjuoHmIWwEG7DLhAqkuh0rbx40p M4tuRNAwYjs/Oou9UzHTlaio7LVJXmKKw8hWvuF8= Received: by simark.ca (Postfix, from userid 112) id 37B561E357; Wed, 9 Oct 2024 11:35:58 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1728488156; bh=gTjntxXq4dO5+XtyMqT2hygq15B5XO9dv+TCIIM6Jkw=; h=Date:Subject:To:References:From:In-Reply-To:From; b=Fz6nKxDkD4ltEBIuwXtv3OfFet/oe82bBKn7iyIS8DqG1yWCeJZ/oh4zNwNWmqMlg zcjGJPonlWqUqv8ltdD8rVCy7IR6PW5soMjLcZyJpuQ728eXFzv085j+1Au9tOoibo bQKmj6etcxLAzQsjE5kYLs7mkhEsAgGGe+V7RB9M= Received: from [10.0.0.11] (modemcable238.237-201-24.mc.videotron.ca [24.201.237.238]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 1036A1E05C; Wed, 9 Oct 2024 11:35:56 -0400 (EDT) Message-ID: <527e0c5d-5ac3-488a-a1ce-e8a1177f6a7e@simark.ca> Date: Wed, 9 Oct 2024 11:35:55 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/3] gdbserver: make arch and osabi names gdb::unique_xmalloc_ptr To: Andrew Burgess , gdb-patches@sourceware.org References: <87msjdbklm.fsf@redhat.com> <952e0e55-b99c-4c24-ae1c-7f3c502bb826@simark.ca> <87ed4pbhch.fsf@redhat.com> Content-Language: en-US From: Simon Marchi In-Reply-To: <87ed4pbhch.fsf@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org On 2024-10-09 08:17, Andrew Burgess wrote: > Simon Marchi writes: > >> On 2024-10-09 07:07, Andrew Burgess wrote: >>> Simon Marchi writes: >>> >>>> On 2024-10-06 14:37, Andrew Burgess wrote: >>>>> Convert target_desc::arch and target_desc::osabi from 'const char*' to >>>>> gdb::unique_xmalloc_ptr. This also allows us to remove the user >>>>> defined ~target_desc destructor. >>>>> >>>>> I doubt it ever actually occurred, but in theory at least, there was a >>>>> memory leak in set_tdesc_architecture and set_tdesc_osabi where the >>>>> member variables were assigned without freeing any previous >>>>> value... but I suspect that usually these fields are only set once. >>>>> >>>>> There should be no user visible changes after this commit. >>>> >>>> Could they be std::string instead? >>> >>> I considered this, but that would, I think, require wider reaching >>> changes as the API to add the osabi to the returned tdesc passes the >>> information via 'const char *'. This approach added the memory safety >>> without requiring any further changes. >>> >>> If you'd prefer std::string be used then let me know and I'll update >>> things. >> >> Up to you, I don't mind, it can be done later. > > I'll leave it then if that's OK. > > My reason is that, if the osbi member variable changes to std::string > then it makes sense that tdesc_osabi_name return 'const std::string &'. > Which means that tdesc_osabi_name in GDB will also need to return 'const > std::string &', but on the GDB side we store 'enum gdb_osabi' rather > than the actual string ... so now that code needs updating too. > > I only wanted to fix this so that I could call set_tdesc_osbi without > leaking memory, and gdb::unique_xmalloc_ptr, which we use in loads > of places, achieves that, and leaves the API untouched. > > But I'm not against changing to std::string if someone's keen :) Yeah, it makes sense to take smaller, simpler steps. I might do it once your series is merged, to scratch my itch :). Simon