From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-f47.google.com (mail-wr1-f47.google.com [209.85.221.47]) by sourceware.org (Postfix) with ESMTPS id 45D77385C416 for ; Fri, 30 Sep 2022 15:52:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 45D77385C416 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=palves.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-wr1-f47.google.com with SMTP id x18so7512818wrm.7 for ; Fri, 30 Sep 2022 08:52:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:content-language:in-reply-to:mime-version :user-agent:date:message-id:from:references:cc:to:subject :x-gm-message-state:from:to:cc:subject:date; bh=8LpuJEy5nVBLyP7S2qP44axeDosNQFR3QahJffLYmZM=; b=EGnyMwfsLzQOusqW//TV/5IIN8kAzwygVHwMX7v9WYCs7xAjASSoCxyvEf9Ztyj32P nAtnIk0Lmb2BdyUU07x4hvzCJROTccC6NM2wWllhZPWYq5/xr3cPbCNzTAZINAcc1zPb k7jl6EyERXjTD3yGuDYAhXEEC5Oo35IrKA1mu6YWgfqjVx2I2c1l8xgsCifDuVTAIeKt yhfBw0UqOYeCyxCWg0O+rpldePGo8RMRo3krSCxzpXSVtjdzgT4akFigCSQBgB1gBaEL CRy7Dca00TQkQUPFNqsL+SLBocH3JacBr5Ht3f6VjkWEuRx9+ZZqvt5oWaMe486cry8Y qi3g== X-Gm-Message-State: ACrzQf3o9zjpMixXRFCMuL36xwc3ld6NQtv9tlwj32ZB6y5VZRBOhS3f SrS/eTHOekw2jYOcDmRkEmE= X-Google-Smtp-Source: AMsMyM4hesnjNklTKLMU2BK2X6h6AiskizX+PNX9OJ0wnwC3/v1fCwY0Dd1Vyh54uZ5u8SjY9N6enw== X-Received: by 2002:a05:6000:154b:b0:22a:9683:3a2d with SMTP id 11-20020a056000154b00b0022a96833a2dmr5992293wry.369.1664553171301; Fri, 30 Sep 2022 08:52:51 -0700 (PDT) Received: from ?IPv6:2001:8a0:f93a:3b00:e038:5cdc:b8bf:4653? ([2001:8a0:f93a:3b00:e038:5cdc:b8bf:4653]) by smtp.gmail.com with ESMTPSA id bx10-20020a5d5b0a000000b00228fa832b7asm2393997wrb.52.2022.09.30.08.52.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 30 Sep 2022 08:52:50 -0700 (PDT) Subject: Re: [PATCH v3] gdb/arm: Handle lazy FPU register stacking To: Torbjorn SVENSSON , gdb-patches@sourceware.org Cc: tom@tromey.com, brobecker@adacore.com References: <20220927190944.201748-1-torbjorn.svensson@foss.st.com> <0aa66097-a196-6ca8-e47f-45fae4482cfa@foss.st.com> From: Pedro Alves Message-ID: <301788c6-6391-f9d3-8e70-06fbea21f413@palves.net> Date: Fri, 30 Sep 2022 16:52:49 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: <0aa66097-a196-6ca8-e47f-45fae4482cfa@foss.st.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, 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 15:52:54 -0000 On 2022-09-30 4:26 p.m., Torbjorn SVENSSON wrote: > Hi, > > On 2022-09-30 17:13, Pedro Alves wrote: >> Is there really no self-contained way to tell that a frame is a "following frame >> after lazy stack has been enabled" ?  E.g., can we look at the address in >> FPCAR and decide based on it, compared to the current frame address, or something >> like that? > > As the function is Cortex-M specific, I suppose it would be fine to assume that the stack always grows downwards. With this assumption, I suppose we could compare the value in FPCAR with the value of $sp of the frame to be unwinded after the current frame. > - If the value is lower, then I think it's safe to assume that the stacked content should be used. > - If the value is greater, then I think it's safe to assume that it's up to LSPACT, LSPEN and ASPEN to define if it's going to be register or stacked content that should be used. > > Does this sound reasonable? > It does to me. I suppose the scheme could break if it's possible to have something like sigaltstack, or coroutines, i.e., some frames after lazy FPU has been enabled are actually running with a different stack. Not sure, maybe you'd never see lazy FPU stacking be enabled across the cpu/thread switching stacks? > I'll try to find some time later today or in the weekend to give it a try. > Thanks.