From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) by sourceware.org (Postfix) with ESMTPS id 59DF33893658 for ; Tue, 28 Nov 2023 09:18:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 59DF33893658 Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=googlemail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=googlemail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 59DF33893658 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::134 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701163121; cv=none; b=RonguUmY6XVOZyLp3S8DfE4eWow4tiaiL/2v7Zqsuar1yq87LfGGyXDfyF9t1zVxSp1E6F+f56T88BJ4VESVaUvuWeJGMqSzdNFUEFxx65KSLTOJCOwCaUgrJ89cpYkFsmqaEcqRw5fuVzTukLyq3Y2VdGQ/LbZu6pBpIHetRwA= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701163121; c=relaxed/simple; bh=X/mVLLJ3otdBZ//ojzkdhFsyDa0lLJbZCWjxmUEMRXQ=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=xeWkimRQ805jg6PeYgUagM1pdu61ggOawATi50vS0c4d/j8Pb22wUNV1s32x1ibLOk/nipNKM2ArPlKxYeQzmhYsWEjKritlyaN0eRu4aY1npwrRSsmbc3dqhyWNdsZlnsL2kdrYzbJm1qX3V5smXoZttkRa55xEgzm/xBiZjQc= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-lf1-x134.google.com with SMTP id 2adb3069b0e04-507a0907896so6732851e87.2 for ; Tue, 28 Nov 2023 01:18:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20230601; t=1701163118; x=1701767918; darn=gcc.gnu.org; h=to:subject:message-id:date:from:reply-to:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Gxl3rAmMoopg9O2nWCk+DIQ4NUbq6OpbzjVuUZveMao=; b=TD1QdCEKFhRY9tDPAvSS99FE585MEGbngLn/TAHwlqyqtYbaIydsO6HT5+tD21gi7y YErX3o4dIutmLZ5MSvsLue842epVeOosexcrNnQnsbP8HocNVBDBvWOYKyemUtsH/KT7 AICiQYnUujI9CS2stiZc8Jx+PDSRdxyGC+z+x64zljZk7LH33zqDvgiTiJtaagpJazFc rTgnZB6DEq3KeQyw01Sri3vJMSSaXFOnzHoMZCcI/9cVVTi20EKNkuzswTMK6iVJXUax Y2lmdcxokXPRc3JzMK/7pd3+1fNoUZfcnm17JmvPwgleiB+G7EMRGL56eUApSsnTrk2x uQyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701163118; x=1701767918; h=to:subject:message-id:date:from:reply-to:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Gxl3rAmMoopg9O2nWCk+DIQ4NUbq6OpbzjVuUZveMao=; b=fFP4gkKy0OA8BeCQpjZMoYIq4guiWVM+zdmyuHFRyjbgjb4LG0YFi1Dt6rczjgKVeY FpDaxYRjOGr5YouvA6liY+qjP3Wsabq52QiH89s1q7TolMcq6jX5HjPZOX0x3avq2Yvf PP0FSa2xbfF/UGVXI80jJBcr4Huv+GuIEILlDVWvZZyeDcZqd2hdexPwPrOmeeKe8dMN F4M/BZeCzztwYszsJKJ/1i5NYww8ZvWrYNdCZcFKuRnl7bKr5hRWHK5FYk6LTxGb07oZ LE5/Yi5igmXtVXfef19UQIyjdBQ6I4w6RI6g5n7swHEo3iA+4vpS//hfcwFMStlQb+st Bacw== X-Gm-Message-State: AOJu0YwHJEyE86yKN99Tq3bKVXCDao2BcpnIVKr3+ktLY3HR8HJwTtlS ymez//atPM0zizyp5UhbyDVudPKKr06ijMSqBPA= X-Google-Smtp-Source: AGHT+IFE1yWZnUOiAOMHe8151gtktOzz53axOThqKHqMWN7LzapBAA2x1mD4Y2F5ZPnHCynkPg1NdMVm8jqVruXgz0Y= X-Received: by 2002:ac2:5634:0:b0:50b:ba79:957e with SMTP id b20-20020ac25634000000b0050bba79957emr758371lff.42.1701163117533; Tue, 28 Nov 2023 01:18:37 -0800 (PST) MIME-Version: 1.0 References: <36da6a00-6b2f-4628-b7ae-d7190a691c46@hesbynett.no> In-Reply-To: <36da6a00-6b2f-4628-b7ae-d7190a691c46@hesbynett.no> Reply-To: edd.robbins@gmail.com From: Ed Robbins Date: Tue, 28 Nov 2023 09:18:25 +0000 Message-ID: Subject: Re: arm-none-eabi, nested function trampolines and caching To: David Brown , gcc-help@gcc.gnu.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=0.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,FREEMAIL_REPLYTO,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi David! On Mon, 27 Nov 2023 at 17:23, David Brown wrote: > > On 27/11/2023 16:16, Ed Robbins via Gcc-help wrote: > > Hello, > > I am using gcc-arm-none-eabi with a cortex M7 device, with caches > > (data/instruction) enabled. Nested function calls result in a usage fault > > because there is no clear cache call for this platform. > > > > I am not sure I understand you here. Are you talking about trying to > use gcc nested function extensions, implemented by trampolines (small > function stubs on the stack)? If so, then the simple answer is - don't > do that. It's a /really/ bad idea. As far as I understand it, these > are a left-over from the way nested functions were originally > implemented in other gcc languages (Pascal, Ada, Modula-2), which now > handle things differently and far more efficiently. Trampolines were a > convenient way to implement nested functions some 30 years ago, before > caches were the norm, before anyone thought about security, before > processors had prefetching, and before people realised what an > appallingly bad idea self-modifying code is. > > If you want to use nested functions, use a language that supports nested > functions, such as Ada, or use C++ with lambdas (which are a bit like > nested functions only much better). I am aware of the alternative languages and the implementation limitations, but I didn't ask if it is a good idea or not! > > > Is there a way to provide the required functions without rebuilding gcc? I > > have been looking at the source and, as far as I can tell, there is not. > > I can think of at least four ways : > > 1. The SDK for your microcontroller, provided by the manufacturer, will > have headers with cache clear functions. > > 2. The ARM CMSIS headers - also available from your manufacturer - has > intrinsic functions, including cache clear functions. > > 3. gcc has a generic "__buitin__clear_cache" function : > > > 4. gcc supports the "ARM C Language Extensions", which include cache > control intrinsics: > > > > I'm aware of how to perform a cache invalidate/clean, but that isn't the question. > > > > > But there also doesn't look to be a clean way to implement this: It appears > > that this is done on an operating system basis, and when running bare metal > > it is not clear where the code would live. > > There is no "clean" way to handle the appropriate cache invalidation, > because there is no clean way to get the addresses you need for > invalidating the instruction cache. Yes, there is, and that is what my question is about. The gcc documentation on trampolines [1] details this to some extent. It says that the target should define CLEAR_INSN_CACHE(beg, end) and it will be called with the correct addresses when the trampoline is initialised. Looking at the gcc source, arm.cc calls maybe_emit_call_builtin___clear_cache with the correct addresses when it initialises the trampoline, and maybe_emit_call_builtin___clear_cache calls __clear_cache if CLEAR_INSN_CACHE is defined. The question is about where to place this clear cache definition for a "none" target. (Cleanly invalidating the > instruction cache for other purposes, such as during firmware upgrades, > is no problem.) Yes, we do this already during firmware upgrades. Best regards, Ed [1] https://gcc.gnu.org/onlinedocs/gccint/Trampolines.html