From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 2FfeDQKdY2COdQAAWB0awg (envelope-from ) for ; Tue, 30 Mar 2021 17:49:54 -0400 Received: by simark.ca (Postfix, from userid 112) id 2FB291EE0E; Tue, 30 Mar 2021 17:49:54 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-0.7 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RDNS_DYNAMIC,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (ip-8-43-85-97.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 57ABA1E789 for ; Tue, 30 Mar 2021 17:49:53 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id B96C73858012; Tue, 30 Mar 2021 21:49:52 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B96C73858012 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1617140992; bh=bFkgpZpRaYaWHbN3zWkP4jgJ7lI5cFt0c9AFMLfeLug=; 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=n4ugJmyGN4IZ55kumSA+O6MJC9Qkud1Dqht1kNKAD51r4kl2eiA/gnNZ5o1vEVBIy uA4UiKp948QA57IA/Ofesa7lx4sQJ0T+G2DUmyQizRyAiREf3f9YdWvu6rxMz++aez gxnj1kDThJn0fR7uGl7b0+1lUVFfBIPnVaNwOWgU= Received: from smtp.polymtl.ca (smtp.polymtl.ca [132.207.4.11]) by sourceware.org (Postfix) with ESMTPS id B3DF63858012 for ; Tue, 30 Mar 2021 21:49:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org B3DF63858012 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 12ULnhnU018192 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 30 Mar 2021 17:49:48 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 12ULnhnU018192 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)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 5607F1E789; Tue, 30 Mar 2021 17:49:43 -0400 (EDT) Subject: Re: Remote query for structure layout To: David Blaikie References: Message-ID: <6b00bbbe-1400-7f11-bdcf-811595bf8e31@polymtl.ca> Date: Tue, 30 Mar 2021 17:49:43 -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 Tue, 30 Mar 2021 21:49:43 +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 5:41 p.m., David Blaikie wrote:> > Is the register layout in this struct part of the ABI? If so the debugger could assume it/hardcode the knowledge. I don't think this is part of any ABI, this is just how FreeRTOS stores the registers of inactive tasks. So it's like an implementation detail of FreeRTOS, but one that the debugger needs to know in order to inspect existing threads. >From what I undersand from Tim's message, the GDB stub inside OpenOCD already hardcodes that knowledge, but the problem is that the layout can change based on compilation options (which OpenOCD probably can't easily detect), and the layout could change between FreeRTOS versions. > If not, then it seems to me the right thing might be for the compiler to have builtin support for emitting this struct under a reserved name into every CU, perhaps? Not relying on source quirks to encourage it (as you say, would leave you at the whims of the compiler implementation), but actually make it explicitly part of compiler support for this architecture. Maybe an attribute struct the_struct { } __attribute__((always_emit_debug)); ? Simon