From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yb1-xb2d.google.com (mail-yb1-xb2d.google.com [IPv6:2607:f8b0:4864:20::b2d]) by sourceware.org (Postfix) with ESMTPS id DF73B3858C60 for ; Sat, 18 Nov 2023 16:13:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org DF73B3858C60 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org DF73B3858C60 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::b2d ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1700324032; cv=none; b=pOfl99keRjEaUDMoIW1bd5PxGIBmZYDjFyfaTaY5yXncRm6PYxphd3Ncl2ThWw0ZLyQhCTe6uF+MmjLi7w0UiSAutL10+jUWTZz3UhKHloMxMYyg12TEN0gFh8MOpZY590Hn28UTyCKi9fxEEFNnQ+1rDwmd6YRjTqFPq55kzn0= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1700324032; c=relaxed/simple; bh=kVXIE47clg/m8uurZjIL33ztO804BJKubjWAQ2IE1vo=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=hWE8JqXYHiYmJ8Z5AyRITYiyKXwOZVv9GkjLZuefP/+tRkMsga5uA9oQKIDrLKwrPM6oQdQllTlbAuKqkTT4EbqbKK60epwn0yyWwaTC6/sptO+krFWZHFu4LTP1b3iydIGlpfuAqK1ry0PrNQNKSzV5F9cr0pUCsqws/jz+CAY= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-yb1-xb2d.google.com with SMTP id 3f1490d57ef6-d9beb865a40so2856966276.1 for ; Sat, 18 Nov 2023 08:13:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1700324030; x=1700928830; darn=sourceware.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=mIgTGoYePiwjFR/vm5Y2J02UdaTTQAh00lxH/EMz+wU=; b=TaWNq8eZ794iLttcMlYFqp3xhv4umgQ3nVYnZFXMMchScUoOgUiOkWTZi+CgVu/87q kENJk3mEy71Zfs/kBN9sjYNLlCTQQ40sbEH//az7HgydxNxVzGCiAYOFghC7YaDQ3QCV bjvOvygjgcS6fV7RxIdRh/OVloHfkIhNXteNZm5/fxM9Zo40IrqenV/pa+v9jUiVuvp1 0csunAQF/q540wLFcow0aa5GDK3Qc7a40BzaNkxyvD5czixvMlI0eXJen43BNJHmR+tk 7NWNMBR3NV6hljX7pxr55Ju2ab5r8oPykyZ2tcJu5csqOc/3LS+MrUEYZbmbRVy67cK1 wXHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700324030; x=1700928830; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=mIgTGoYePiwjFR/vm5Y2J02UdaTTQAh00lxH/EMz+wU=; b=QtTKXkdeKPSd7hGVywIp4XJoh7UK5I9YMnf2++BXdEEby3gHlLu8vNIiaWPGuBSl9b SGwIK7ANrnqRZ/v2QanRN6V4pf14ny3UD8+g5CtTR1qENIdbZ33GS2Ex6khMQBIAFEUo 4xI2Td72HSXAvpuo8vdgkcrVQxdZCarB8wsoKLYTtORgW06yRS+BvZAyzr7ouJ8/2o+Q qbseRoKdMJMlK8cR9V/Ass1dKF609xyyTgbjGkb0UMEtkPsr2LSBGClemlDLUy21F7fA /0PT4y9IAPem75j/La5NuKe7uqCbUrgbc+qusPOz5U7taTE95sI5Y/a4fwruK5PGSKpr qTYg== X-Gm-Message-State: AOJu0YxJuD1YcC3mEAL3RDJfigKD9K4XOBchMzRUdhUBhkykViFZLlsY dC0cRI4Ocs1bNTbZlCfK5K7OfwQbSCApfqRBLQ5iihF05LM= X-Google-Smtp-Source: AGHT+IFmkG2CTe2fTgvObKTazlF3GldfcisRBZtfM2eESPTq1jQWOlFjxZ3tpArdR8UOz43j5FqSfxJX+unZPV059HM= X-Received: by 2002:a25:c287:0:b0:d09:34f4:6698 with SMTP id s129-20020a25c287000000b00d0934f46698mr2564688ybf.36.1700324030018; Sat, 18 Nov 2023 08:13:50 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Alex Tarasov Date: Sat, 18 Nov 2023 19:13:38 +0300 Message-ID: Subject: Fwd: Usage of __assert_func in standard library To: newlib@sourceware.org Content-Type: multipart/alternative; boundary="000000000000cff911060a6f89d0" X-Spam-Status: No, score=0.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,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: --000000000000cff911060a6f89d0 Content-Type: text/plain; charset="UTF-8" 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. Let me describe what I've stumbled upon. I'm using "Arm GNU Toolchain" for embedded software development. This toolchain is shipped with Newlib's standard library. Up until recently I've been using the old version of the toolchain (released in 2019). When I tried to update to the newer one, I faced a problem. My project is being built without any errors or warnings with the old toolchain, but when I try to build it with the newer version I get these errors: 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' PathToCompiler/ld.exe: PathToCompiler/../lib/gcc/arm-none-eabi/13.2.1/thumb/v7e-m+fp/hard\libg.a(libc_a-lseekr.o): in function `_lseek_r': lseekr.c:(.text._lseek_r+0x14): undefined reference to `_lseek' PathToCompiler/ld.exe: PathToCompiler/../lib/gcc/arm-none-eabi/13.2.1/thumb/v7e-m+fp/hard\libg.a(libc_a-readr.o): in function `_read_r': readr.c:(.text._read_r+0x14): undefined reference to `_read' PathToCompiler/ld.exe: PathToCompiler/../lib/gcc/arm-none-eabi/13.2.1/thumb/v7e-m+fp/hard\libg.a(libc_a-writer.o): in function `_write_r': writer.c:(.text._write_r+0x14): undefined reference to `_write' PathToCompiler/ld.exe: PathToCompiler/../lib/gcc/arm-none-eabi/13.2.1/thumb/v7e-m+fp/hard\libg.a(libc_a-fstatr.o): in function `_fstat_r': fstatr.c:(.text._fstat_r+0x12): undefined reference to `_fstat' PathToCompiler/ld.exe: PathToCompiler/../lib/gcc/arm-none-eabi/13.2.1/thumb/v7e-m+fp/hard\libg.a(libc_a-isattyr.o): in function `_isatty_r': isattyr.c:(.text._isatty_r+0xc): undefined reference to `_isatty' PathToCompiler/ld.exe: PathToCompiler/../lib/gcc/arm-none-eabi/13.2.1/thumb/v7e-m+fp/hard\libg.a(libc_a-signalr.o): in function `_kill_r': signalr.c:(.text._kill_r+0x12): undefined reference to `_kill' PathToCompiler/ld.exe: PathToCompiler/../lib/gcc/arm-none-eabi/13.2.1/thumb/v7e-m+fp/hard\libg.a(libc_a-signalr.o): in function `_getpid_r': signalr.c:(.text._getpid_r+0x0): undefined reference to `_getpid' 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. I would really appreciate any feedback on this matter. Kind regards, Alexander Tarasov --000000000000cff911060a6f89d0--