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 [216.205.24.124]) by sourceware.org (Postfix) with ESMTP id E11143857C69 for ; Wed, 9 Dec 2020 10:17:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org E11143857C69 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-151-ZBKR9h6IPDe9oKyAkpdjwQ-1; Wed, 09 Dec 2020 05:17:14 -0500 X-MC-Unique: ZBKR9h6IPDe9oKyAkpdjwQ-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id A0184CE678; Wed, 9 Dec 2020 10:17:01 +0000 (UTC) Received: from localhost (unknown [10.33.36.115]) by smtp.corp.redhat.com (Postfix) with ESMTP id 17CF160BF1; Wed, 9 Dec 2020 10:17:00 +0000 (UTC) Date: Wed, 9 Dec 2020 10:17:00 +0000 From: Jonathan Wakely To: Keith Packard Cc: libstdc++@gcc.gnu.org, gcc-patches@gcc.gnu.org Subject: Re: [PATCH 1/2] libstdc++: Add --enable-pure-stdio-libstdcxx option Message-ID: <20201209101700.GS2309743@redhat.com> References: <20201207183927.3275768-1-keithp@keithp.com> <20201207183927.3275768-2-keithp@keithp.com> <20201207185501.GA4100714@redhat.com> <87y2i98ib2.fsf@keithp.com> MIME-Version: 1.0 In-Reply-To: <87y2i98ib2.fsf@keithp.com> X-Clacks-Overhead: GNU Terry Pratchett X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: multipart/mixed; boundary="Pz0BBB9QxoYXlT+x" Content-Disposition: inline X-Spam-Status: No, score=-14.0 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libstdc++@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libstdc++ mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2020 10:17:20 -0000 --Pz0BBB9QxoYXlT+x Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline On 07/12/20 12:36 -0800, Keith Packard wrote: >Jonathan Wakely writes: > >> GCC changelog files are autogenerated now, so patches should not touch >> them. Just include the ChangeLog entry in the Git commit log (which >> will usually end up being quoted in the patch and/or the email body of >> the mail to gcc-patches). > >Awesome. > >> I think the right way to do this (or at least, the way that was >> intended when basic_file_stdio.cc was added) is to provide a new file >> and change GLIBCXX_ENABLE_CSTDIO in acinclude.m4 to use that new file. >> >> The two biggest downsides of that are that it duplicates a lot of the >> file (because the diffs for your changes are small) and that the >> correct name for your new file is already taken! > >I can definitely see a reason to use a separate file when implementing >the basic_file interface on top of something other than stdio, but >this patch doesn't do that -- it only changes the interaction between >basic_file and stdio in a few places. > >I think it makes the best long-term sense to leave everything in >basic_file_stdio.cc and avoid having the two implementations diverge in >the future. > >> However, it's rather late in the GCC 11 process to make a change like >> that (even though it's really just renaming some files). Would you be >> OK waiting until after GCC 11 is released (in 4-5 months) to do it >> "properly"? Is this blocking something that would require doing it >> sooner? > >This patch enables the use of C++ with picolibc, a libc designed for 32- >and 64- bit embedded systems. > >Right now, I'm working on getting picolibc support integrated into >Zephyr, which uses toolchains build by crosstool-ng. I've gotten >picolibc support merged to crosstool-ng, but the Zephyr developers are >interested in having a single toolchain support three different libc >implementations (newlib, newlib-nano and picolibc), but that's blocked >on having C++ support available in all three libraries. > >So, you're at the bottom of my current dependency graph :-) > >I don't particularly need this released in gcc, but I would like to >get patches reviewed and the general approach agreed on so that I can >feel more confident in preparing patches to be applied to gcc in >crosstool-ng itself. > >Once that's done, I'll also be able to release new Debian packages of >GCC for embedded ARM and RISC-V and have those include suitable patches >so that we can support embedded C++ development there too. OK. In principle, changes to avoid using the POSIX APIs are definitely fine. I would like to combine your new configure switch with the existing --enable-cstdio one though. How about the attached change for acinclude.m4 which would allow you to do --enable-cstdio=stdio_pure? (It also adds "stdio_posix" as a more accurate alternative spelling of the current "stdio" option.) --Pz0BBB9QxoYXlT+x Content-Type: text/x-patch; charset=us-ascii Content-Disposition: attachment; filename="patch.txt" diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4 index fcd9ea3d23a..535ffd8682f 100644 --- a/libstdc++-v3/acinclude.m4 +++ b/libstdc++-v3/acinclude.m4 @@ -2862,24 +2862,30 @@ AC_DEFUN([GLIBCXX_ENABLE_PARALLEL], [ dnl -dnl Check for which I/O library to use: stdio, or something specific. +dnl Check for which I/O library to use: stdio and POSIX, or pure stdio. dnl -dnl Default is stdio. +dnl Default is stdio_posix. dnl AC_DEFUN([GLIBCXX_ENABLE_CSTDIO], [ AC_MSG_CHECKING([for underlying I/O to use]) GLIBCXX_ENABLE(cstdio,stdio,[[[=PACKAGE]]], - [use target-specific I/O package], [permit stdio]) + [use target-specific I/O package], [permit stdio|stdio_posix|stdio_pure]) - # Now that libio has been removed, you can have any color you want as long - # as it's black. This is one big no-op until other packages are added, but - # showing the framework never hurts. + # The only available I/O model is based on stdio, via basic_file_stdio. + # The default "stdio" is actually "stdio + POSIX" because it uses fdopen(3) + # to get a file descriptor and then uses read(3) and write(3) with it. + # The "stdio_pure" model doesn't use fdopen and only uses FILE* for I/O. case ${enable_cstdio} in - stdio) + stdio*) CSTDIO_H=config/io/c_io_stdio.h BASIC_FILE_H=config/io/basic_file_stdio.h BASIC_FILE_CC=config/io/basic_file_stdio.cc AC_MSG_RESULT(stdio) + + if test "x$enable_cstdio" = "xstdio_pure" ; then + AC_DEFINE(_GLIBCXX_USE_PURE_STDIO, 1, + [Define to restrict std::__basic_file<> to stdio APIs.]) + fi ;; esac --Pz0BBB9QxoYXlT+x--