From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id 117B3385842C for ; Thu, 21 Dec 2023 20:48:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 117B3385842C 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 117B3385842C 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=1703191705; cv=none; b=DLSXgVB2D5uH+lh/UN9i7QDYW4ic1KiHEHK7lMfhSILbvGfAhRiUfJ3Jk7yUrgdeJbE3DuPhD5VSN7FrHfRNOUDdJYg27GFUgMqEeAYXpCEmO73RGdPlv7hzpAbsrR3YYSAMkttC0QQ2+UxVbvN65pJQ3lAAl1DtoaKg7W+Ylxw= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1703191705; c=relaxed/simple; bh=QwmUiysq+ux9pBoI+BNoHA3Aslpay/Wyqx0PfU1rm7Q=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=HOjtfcHloxcRT5l0/dDHZp8qhfB91CZ3g1PZ45immsKBr6XZr+lgutwyff6RYsJhiamIOpL8gZ2V3YkJ71Y3DPGObKYNdujKDT2ZogVa20IaVFMLaulCGPyrP7D8Kj+VSxze7TRC/BYmC3181QgSb2iPKFfxSPm7MEiFjtx64hg= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1703191703; bh=QwmUiysq+ux9pBoI+BNoHA3Aslpay/Wyqx0PfU1rm7Q=; h=Date:Subject:To:References:From:In-Reply-To:From; b=GQMUi42ri2DPV9VJoUkOnq3JKbnT/KLIEgVU66hyPyCwZkmDT9ntKkfS0jRW43N+U idM1nk3+5dSwTvfpsxgtejhm7wFZmn8KtMX6IDY2tvLOY4QTaS5mshrbhEmvpZA6l0 xIooTys/bxMiIyiY2OMZYcCAA4MwvxTXy/GkHuYE= Received: from [172.16.0.192] (192-222-143-198.qc.cable.ebox.net [192.222.143.198]) (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 7BCE91E0AC; Thu, 21 Dec 2023 15:48:23 -0500 (EST) Message-ID: <5bd0ee41-915f-4bbc-95e7-62baaccbc430@simark.ca> Date: Thu, 21 Dec 2023 15:48:22 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 06/26] gdbserver: turn part of get_thread_regcache into regcache::fetch Content-Language: fr To: Tankut Baris Aktemur , gdb-patches@sourceware.org References: From: Simon Marchi In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-10.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE 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: On 2/28/23 06:28, Tankut Baris Aktemur via Gdb-patches wrote: > Extract out a piece of code in get_thread_regcache that fetches the > registers from the target, and turn it into a method of 'regcache'. > --- > gdbserver/regcache.cc | 23 +++++++++++++++-------- > gdbserver/regcache.h | 3 +++ > 2 files changed, 18 insertions(+), 8 deletions(-) > > diff --git a/gdbserver/regcache.cc b/gdbserver/regcache.cc > index 2a8dc17ed6a..89ecdfec6f3 100644 > --- a/gdbserver/regcache.cc > +++ b/gdbserver/regcache.cc > @@ -48,19 +48,26 @@ get_thread_regcache (struct thread_info *thread, bool fetch) > regcache->thread = thread; > } > > - if (fetch && regcache->registers_valid == 0) > + if (fetch) > + regcache->fetch (); > + > + return regcache; > +} > + > +void > +regcache::fetch () > +{ > + if (registers_valid == 0) > { > scoped_restore_current_thread restore_thread; > + gdb_assert (this->thread != nullptr); > + switch_to_thread (this->thread); > > - switch_to_thread (thread); > /* Invalidate all registers, to prevent stale left-overs. */ > - memset (regcache->register_status, REG_UNAVAILABLE, > - regcache->tdesc->reg_defs.size ()); > - fetch_inferior_registers (regcache, -1); > - regcache->registers_valid = 1; > + memset (register_status, REG_UNAVAILABLE, tdesc->reg_defs.size ()); > + fetch_inferior_registers (this, -1); > + registers_valid = 1; > } > - > - return regcache; Ok, so this is one of the uses of the regcache::thread field. Given that, as of today (before your series), a thread knows its regcache, but a regcache doesn't know its thread (if any), it could be the other way around. You could have a thread_info::fetch_registers method that does the above. This way, the regcache stays a relatively dumb box of register data, oblivious to where the bytes come from. Again, I don't have yet the full context of the rest of the series. Another improvement I'd like to see: would it be relatively easy to change fetch_inferior_registers to pass the thread down, and avoid the switch_to_thread? I guess you wouldn't need to pass the regcache down anymore, because the target function would know it needs to put the register data in thread->regcache. Doing the same in GDB is an enormous amount of work, but I peeked at the GDBserver code, and it seems do-able. Simon