RE: [PATCH] Use response files from the driver in more cases

[Tamar Christina <Tamar dot Christina at arm dot com>]

Sending to list as well.

> -----Original Message-----
> From: Tamar Christina
> Sent: Thursday, June 14, 2018 11:54
> To: 'Eric Botcazou' <ebotcazou@adacore.com>; gcc-patches@gcc.gnu.org
> Subject: RE: [PATCH] Use response files from the driver in more cases
> 
> This also fixes PR86030,
> 
> Thanks Eric!
> 
> Regards,
> Tamar
> 
> > -----Original Message-----
> > From: gcc-patches-owner@gcc.gnu.org <gcc-patches-owner@gcc.gnu.org>
> On
> > Behalf Of Eric Botcazou
> > Sent: Thursday, April 26, 2018 11:52
> > To: gcc-patches@gcc.gnu.org
> > Subject: [PATCH] Use response files from the driver in more cases
> >
> > Hi,
> >
> > response files were added to the GNU toolchain to work around length
> > limits put on the command line by some OSes, typically Windows.  For
> > the compiler, the implementation is as follows: if a response file is
> > passed to the driver at link time, typically containing the list of
> > object files, then the list of object files is passed to collect2 in a
> > (second) response file and, if the linker is the GNU linker, collect2
> > then passes *all* the arguments to the linker in a (third) response file.
> >
> > So you can flawlessly pass a gigantic list of object files at link
> > time.  But this doesn't work for a gigantic list of -L switches,
> > because the driver will pass them to collect2 on the command line,
> > even if they were passed to it in a response file and even if they'll be
> passed to the GNU linker this way again.
> >
> > In other words, the ball is dropped between driver and collect2.
> > Similarly, if you pass a gigantic list of -I switches at compile time,
> > the driver will pass them to cc1 on the command line, even if they were
> passed to it in a response file.
> >
> > Therefore the attached patch makes it so that the -I switches and -L
> > switches are passed by the driver to cc1 and collect2 respectively in
> > a response file, if they were passed to it this way.  That's
> > implemented by extending the spec syntax with:
> >
> >  %@{...}
> > 	like %{...} but puts the result into a FILE and substitutes @FILE
> > 	if an @file argument has been supplied.
> >
> > and adding '@' to the LINK_COMMAND_SPEC and cpp_unique_options
> specs.
> >
> > Tested on x86-64/Linux and Windows.  We have been using this in
> > production for a couple of months.  OK for the mainline?
> >
> >
> > 2018-04-26  Eric Botcazou  <ebotcazou@adacore.com>
> >
> > 	* gcc.c: Document new %@{...} sequence.
> > 	(LINK_COMMAND_SPEC): Use it for the -L switches.
> > 	(cpp_unique_options): Use it for the -I switches.
> > 	(at_file_argbuf): New global variable.
> > 	(in_at_file): Likewise.
> > 	(alloc_args): Create at_file_argbuf.
> > 	(clear_args): Truncate at_file_argbuf.
> > 	(store_arg): If in_at_file, push the argument onto at_file_argbuf.
> > 	(open_at_file): New function.
> > 	(close_at_file): Likewise.
> > 	(create_at_file): Delete.
> > 	(do_spec_1) <'i'>: Use open_at_file/close_at_file.
> > 	<'o'>: Likewise.
> > 	<'@'>: New case.
> > 	(validate_switches_from_spec): Deal with %@{...} sequence.
> > 	(validate_switches): Likewise.
> > 	(driver::finalize): Call clear_args.
> >
> > --
> > Eric Botcazou