From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 17BB93858D38; Mon, 11 Sep 2023 15:52:40 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 17BB93858D38 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1694447560; bh=I7OzcFYejUK5yNZ8IyrbKirXSr1DVtpUU1YclWU1eGs=; h=From:To:Subject:Date:In-Reply-To:References:From; b=K8p/jFHr7dLMI/vdps4yvagoizTc56ezn+cTwSIyquV8Zsm2p2PtRQLUQVVYuU8jT o3sygb2VIKAQl/Nu27F3InisZdfMwQN2IxaFbgkQDKPlBUKlkrFtHz9Kc3e7rgaqI5 Wd/gtrbvaa5YDrD+etXNt6qqZ6fqhyhOT4/gDj4U= From: "costas.argyris at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug driver/86030] specs file processing does not create response files for input directories Date: Mon, 11 Sep 2023 15:52:39 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: driver X-Bugzilla-Version: unknown X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: costas.argyris at gmail dot com X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D86030 --- Comment #13 from Costas Argyris --- (In reply to John Soo from comment #12) > I think the general problem in that issue is that ARG_MAX is not respected > when the driver (or any subprocess) execs things on linux. I think that it > is not the same as the original issue here, though. >=20 > > I don't know if its going to be helpful to see that patch as a guide >=20 > Do you think using response files like in pex-win32.c in pex-unix.c could > help? I tried this out and it seems like this may not solve all the ARG_M= AX > problems. I really don't know because the problem might be happening even before it g= ets to the point where the new subprocess is spawned. Then, passing the comm= and line through a response file wouldn't help with anything, if the problem has already happened by that point. The Windows patch above just checks if the subprocess is about to be spawned with a command line > 32K and if that is true it simply puts it in a tempor= ary response file and calls the subprocess with @rsp as the only arg, instead of the large command line which would break it. But obviously this makes the assumption that the large command line is correct (nothing has been dropped= or otherwise messed up). Here though it seems that you are dealing with another sort of limit which = is much larger (I have seen 128K being mentioned on the GH page). If this somehow corrupts the command line, it wouldn't help if that command line we= nt into a response file because it would still be wrong. To my knowledge, Linux-based systems don't have a command line length limitation, so I can't= see how a response file approach would be useful at the point where the subproc= ess is spawned. Whether something similar can be used at an earlier point to save it from the 128K limit, whatever it is, is unknown to me.=