[Bug driver/111527] New: COLLECT_GCC_OPTIONS option hits single-variable limits too early

[Bug driver/111527] New: COLLECT_GCC_OPTIONS option hits single-variable limits too early

[slyfox at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111527

            Bug ID: 111527
           Summary: COLLECT_GCC_OPTIONS option hits single-variable limits
                    too early
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: driver
          Assignee: unassigned at gcc dot gnu.org
          Reporter: slyfox at gcc dot gnu.org
  Target Milestone: ---

Tl;DR:

  linux allows you to pass up to 2MB of command line arguments to the tools
limiting each individual option to 128KB. Unfortunately `gcc` collects all the
options into a single `COLLECT_GCC_OPTIONS` variable and hits the smaller 128KB
limit.

  This causes periodic problems for distributions that install each individual
package into a separate directory. One of them is `NixOS`.

  Could `gcc` be amended not to use single limiting `COLLECT_GCC_OPTIONS`
variable and use, say, direct arguments to pass options around? Or even use
response file if it hits `-E2BIG`?

  Fake reproducer: 2 huge variables that programs normally accept, but not
`gcc`:

  $ big_100k_var=$(printf "%0*d" 100000 0)

  # this works: 200KB of options for `printf` external command
  $ $(which printf) "%s %s" $big_100k_var $big_100k_var >/dev/null; echo $?
  0

  # this fails: 200KB of options for `gcc`, fails in `cc1`
  $ touch a.c; gcc -c a.c -DA=$big_100k_var -DB=$big_100k_var
  gcc: fatal error: cannot execute 'cc1': execv: Argument list too long
  compilation terminated.

  Thanks!

MOre words

In `nixpkgs` repository each package gets installed into it's own unique
directory:

    /nix/store/hash1-foo/include/foo.h
    /nix/store/hash2-bar/include/bar.h
    ...

If any of those encounter `__FILE__` macros in static inline functions they
usually embed full path to header files into final binaries as is.

I wanted to remap all those paths into form that does not contain hashes:

   
-fmacro-prefix-map=/nix/store/hash1-foo/include/foo.h=/nix/store/00000000-foo/include/foo.h
   
-fmacro-prefix-map=/nix/store/hash2-bar/include/bar.h=/nix/store/00000000-bar/include/bar.h
    ...

When I got to packages that use about ~100 include directories I started
getting  errors from `cc1`:

```
Command line: `gcc -m64 -mcx16 $remap_options
/build/qemu-8.1.0/build/meson-private/tmpbyikv8nc/testfile.c \
  -o /build/qemu-8.1.0/build/meson-private/tmpbyikv8nc/output.exe
-D_FILE_OFFSET_BITS=64 \
  -O0 -Wl,--start-group -laio -Wl,--end-group -Wl,--allow-shlib-undefined` -> 1
stderr:
gcc: fatal error: cannot execute 'cc1': execv: Argument list too long
compilation terminated.
```

The limit felt too low and I found the `COLLECT_GCC_OPTIONS` variable.

[Bug driver/111527] COLLECT_GCC_OPTIONS option hits single-variable limits too early

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111527

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Hm, but the COLLECT_GCC_OPTIONS variable is only used for communicating between
the driver and the linker, the options therein are individually passed to the
program execved?

You are maybe looking for the -f*-map options to take a file as input
containing multiple mappings?

[Bug driver/111527] COLLECT_GCC_OPTIONS option hits single-variable limits too early

[slyfox at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111527

--- Comment #2 from Sergei Trofimovich <slyfox at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #1)
> Hm, but the COLLECT_GCC_OPTIONS variable is only used for communicating
> between the driver and the linker, the options therein are individually
> passed to the program execved?

AFAIU the driver sets `COLLECT_GCC_OPTIONS` variable and never unsets it. As a
result it affects all the `exevce() calls. Be it `cc1`, `as` or anything else
regardless of the fact if it uses the variable or not. `cc1` is probably the
first casualty.

As a simplistic example here we break `ls` with too large environment file:

    $ COLLECT_GCC_OPTIONS=$(printf "%0*d" 200000 0) ls
    -bash: /run/current-system/sw/bin/ls: Argument list too long

> You are maybe looking for the -f*-map options to take a file as input
> containing multiple mappings?

`NixOS` is also occasionally hottong the same limit by passing too many include
an library paths:

    -I/nix/store/hash1-foo/include
    -I/nix/store/hash2-bar/include
    ...
    -L/nix/store/hash1-foo/lib
    -L/nix/store/hash2-bar/lib
    ...
    -Wl,-rpath,/nix/store/hash1-foo/lib
    -Wl,-rpath,/nix/store/hash2-bar/lib

I wonder if we could solve all of these limitations here by at least avoiding
`COLLECT_GCC_OPTIONS`.

But otherwise if generic fix is too invasive change then passing a mapping file
should do as well.

What would be an acceptable for of the file? A new option, like?
    -fmacro-prefix-map-file=./foo
with entries of exactly the same form
    $ cat foo
    /nix/store/hash1-foo=/nix/store/00000000-foo
    /nix/store/hash2-bar=/nix/store/00000000-bar
    ...

Or maybe reuse existing -fmacro-prefix-map= and use response-style file input?
Like -fmacro-prefix-map=@./foo.

clang would probably need the same handling if we were to extend the driver.

[Bug driver/111527] COLLECT_GCC_OPTIONS option hits single-variable limits too early

[deepadeepthi98 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111527

Deepthi H <deepadeepthi98 at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |deepadeepthi98 at gmail dot com

--- Comment #3 from Deepthi H <deepadeepthi98 at gmail dot com> ---
I have been investigating this issue further. Hence checking the source code
and debugging the gcc sources. However, I wasn't able to find where the
COLLECT_GCC_OPTION has been set to 128kb

I couldn't find it being set in gcc. Can you please let us know how can we
increase the limit of collect options?

[Bug driver/111527] COLLECT_GCC_OPTIONS option hits single-variable limits too early

[deepadeepthi98 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111527

--- Comment #4 from Deepthi H <deepadeepthi98 at gmail dot com> ---
I have been investigating this issue further. Hence checking the source code
and debugging the gcc sources. However, I wasn't able to find where the
COLLECT_GCC_OPTION has been set to 128kb

I couldn't find it being set in gcc. Can you please let us know how can we
increase the limit of collect options?

[Bug driver/111527] COLLECT_GCC_OPTIONS option hits single-variable limits too early

[slyfox at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111527

--- Comment #5 from Sergei Trofimovich <slyfox at gcc dot gnu.org> ---
(In reply to Deepthi H from comment #4)
> I have been investigating this issue further. Hence checking the source code
> and debugging the gcc sources. However, I wasn't able to find where the
> COLLECT_GCC_OPTION has been set to 128kb
> 
> I couldn't find it being set in gcc. Can you please let us know how can we
> increase the limit of collect options?

The 128K limit against a single environment variable is a linux kernel
limitation set by this define in include/uapi/linux/binfmts.h:

    #define MAX_ARG_STRLEN (PAGE_SIZE * 32)

https://trofi.github.io/posts/299-maximum-argument-count-on-linux-and-in-gcc.html
has more words on that.

[Bug driver/111527] COLLECT_GCC_OPTIONS option hits single-variable limits too early

[deepadeepthi98 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111527

--- Comment #6 from Deepthi H <deepadeepthi98 at gmail dot com> ---
Created attachment 58107
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58107&action=edit
workaround for gcc driver long argument list error

[Bug driver/111527] COLLECT_GCC_OPTIONS option hits single-variable limits too early

[deepadeepthi98 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111527

--- Comment #7 from Deepthi H <deepadeepthi98 at gmail dot com> ---
We've a solution for this issue.

When gcc/g++ is called using the @response-file.rsp syntax, gcc should forward
the argument to its subprocesses. Previously the files were expanded which
could lead to excessively long argument lists and 'cc1: execv: Argument list
too long' errors.

In particular, CMake and Ninja tend to create a lot of '-isystem' include
directories, requiring allowing the forwarding in spec files by using %@{i*}.

In xputenv method, If the ENV variable size greater then 128kb then we split
the ENV variable(i.e COLLECT_GCC_OPTIONS) where each chunk will be 128kb in
length.

GCC passes the entire command line, including expanded @rsp-files to the
collect2 in environment variable COLLECT_GCC_OPTIONS. This can exceed the build
environment's kernel's environment variable length limit. In this workaround,
environment variables longer than 128kb are split into multiple variables and
stitched back together in collect2.

The patch is attached here. 
And, the patch output of the example code given in 'Description' as below:

=======
sunild@BFT-LPT-I-051:~$ $GCC_PATH/gcc -c a.c -DA=$big_100k_var
-DB=$big_100k_var -v
Using built-in specs.
COLLECT_GCC=/home/sunild/GCC_Driver/bin/home/sunild/GCC_Driver/build/bin/gcc
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/home/sunild/GCC_Driver/build
--enable-languages=c --disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.1 20240426 (experimental) (GCC)
COLLECT_GCC_OPTIONS_0='-c' '-D'
'A=00000000000000000000000000000000000000000000000000000000
COLLECT_GCC_OPTIONS_1=000000000000000000000000000000000000000000000000000000000000000000000
COLLECT_GCC_OPTIONS_COUNT=2

=======

Let us know your comments on this solution. Such a solution is acceptable to
change the gcc driver?

[Bug driver/111527] COLLECT_GCC_OPTIONS option hits single-variable limits too early

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111527

--- Comment #8 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Deepthi H from comment #7)
>  
> Let us know your comments on this solution. Such a solution is acceptable to
> change the gcc driver?

Seems better to place the arguments in a file instead and just pass around that
file name instead of passing all arguments via an env variable.

[Bug driver/111527] COLLECT_GCC_OPTIONS option hits single-variable limits too early

[deepadeepthi98 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111527

--- Comment #9 from Deepthi H <deepadeepthi98 at gmail dot com> ---
Created attachment 58212
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58212&action=edit
With_Files_Workaround_for_GCC_ArgumentLongList

[Bug driver/111527] COLLECT_GCC_OPTIONS option hits single-variable limits too early

[deepadeepthi98 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111527

--- Comment #10 from Deepthi H <deepadeepthi98 at gmail dot com> ---
As suggested, We've updated the patch to place the arguments in a file instead
of passing it from an env variable.
When the COLLECT_GCC_OPTIONS is <128kb the env variable is used and when the
size >128kb arguments will be moved to a file.

In Collect2: We copy back the contents of the arguments from file into a buffer
and pass it on to the Linker.

See the updated patch :
With_Files_Workaround_for_GCC_driver_LongArgumentList.patch

The output of the example program in descripton section as below: 
=============================================================
$big_100k_var=$(printf "%0*d" 100000 0)
$<<GCC_PATH_With_Fix>>/gcc -c a.c -DA=$big_100k_var -DB=$big_100k_var -v
Using built-in specs.
COLLECT_GCC=/home/sunild/Gcc_Driver_with_FILE/install/home/Gcc_Driver_with_FILE/build/bin/gcc
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/home/Gcc_Driver_with_FILE/build
--enable-languages=c --disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 15.0.0 20240513 (experimental) (GCC)
/home/Gcc_Driver_with_FILE/install/home/Gcc_Driver_with_FILE/build/bin/../libexec/gcc/x86_64-pc-linux-gnu/15.0.0/cc1
-quiet -v -imultiarch x86_64-linux-gnu -iprefix
/home/Gcc_Driver_with_FILE/install/home/Gcc_Driver_with_FILE/build/bin/../lib/gcc/x86_64-pc-linux-gnu/15.0.0/
-D A=00000000000000000000000000000000000000000000000
....
....
<<trimmed output>>
....
....
0 -D B=000000000000000000000000000...
....
....
<<trimmed output>>
....
....
00000000000 a.c -quiet -dumpbase a.c -dumpbase-ext .c -mtune=generic
-march=x86-64 -version -o /tmp/cc7Ox5mH.s
=============================================================

Please let us know this solution is ok.

[Bug driver/111527] COLLECT_GCC_OPTIONS option hits single-variable limits too early

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111527

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2024-05-18
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW

--- Comment #11 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Note using "/tmp/rsp.txt" is not acceptable at all since there might be a few
linking happening on the machine. You should use make_at_file (which will make
either a tmp file which will be deleted at the end compiling or an .args.N file
which can be looked at if used with -save-temps) instead from gcc.cc and then
pass the filename to collect2 as "@filename" and then inside collect2 expand as
needed.

[Bug driver/111527] COLLECT_GCC_OPTIONS option hits single-variable limits too early

[deepadeepthi98 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111527

--- Comment #12 from Deepthi H <deepadeepthi98 at gmail dot com> ---
As suggested, we made the necessary changes and updated the patch to gcc
community. Please find the link below:
https://gcc.gnu.org/pipermail/gcc-patches/2024-July/656073.html

[Bug driver/111527] COLLECT_GCC_OPTIONS option hits single-variable limits too early

[deepadeepthi98 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111527

--- Comment #13 from Deepthi H <deepadeepthi98 at gmail dot com> ---
Test logs ::

:~/$ big_100k_var=$(printf "%0*d" 100000 0)

Host gcc binary (Without fix)::

:~/$ gcc a.c -DA=$big_100k_var -DB=$big_100k_var
gcc: fatal error: cannot execute ‘/usr/lib/gcc/x86_64-linux-gnu/11/cc1’: execv:
Argument list too long
compilation terminated.


Gcc binary with fix included ::
:~$ ./gcc a.c -DA=$big_100k_var -DB=$big_100k_var
:~$ ls a.o*
a.out

Test Logs::

                === gcc Summary ===

# of expected passes            8
# of expected failures          2

PASS: gcc.dg/longcmd/pr111527-1.c (test for excess errors)
PASS: gcc.dg/longcmd/pr111527-1.c execution test  

PASS: gcc.dg/longcmd/pr111527-2.c (test for excess errors)
PASS: gcc.dg/longcmd/pr111527-2.c execution test
PASS: gcc.dg/longcmd/pr111527-2.c output-exists ./pr111527-2.exe

PASS: gcc.dg/longcmd/pr111527-3.c (test for excess errors)
PASS: gcc.dg/longcmd/pr111527-3.c execution test
PASS: gcc.dg/longcmd/pr111527-3.c output-exists ./pr111527-3.exe

XFAIL: *-*-*
xgcc: fatal error: cannot execute 'cc1': posix_spawn: Argument list too long^M
compilation terminated.^M
compiler exited with status 1
XFAIL: gcc.dg/longcmd/pr111527-4.c (test for excess errors)

[Bug driver/111527] COLLECT_GCC_OPTIONS option hits single-variable limits too early

[randy.macleod at windriver dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111527

--- Comment #14 from Randy MacLeod <randy.macleod at windriver dot com> ---
There is a revised patch that has finally been tested after someone's vacation.
Deepthi, please share the link to the patch on this list once it's sent.

[Bug driver/111527] COLLECT_GCC_OPTIONS option hits single-variable limits too early

[deepadeepthi98 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111527

--- Comment #15 from Deepthi H <deepadeepthi98 at gmail dot com> ---
We fixed the testcase that linaro complained about the previous patch. 
We tested thoroughly the updated patch in-house and sent the patch to gcc
mailing list. Please find the link below:
https://gcc.gnu.org/pipermail/gcc-patches/2024-August/660223.html

[Bug driver/111527] COLLECT_GCC_OPTIONS option hits single-variable limits too early

[sunil.dora1988 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111527

Sunil Dora <sunil.dora1988 at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sunil.dora1988 at gmail dot com

--- Comment #16 from Sunil Dora <sunil.dora1988 at gmail dot com> ---
Dear GCC Team,

I would like to request an update on the status of my patch. 
If there are any issues or additional changes required, please let me know. 
I am happy to make any necessary adjustments to ensure the patch meets the
community's standards.

Summary of the Patch:
********************
Description: 
[GCC should not limit the length of command line passed to collect2 if the size
of the command line range in between 128kb to 2MB]

Key Changes: 
[ If the command line argument in the range of 128kb to 2mb, gcc should copy
arguments in a file and use FILE_GCC_OPTIONS to communicate and compile fine.]

Reason for Change: 
[Currently, Gcc uses the COLLECT_GCC_OPTIONS environment variable to transfer
the expanded command line to collect2. If the command line size is greater than
128KB: It fails saying : "Argument list too long"]

Thank you for your time and assistance. I look forward to any feedback you may
have.

PATCH File Link:
***************
https://gcc.gnu.org/pipermail/gcc-patches/2024-August/660223.html

Best regards,
Sunil Dora

[Bug driver/111527] COLLECT_GCC_OPTIONS option hits single-variable limits too early

[sjames at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111527

--- Comment #17 from Sam James <sjames at gcc dot gnu.org> ---
See https://gcc.gnu.org/contribute.html#patches ("Pinging patches, Getting
patches applied"). You can ping patches on the ML by just saying "ping" or
similar in response to the original message, after 2 weeks or so.

Sometimes it can be helpful if it's a niche component to CC the relevant
maintainers of $COMPONENT, after looking at MAINTAINERS, but do so with care.

[Bug driver/111527] COLLECT_GCC_OPTIONS option hits single-variable limits too early

[sunil.dora1988 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111527

--- Comment #18 from Sunil Dora <sunil.dora1988 at gmail dot com> ---
Thank you, Sam.

I have addressed the feedback and submitted the revised V2 patch. You can
review it at the following link:

https://gcc.gnu.org/pipermail/gcc-patches/2024-August/661842.html

[Bug driver/111527] COLLECT_GCC_OPTIONS option hits single-variable limits too early

[sunil.dora1988 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111527

--- Comment #19 from Sunil Dora <sunil.dora1988 at gmail dot com> ---
Created attachment 59064
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59064&action=edit
Details of issue summary, response file logs and proposed solution

[Bug driver/111527] COLLECT_GCC_OPTIONS option hits single-variable limits too early

[sunil.dora1988 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111527

--- Comment #20 from Sunil Dora <sunil.dora1988 at gmail dot com> ---
Hi Andrew,

Initially, I thought to address long command line options (when exceeding
128KB) without disrupting the existing GCC driver behavior. 

As you suggested, I implemented changes to use the response file format (@file)
within the set_collect_gcc_options function and ensured that this was passed
through COLLECT_GCC_OPTIONS.
However, these changes have introduced a side effect: they impact the behavior
of the -save-temps switch by generating additional .args.N files. As a result,
some existing test cases, including the one reported by the Linaro team, are
now failing.

Could you please advise on how we should proceed? Specifically, should we
adjust the test cases to accommodate the impact on the -save-temps switch, or
is there an alternative approach you would recommend? Your guidance on how to
address these issues while implementing the response file approach would be
greatly appreciated.

[Bug driver/111527] COLLECT_GCC_OPTIONS option hits single-variable limits too early

[sunil.dora1988 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111527

--- Comment #21 from Sunil Dora <sunil.dora1988 at gmail dot com> ---
From Andrew:


Sounds like the testcase needs to be changed. If you were not saving
around the file that was used for COLLECT_GCC_OPTIONS in the previous
patches (with -save-temps), then that was broken.
Or is the issue the name of the file is not based on the aux dump file
but based on something else?  That is what is the file that is kept
around for -save-temps ?

Thanks,
Andrew

[Sunil] I will continue to work on Andrew's suggestion. Thank you for your
input!