From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id QVKPJjqVZ2APWwAAWB0awg (envelope-from ) for ; Fri, 02 Apr 2021 18:05:46 -0400 Received: by simark.ca (Postfix, from userid 112) id 8F9D31EF62; Fri, 2 Apr 2021 18:05:46 -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 CF64A1EE0E for ; Fri, 2 Apr 2021 18:05:44 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 65F43385781B; Fri, 2 Apr 2021 22:05:44 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 65F43385781B DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1617401144; bh=Wdfol3dEpMtF6pOJm/dKfXTOnx/sdqtA4ozGaurUnQ4=; h=References:In-Reply-To:Date:Subject:To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=m45NtV+cYwlOzqpIOrwoCNSWZl8zeDyji4iW0/biF5aSFBriqGsUYpTr+/fgVd/Sb Pqrt1XL1Y7O69gB7jQnA9iRZHE/hZ28Wl4SdMMnhQA8NjrIdIOT61wxHow7wCTF4aR EgubDTJagLJMwRn1qKf/62L0uV/nG3A3wmSIuhq4= Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com [IPv6:2607:f8b0:4864:20::435]) by sourceware.org (Postfix) with ESMTPS id 07BF3385781B for ; Fri, 2 Apr 2021 22:05:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 07BF3385781B Received: by mail-pf1-x435.google.com with SMTP id c204so589116pfc.4 for ; Fri, 02 Apr 2021 15:05:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Wdfol3dEpMtF6pOJm/dKfXTOnx/sdqtA4ozGaurUnQ4=; b=lmI0lF1YWVUx3FvK1H18bmyrmCq9/tD/TnnFvCLYDn9cFjjiQvq5HSoA0XKUBpLjx9 /tIi3RQ9sdzLRmS5g6URt0R5CHikNtn4BiKmI8/eO7XhpjGqPJNXvZhwozscMwQ+LBbA C07iqgzs54iJX/4vTIgPP1pvjiokSEUpbY4Yk5467HSWcy74lkPo/Pup7Uu1At3sTKLl ajhLFEggYFBqIF4YFdZkeyTjc6qHZz67ZMTUXCQTWT/3RlkaOZ7N3rkw8GnmTCYXpgGm Z5/HVo6Ksumv+H+eD2BfhGj0ecacpn7WTOTL3MxQU4FiQlA2Ej1Kl3cA/5VJoFVVBdQl 0evw== X-Gm-Message-State: AOAM531hRO2RK8x73/T4XCHOLBwa5DKBHk+nyG61N7Y38SlDkS9V/c76 wV6LUSdH2Gy2rBOMyi8OZxYsQzyqjEFip489I4uNwqRlmSQ= X-Google-Smtp-Source: ABdhPJxF6UWIfJN4HpVkseJXQyiH387BZwCBkCeug3F5x1PV+EI81+5J4fxhnq/4DrjbyvGljC3Ax15T8uPAoZvwBxs= X-Received: by 2002:a62:1953:0:b029:20a:d94d:dd69 with SMTP id 80-20020a6219530000b029020ad94ddd69mr13721110pfz.44.1617401141093; Fri, 02 Apr 2021 15:05:41 -0700 (PDT) MIME-Version: 1.0 References: <6b00bbbe-1400-7f11-bdcf-811595bf8e31@polymtl.ca> <1c8fec3c-0d7e-d133-bf88-adaf764473f1@polymtl.ca> <4f5e4de2-035d-a1eb-69ef-bb4144ce82de@polymtl.ca> In-Reply-To: <4f5e4de2-035d-a1eb-69ef-bb4144ce82de@polymtl.ca> Date: Fri, 2 Apr 2021 15:05:29 -0700 Message-ID: Subject: Re: Remote query for structure layout To: Simon Marchi Content-Type: text/plain; charset="UTF-8" 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: David Blaikie via Gdb Reply-To: David Blaikie Cc: Tim Newsome , gdb Errors-To: gdb-bounces@sourceware.org Sender: "Gdb" On Wed, Mar 31, 2021 at 6:00 AM Simon Marchi wrote: > > On 2021-03-30 11:27 p.m., David Blaikie wrote: > > (let me know if I'm just being an unhelpful bystander here - I clearly > > don't have a lot of context) > > I think it is interesting. If people are not interested they can just > skip reading this thread :). > > > On Tue, Mar 30, 2021 at 5:16 PM Simon Marchi wrote: > >> > >> 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 > > > > Ah, OK. So this is part of signal handling - so it's not part of the > > code that's compiled into the user's program, for instance... not even > > in some system library linked in, necessarily, I guess? > > It is part of "user code". Wih "big" OSes (e.g. Linux), the OS is > compiled on its own and the user programs are compiled separately. With > embedded RTOSes (at least those I worked with), it's just one big > program. Your user code includes and calls FreeRTOS > functions to spawn to tasks. > > >> 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, > > > > I guess in the worst case it could be totally dynamic - it could pick > > a different layout each time. > > Yes, if it wanted to be really annoying :). > > > (guess a side question: How's this different from other systems? I > > don't know how other/more common systems handle registers during > > signals) > > I think Linux does the same, pushing the registers (and some information > about the signal) on the thread's stack before calling a signal handler. > The layout is defined by the ucontext structure, exposed in the Linux > ABI: > > https://github.com/torvalds/linux/blob/master/arch/riscv/include/uapi/asm/ucontext.h > > GDB hardcodes that layout here: > > https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=gdb/riscv-linux-tdep.c;h=ca97a60128ffe681766e7e1600d3f24048bf1f68;hb=HEAD#l103 > > Being exposed by the Linux kernel and part of this ABI, this structure > is not likely to change. That makes it reasonable to hardcode it. Ah, fair enough - good to understand and compare/contrast. > >> 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. > > > > If practical experience has shown the hard-coding is not > > stable/reliable (than FreeRTOS does change its strategy from time to > > time - but it's always constant for any given build of the FreeRTOS) I > > guess. > > My guess is that FreeRTOS does not change it that often, there's not > reason to. But it can vary from build to build due to compile-time > configuration of FreeRTOS (i.e. include or exclude support for using > some particular register). An external observer such as OpenOCD does > not have access to the compile-time configuration that was used to build > FreeRTOS, so it's difficult to know what the layout used by this > particular build is. Fair enough. > > But I'm not sure where FreeRTOS would expose this structure to user > > code - it's not like there's a system library header that user code > > must include... > > There is, any code using FreeRTOS will include FreeRTOS.h. Oh, that helps a lot, then. > You can see > FreeRTOS more like a library than an OS. FreeRTOS is not involved at > all until the user program calls functions like xTaskCreate to create > some tasks and calls vTaskStartScheduler to hand over control to > FreeRTOS. OK > So if the structure was declared somewhere in the port's include file, > it would necessarily be seen by some CUs (those that invoke FreeRTOS > functions). Great! One possibly "cheap" way would be for FreeRTOS to use the structure in C code to do the register stashing - rather than or in addition to/in some kind of hybrid manner along with the assembly. If that's not possible/would make the code harder to understand, then finding some other way to pin the data structure into the DWARF would be needed. I'd be inclined to avoid adding a new attribute or other feature (though I wouldn't be entirely opposed to it - I can certainly think of other places where it may be useful to have a "whenever the compiler sees this type, ensure it makes it into the resulting DWARF no matter what" attribute) if reasonably possible - instead finding some lowest-common-denominator/highly reliable signal that compilers use to emit type information. The simplest such signal is a global variable of the type (not a pointer to it, but of the type itself) - though probably has to be annotated in some way that ensures the compiler won't optimize the variable away even under LTO, etc. I'm not sure sure off-hand if I have a great way to do that portably (non-portably I guess there's various "exported" attributes that ensure the entity is visible even beyond the shared library/executable scope, and thus can't be optimized away - maybe such an attribute would be sufficiently portable for FreeRTOS's needs (ie: no less portable than the rest of the code already)). If such a variable would be problematic (taking up space in the image, etc) - maybe there's a way to ensure it through an extra nonce parameter (if it's C++ code, a parameter with a default argument - so the caller never has to think about it) to some core FreeRTOS function that won't be optimized away/removed as unused/etc. Again, has a runtime impact, though - maybe if it was zero-size (like a class template specialization with no members) & with the type as a template parameter /maybe/ that would suffice... Happy to play around with mechanisms like that if it's of interest. > >> 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? > > > > Somewhat - any lack of understanding is just my ignorance in this > > field/area in general, to be clear. (I'm also not a core gdb > > developer, so I'm not the sort of person you have to convince of > > anything - just a curious bystander trying to understand/maybe offer > > some insightful suggestions (I predominantly work on LLVM's debug info > > emission, so that's my background/connection)) > > Well, since it's related to debug info emission, it could land on your > plate at some point, it's good that you have some context.