From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vk1-xa33.google.com (mail-vk1-xa33.google.com [IPv6:2607:f8b0:4864:20::a33]) by sourceware.org (Postfix) with ESMTPS id EB2F73858D1E for ; Fri, 30 Sep 2022 02:55:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org EB2F73858D1E Received: by mail-vk1-xa33.google.com with SMTP id bi53so1621541vkb.12 for ; Thu, 29 Sep 2022 19:55:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:in-reply-to :subject:cc:to:from:user-agent:references:x-gm-message-state:from:to :cc:subject:date; bh=7JaDKxwsgRKTF8+HwbHvo9PZmBxLwKkBfKVmeG6nbkc=; b=B1f+Bd3lXIX6k6XXMAqg4ULcrQdRmnxCZKhasqBQILGqCa4g77b/ahgWr1T/HLwa72 lINNF5VvJvdT6Eh59+sZ1TOBsHl9FPEUCSVpNpTLkm86aCAHaNRwGfBAD35U9+rL2Dwd vnNeLQ0dfPmqbKM6CYa57WbICeVZW/u9CYPva6Dykv/P1phzwQb0VL/qb42d8TE4313O K7VPKaLWONLXqOfMafYdfILpbKUY48ADcJ+/E1Y3MH9d9NEWIF+zKFRgGOMUl2gENcCb gaafngS6H10Vg2616rR7jLjxjVwK9z3uOJliLqkRCeNd0+SJxFG7TuCFQ5ux0+vQYU7G fhig== X-Gm-Message-State: ACrzQf3f2hP9duNMTbFtKGCbhI7S5cogEUrzMZNp+T0A2mZYdGVYEKIQ tZjngbSN9463vidulHjp7WJL9A== X-Google-Smtp-Source: AMsMyM5P+X1Y8Jh7jMCmuLvMc/mfXRn+2VeCqeQLX5xq8befqqyG8j7I1eyJrKbo6Aep6xM4jrP37Q== X-Received: by 2002:a05:6122:106e:b0:39e:e580:440 with SMTP id k14-20020a056122106e00b0039ee5800440mr3404373vko.37.1664506518317; Thu, 29 Sep 2022 19:55:18 -0700 (PDT) Received: from localhost ([2804:14d:7e39:8470:df9a:e42e:b6ac:6496]) by smtp.gmail.com with ESMTPSA id p72-20020a1fbf4b000000b0039e90e8eb62sm1156867vkf.4.2022.09.29.19.55.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 29 Sep 2022 19:55:17 -0700 (PDT) References: <20220927190944.201748-1-torbjorn.svensson@foss.st.com> <87pmfgeg1h.fsf@linaro.org> User-agent: mu4e 1.8.9; emacs 28.1 From: Thiago Jung Bauermann To: Torbjorn SVENSSON Cc: tom@tromey.com, brobecker@adacore.com, gdb-patches@sourceware.org Subject: Re: [PATCH v3] gdb/arm: Handle lazy FPU register stacking In-reply-to: Date: Fri, 30 Sep 2022 02:55:14 +0000 Message-ID: <87pmfdh8q5.fsf@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-11.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, 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 X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2022 02:55:20 -0000 Hello, Torbjorn SVENSSON writes: > Hello, > > On 2022-09-27 22:08, Thiago Jung Bauermann wrote: >> Hello, >> Torbj=C3=B6rn SVENSSON via Gdb-patches writ= es: >>=20 >>> diff --git a/gdb/arm-tdep.c b/gdb/arm-tdep.c >>> index 2810232fcb8..43ce1a45782 100644 >>> --- a/gdb/arm-tdep.c >>> +++ b/gdb/arm-tdep.c >>> @@ -68,6 +68,7 @@ >>> #endif >>> static bool arm_debug; >>> +static bool force_fpu_regs_from_stack =3D false; >> I'm a bit concerned about having a global variable to indicate what is >> (IIUC) a per-CPU state. Does this logic work with multi-processor >> inferiors? >> Instead of using a global variable, can arm_m_exception_cache use >> =E2=80=9Cthis_frame->level > 0=E2=80=9D to decide whether to get the FPU= registers from >> the stack? >>=20 > > I share your concern, but haven't found any better way to achieve the req= uired condition. > > The content of FPCCR shall only be considered for the first extended exce= ption frame on > the stack. As there are likely other kinds of frames on the stack, the le= vel would not be > enough to decide if stack or registers should be used. > > Do you know a way that this state can be saved per inferior? You could create a subclass of private_inferior containing force_fpu_regs_from_stack and store it in inferior->priv. An example is the remote_inferior class used by the remote target. It would still be inadequate for multi-core inferiors =E2=80=94 I don't kno= w how each CPU is modelled by GDB in that case. But if that scenario isn't currently required then perhaps we can cross that bridge when we get there... > On the other hand, I got the impression that the cache is purged when the= inferior is > switched, but this assumption might be wrong. switch_to_inferior_no_thread calls reinit_frame_cache so you're right IIUC. Even then, I think it's conceptually more correct to store this state in a private_inferior struct/class. --=20 Thiago