On Thu, 20 Feb 2020, Bernd Edlinger wrote:
> Hi,
>
> this is the remaining issue that happens when -flto and -save-temps
> is used together, it leaks several files in /tmp.
>
> I try to give more background to how these temp files are
> created, and in all likelihood the leaking of these
> files is wanted, and certainly very helpful for debugging
> lto issues, that's for sure. It is just not helpful
> that they need to be looked up in the /tmp folder, even
> if you want to debug something with lto.
>
> The short story is...
>
> They are created here:
>
> if (parallel)
> {
> makefile = make_temp_file (".mk");
> mstream = fopen (makefile, "w");
>
> and here:
>
> /* Note: we assume argv contains at least one element; this is
> checked above. */
>
> response_file = make_temp_file ("");
>
> f = fopen (response_file, "w");
>
> And in a few other places as well, it depends a bit
> if -o is used or not (i.e. linker_output != NULL or not).
>
> and not removed here:
>
>
> if (response_file && !save_temps)
> {
> unlink (response_file);
> response_file = NULL;
> }
>
> and here:
>
> do_wait (new_argv[0], pex);
> maybe_unlink (makefile);
> makefile = NULL;
>
>
> the code with the response_file is executed both in
> lto-wrapper and collect2, but in collect2 only when
> if is invoked from lto-wrapper, triggered by the @file
> argument list.
>
> Therefore I figured that the best possible
> solution is just let lto-wrapper create a temp-file
> for those problem cases, and use TMPDIR to have
> all make_temp_file that follow use that to folder to
> place the those response files and other stuff in
> there.
>
>
> So that is what I split out from the previous patch,
> which focused on collect2.
>
>
> Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
> Is it OK for trunk?
I don't think this is an improvement. The files still
will be (correctly) retained and now in addition to that
there's temporary directories piling up?
A better improvement would be to selectively decide
which files might not be needed to be preserved and/or
give them names in the build directory in more cases.
Richard.
>
> Thanks
> Bernd.
>
>
--
Richard Biener <rguent...@suse.de>
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)
