From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id D09B43858C5F for ; Fri, 3 Feb 2023 16:33:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D09B43858C5F Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1675442028; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=VHV8xgtAv+E7Os+t+oo89e/AV2GPTwMUQNHThgJOEwE=; b=HYNP9Zdd2E/SfHNGATNkAuJloRZwiZyqT3bTNtVMok5WIVUt/uQwqxYyVVTVWTrrN7yjh3 WN5HPRME14XvbsUd/JQezuxYKpvGYKhTgwtTRQU1vJ/uIMayDHz4wZASikcSpAbg9w54c4 BdCgNeqS6fsX3t/vbjkfQfmVMJyCuWg= Received: from mail-qk1-f200.google.com (mail-qk1-f200.google.com [209.85.222.200]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-629-DGdGxUyNMliqhTCgBxeHXg-1; Fri, 03 Feb 2023 11:33:47 -0500 X-MC-Unique: DGdGxUyNMliqhTCgBxeHXg-1 Received: by mail-qk1-f200.google.com with SMTP id a6-20020a05620a102600b00729952b4c73so3570382qkk.6 for ; Fri, 03 Feb 2023 08:33:47 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=VHV8xgtAv+E7Os+t+oo89e/AV2GPTwMUQNHThgJOEwE=; b=7Uk03unYSPXRVXHfFhJaf/N9bYfWQgJpnZoQgFD5F2/i5ixVdqTb4evXY03aklrD9U p3XYvNforNEjySW+VViaR/CvpPx/YPVY7SgTj0WVx82n8W8S9w3t/EiLuamvHaAzE2Jd Y0GsReRd+ulFiG8uHv7EgIlvGGqeB2GtBE8D859OQ2GPW7bbhNO0ELcgEpyNa1kRBCUv Erhje7Yi0vFB74q0BKmVO7ylXVD0RIo4XwU2e5COFG22YF9B2LugWOXloe/WSNXqBU8H M3aK6D5Iy5BiP8nA/YBPWOF/oeLtCRHWE8T1N3SO8e8l5O+wBAGpDBjt7wIAW5h6mBHZ bEAA== X-Gm-Message-State: AO0yUKW+OmVXaLp300qcMDLFE1IMD8k9yx22SQ1uWbZdqPV/xWlOdeBw wPj17bEp1PG4msJcR8I1JTvYVmfWGL2bfQVJ3pfhIsCbE+vZK2fb5v27FdJ9TGUtX0WrvDVWdTi yzDXf9VanSvMErFJDlxKW0w== X-Received: by 2002:a05:622a:4ca:b0:3b8:68f4:31f0 with SMTP id q10-20020a05622a04ca00b003b868f431f0mr20030347qtx.41.1675442026736; Fri, 03 Feb 2023 08:33:46 -0800 (PST) X-Google-Smtp-Source: AK7set/QiMQNCANSwW8tPEUZ8V6K4XqLSjJRKslQub1zfYE06RLx+2YWvx1imVDJLHJnjIceQIbRpA== X-Received: by 2002:a05:622a:4ca:b0:3b8:68f4:31f0 with SMTP id q10-20020a05622a04ca00b003b868f431f0mr20030310qtx.41.1675442026409; Fri, 03 Feb 2023 08:33:46 -0800 (PST) Received: from localhost (95.72.115.87.dyn.plus.net. [87.115.72.95]) by smtp.gmail.com with ESMTPSA id l11-20020a05620a28cb00b007259807a512sm2224767qkp.12.2023.02.03.08.33.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 03 Feb 2023 08:33:46 -0800 (PST) From: Andrew Burgess To: Simon Marchi , Luis Machado , Thiago Jung Bauermann via Gdb-patches Cc: Thiago Jung Bauermann Subject: Re: [PATCH v3 6/8] gdb/remote: Parse tdesc field in stop reply and threads list XML In-Reply-To: <7ad8e78a-7966-a714-d4cb-ebe1bfa606ee@simark.ca> References: <20230130044518.3322695-1-thiago.bauermann@linaro.org> <20230130044518.3322695-7-thiago.bauermann@linaro.org> <87edr9tq0c.fsf@redhat.com> <9f5deefd-52fc-9792-f9a5-dede9c415777@simark.ca> <7ad8e78a-7966-a714-d4cb-ebe1bfa606ee@simark.ca> Date: Fri, 03 Feb 2023 16:33:44 +0000 Message-ID: <87sffmr9nb.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-5.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Simon Marchi writes: > On 2/3/23 06:27, Luis Machado wrote: >> On 2/1/23 20:16, Simon Marchi via Gdb-patches wrote: >>>> IIUC, the tdescs would be deleted during the >>>> pop_all_targets_at_and_above, when the refcount of the remote_target >>>> gets to 0 and it gets deleted. And the threads would be removed in >>>> generic_mourn_inferior just after. >>>> >>>> An idea could be to call generic_mourn_inferior before >>>> remote_unpush_target (no idea if it works). Another one would be to >>>> get a temporary reference to the remote_target object in >>>> remote_unpush_target, just so that it outlives the threads. >>>> Or maybe we should say that it's a process target's responsibility to >>>> delete any thread it "owns" before getting deleted itself. >>> >>> Another question related to this popped while reading the following >>> patch. When creating a gdbarch from a tdesc, the gdbarch keeps a >>> pointer to that tdesc (accessible through gdbarch_target_desc). And >>> AFAIK, we never delete gdbarches. So I suppose the gdbarch will refer a >>> stale target desc. At first I thought it wouldn't be a problem in >>> practice, because while that gdbarch object still exists, nothing >>> references it (it is effectively leaked). But then I remember that we >>> cache gdbarches to avoid creating arches with duplicate features. So >>> later (let's say if you connect again to a remote), we might want to >>> create a gdbarch with the same features as before, and we'll dig up the >>> old gdbarch, that points to the now deleted tdesc. >> >> The target descriptions for aarch64 are all cached using a map in gdb/aarch64-tdep.c: >> >> /* All possible aarch64 target descriptors. */ >> static std::unordered_map tdesc_aarch64_map; >> >> I don't think we should try to delete those, and they should live throughout the life of gdb (unless things get large, then we might consider cleanups). > > When debugging natively with GDB, that's true. When debugging remotely, > on GDBserver-side, that's true too. But when debugging remotely, on > GDB-side, don't we create a new target_desc object for each read target > description? > > Ok, I just saw in xml-tdesc.c: > > /* A record of every XML description we have parsed. We never discard > old descriptions, because we never discard gdbarches. As long as we > have a gdbarch referencing this description, we want to have a copy > of it here, so that if we parse the same XML document again we can > return the same "struct target_desc *"; if they are not singletons, > then we will create unnecessary duplicate gdbarches. See > gdbarch_list_lookup_by_info. */ > > static std::unordered_map xml_cache; > > So, at least, a remote sending the same exact XML over and over will > lead to the same target_desc object being reused. And there won't be > lifetime issues, since the target_desc created from XML also live > forever. So I guess we're good. Simon, Thanks for chasing this down. I guess my concerns about object life time are addressed then. Thanks, Andrew