Re: [PATCH 1/2] libstdc++: Add --enable-pure-stdio-libstdcxx option

[Jonathan Wakely <jwakely@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 2865 bytes --]

On 07/12/20 12:36 -0800, Keith Packard wrote:
>Jonathan Wakely <jwakely@redhat.com> 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.)




[-- Attachment #2: patch.txt --]
[-- Type: text/x-patch, Size: 1628 bytes --]

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