From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id 698923858D28 for ; Wed, 15 Feb 2023 17:01:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 698923858D28 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=foss.arm.com Authentication-Results: sourceware.org; spf=none smtp.mailfrom=foss.arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 9F4061042; Wed, 15 Feb 2023 09:01:50 -0800 (PST) Received: from [10.57.52.9] (unknown [10.57.52.9]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 6FA1A3F881; Wed, 15 Feb 2023 09:01:07 -0800 (PST) Message-ID: Date: Wed, 15 Feb 2023 17:01:05 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1 Subject: Re: [PATCH] libc: arm: setjmp jmp_buf exagerated size Content-Language: en-GB To: Bernhard Krug , newlib@sourceware.org References: <7074AE0F-4BFC-48B4-AE8B-DCCA22D0105E@elektronenpumpe.de> From: Richard Earnshaw In-Reply-To: <7074AE0F-4BFC-48B4-AE8B-DCCA22D0105E@elektronenpumpe.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3489.6 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,NICE_REPLY_A,SPF_HELO_NONE,SPF_NONE,TXREP 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: On 15/02/2023 16:40, Bernhard Krug wrote: > On February 15, 2023 5:12:04 PM GMT+01:00, Richard Earnshaw wrote: >> >> >> On 15/02/2023 11:09, Bernhard Krug wrote: >>> Patch sets correct jmp_buf size for armv6-m conforming to implementation in setjmp.S >>> >>> FYI a table of cortex architectures: >>> __ARM_ARCH_6M__ cortex-m0/m0+/m1 no fpu option >>> __ARM_ARCH_7M__ cortex-m3 no fpu option >>> __ARM_ARCH_7EM__ cortex-m4 optional fpu >>> check using __ARM_FP >> >> I don't think it's as simple as this. The ABI supports three variants, two of which are call compatible. >> >> hard-float (where you must have hardware FP) >> soft (where you haven't got any hardware FP) >> softfp (where you have hardware FP but need to inter-operate with code that doesnt). >> >> soft and softfp are call compatible and so any jump-bufs created need to support saving and restoring the FP context. >> >> I guess a configure-time option to disable support for softfp might be an option, but the default needs to ensure things are compatible. >> >> R. > > As far as I understand the source in setjmp.S in the case of armv6-m it is. > Looking in the source > https://github.com/bminor/newlib/blob/master/newlib/libc/machine/arm/setjmp.S#L89 > How I read this: It will never copy more than ten registers because of the exclusive #if #else ... But you can build your source file with a jmp_buf in it, and if you then end up linking it against a version of the library that expects a larger buffer it will end up corrupting data. The following has to work file1.c // compiled for arm6m soft-float file2.c // compiled for arm7m softfp image // link file1.o and file2.o with softfp libraries. This can't lead to file1 having a different jmp_buf size or layout to file2 or the version in the library. > > But okay let it be 20 registers. > Then does it have to be "long long" only for special chips that use wider registers in their FPU? long long is used for alignment, but that doesn't affect the size because you only need half the number of long longs as you do longs. > > Then I'll hope for a decision-tree ARM_ARCH_xy ARM_FP ARM_NEON in the future :) R.