From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id MqB9CVe/Y2A6eQAAWB0awg (envelope-from ) for ; Tue, 30 Mar 2021 20:16:23 -0400 Received: by simark.ca (Postfix, from userid 112) id 1A30F1EE0E; Tue, 30 Mar 2021 20:16:23 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from 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 RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 6209D1E01F for ; Tue, 30 Mar 2021 20:16:22 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id C5DDB3858018; Wed, 31 Mar 2021 00:16:21 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C5DDB3858018 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1617149781; bh=tXPiR08SFANfEBP0MLqA6baqwsBfLXbXak6UPWokjN8=; h=Subject:To:References:Date:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=PVQNd3k2vtqdoxiRawa09xA8yn+5wPjiqy6vAGMnpBIro21o6mBSX28ZV5ATUyxt1 4ioTfSomkZbmjF+uRfCb7BfnmLw4upJCN6Ac9Z6sXJQQMQziQZ6nTqrErtHFN+xxOp +jKKvNyYju50WwHf7p8lvPYVzGCK7LkTagTCxtfY= Received: from smtp.polymtl.ca (smtp.polymtl.ca [132.207.4.11]) by sourceware.org (Postfix) with ESMTPS id BE18E3858018 for ; Wed, 31 Mar 2021 00:16:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org BE18E3858018 Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id 12V0GA1k016590 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 30 Mar 2021 20:16:14 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 12V0GA1k016590 Received: from [10.0.0.11] (192-222-157-6.qc.cable.ebox.net [192.222.157.6]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id DB0B71E01F; Tue, 30 Mar 2021 20:16:09 -0400 (EDT) Subject: Re: Remote query for structure layout To: David Blaikie References: <6b00bbbe-1400-7f11-bdcf-811595bf8e31@polymtl.ca> Message-ID: <1c8fec3c-0d7e-d133-bf88-adaf764473f1@polymtl.ca> Date: Tue, 30 Mar 2021 20:16:09 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Wed, 31 Mar 2021 00:16:10 +0000 X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Simon Marchi via Gdb Reply-To: Simon Marchi Cc: Tim Newsome , gdb Errors-To: gdb-bounces@sourceware.org Sender: "Gdb" On 2021-03-30 6:44 p.m., David Blaikie wrote: > If it's "just" some user-code, is there a variable of the desired type being declared around the function call? AFAIK, this type wouldn't be used by the FreeRTOS code at all, so no. Again, here's my understanding, hopefully it's close enough to the reality. When a trap occurs, FreeRTOS saves the current task's register values on the task's stack, using some arch-specific assembly code. For example, for RISC-V: https://github.com/FreeRTOS/FreeRTOS-Kernel/blob/534eba66ce4a5bda45d5edeeb81ac5a3cf6d0df8/portable/GCC/RISC-V/portASM.S#L121 The way these registers are pushed is an implementation detail of FreeRTOS. And we can imagine that it can vary depending on the compile-time FreeRTOS configuration, which OpenOCD doesn't know about. To get register values of scheduled out tasks, OpenOCD needs to interpret these register values from the tasks' stacks. So Tim's suggestion is: have FreeRTOS declare a structure that has the exact layout as the saved registers on the stack: struct freertos_saved_regs { int x1; int x5; int x6; ... }; Consumers could read that structure's layout from the DWARF info, and read the register values based on that. That would be a lot more robust than hard-coding in the consumers how FreeRTOS stores things. However, since that struct would never actually be used by FreeRTOS' code, the compiler won't emit it. Hence the need to find a way to force the compiler to include it in the DWARF. Does that clarify the situation? Simon