From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id F16DB3858D3C for ; Mon, 20 Nov 2023 10:34:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org F16DB3858D3C Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org F16DB3858D3C Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1700476448; cv=none; b=aZM4/HCeA/VJ9jPB3gH/6qqL5x80h3+YD/WE9h0cgPEPbaL0RZ/hBG6V0hg9I+xySxmh2vQoNnxLjmmAIWus6kcWr9t2LbGfh/vRiuOvtTDZKE+K34Ln6iyRWsKpCir52uHOca/8KfvQAApDBzPVX5RhF23U/6JHnZMyKMtQKVI= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1700476448; c=relaxed/simple; bh=rpV5Od8C0WSobjlQaTAErG/MAT4QY/uj9uKfYIDt5bM=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=wqCt2v30IK9zoXnHDvdB8AmaJUKKx5RZrFIVDDWlJC2LprIy67ADSBTomO/oGqWyIdI+BIzQPzDNjdX4FJiwZK20w6SsMA+O2TM6tPid1HUXHpLZfyZpDzYNsxF94ln08laaT+5XoAe8lLX2n9Q7/+L1XH09+Tu1Lv3Vs6ACFhE= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1700476446; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references; bh=37hwcNZx3S5NdEtpE8gcJ38M7N2/39HrNgLpxQ2X0O0=; b=NggGyJEBxM1vhQY1rPjDtCwvWM/qj2DFZ4QhlQhuDUpI5AxnM1AJj0lQDTo2Etb/i5kI/P riY/TiEeFAvwwHLamzoN/UgTgBdy2amkrflgkkXNMsnsF367/8S+TNKBAlSyy0aW+g0qQl 0WWrkVqv18ELYIYdIFwNF1MaSxzBVc0= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-370-MZGNmre8OIaC-A4D6K3yWg-1; Mon, 20 Nov 2023 05:34:04 -0500 X-MC-Unique: MZGNmre8OIaC-A4D6K3yWg-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.rdu2.redhat.com [10.11.54.7]) (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 mimecast-mx02.redhat.com (Postfix) with ESMTPS id 6F99F812C27 for ; Mon, 20 Nov 2023 10:34:04 +0000 (UTC) Received: from calimero.vinschen.de (unknown [10.39.193.251]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 4DD2E1C060B1; Mon, 20 Nov 2023 10:34:04 +0000 (UTC) Received: by calimero.vinschen.de (Postfix, from userid 500) id EAF2CA80940; Mon, 20 Nov 2023 11:34:02 +0100 (CET) Date: Mon, 20 Nov 2023 11:34:02 +0100 From: Corinna Vinschen To: newlib@sourceware.org Cc: Jeff Johnston Subject: Re: Usage of __assert_func in standard library Message-ID: Reply-To: newlib@sourceware.org Mail-Followup-To: newlib@sourceware.org, Jeff Johnston References: MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.7 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Spam-Status: No, score=-4.8 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham 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 Nov 18 19:13, Alex Tarasov wrote: > Dear developers of Newlib, > > I think we have a bit of an issue concerning usage of *__assert_func *function > in the current version of the standard library. > [...] > ld.exe: PathToCompiler/../lib/gcc/arm-none-eabi/13.2.1/thumb/v7e-m+fp/hard\libg.a(libc_a-closer.o): > in function `_close_r': > closer.c:(.text._close_r+0xc): undefined reference to `_close' > [...] > The analysis of cross reference table in the .map file showed me the source > of these errors. Somehow, in the newer toolchain functions from the > standard library (*strtod* in my case) call *"__assert_func"* which in turn > lead to various system calls. I downloaded the latest Newlib version on the > "main" branch and saw this code in the *newlib/libc/stdlib/mprec.h* file: > > #define eBalloc(__reent_ptr, __len) ({ \ > void *__ptr = Balloc(__reent_ptr, __len); \ > if (__ptr == NULL) \ > __assert_func(__FILE__, __LINE__, (char *)0, "Balloc succeeded"); \ > __ptr; \ > }) > > According to *git log* this *eBalloc* macro was introduced in commit > with f88aece242178ff0c187d56e34a79645fbc44a23 > hash on October 4th 2019. This leads to several functions in the standard > library calling *__assert_func* inside them. Standard definition of this > function in *newlib/libc/stdlib/assert.c* calls *abort* and *fiprintf* > functions > which in turn drag a lot of system functions (see error log that I > mentioned above). > > This leads to several issues: > > - If I want to use some functions from the standard library (like > *strtod*) but I don't want any system calls, I need to redefine > *__assert_func* in my project. I have to do it even if I don't use > assert's anywhere in my own code. > - There is a project where I use and my own > implementation of *__assert_func. > *I expect that when I build my project with NDEBUG macro defined > (release configuration), I would not see any calls to that function. That > is not the case if any function from Newlib's standard library that uses > *eBalloc* macro gets linked. > > I think this behaviour is too implicit and needs to be fixed. I suggest > removing *__assert_func* from *eBalloc* macro or making some other changes > to Newlib that will get rid of the mentioned issues. Yeah, that looks a tad too aggressive. I see only ~20 calls to eBalloc in newlib. Maybe somebody can take a stab at it and convert the calls to Balloc plus error checking? However, the parent functions of the functions calling eBalloc potentially don't check error conditions either, so this might be indeed a bit more work than a quick count of the eBalloc calls indicates... Jeff? Any idea how to go forward? Corinna