This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [LTO] PATCH: Fix WPA errors seen with make -j2


Ollie Wild wrote:
On Fri, Oct 24, 2008 at 6:39 AM, Simon Baldwin <simonb@google.com> wrote:
There's also make_temp_file(). Before this version of the patch I
investigated using that to just throw a bunch more cc*.mumble files into
/tmp (or wherever else gcc is using for temporary files). I settled on the
simpler one, though, as using make_temp_files() was a bit more invasive
overall (and may push an API change onto lto_elf_open_file).

I think you guys are all overlooking one important point. These files are going to exist in /tmp at the same time and potentially consume a *very* large amount of space. Many user's /tmp directories may have size restrictions which make this unfeasible.

I would suggest creating these somewhere inside the build directory,
where we know the user is expecting to consume a lot of space.

That adds a bit of extra awkwardness.


Libiberty's make_temp_file() only understands, for uniqueness purposes, temporary files residing in $TMPDIR and cousins. Its underlying mkstemps() would do the job, but this is currently not exposed as part of the libiberty API, so at minimum there'd be a change to libiberty to go that route.

Libc's mktemp(3), mkstemp(3), tempnam(3), and tmpnam(3) are all marked do-not-use in their respective man pages. tmpfile(3) is $TMPDIR-biased and returns a FILE*, but not the associated name.

It seems that the straightforward routes are to either add a new libiberty function to generate a unique (to the build directory) temporary filename without prefixing with $TMPDIR first, or go back to just adding the process ID to the filename as first suggested. Any other ideas here?

Finally, there's currently no intermediate file deletion (which is of course less of a problem with bogus* filenames, as subsequent builds overwrite early ones so they don't accumulate!). Deleting them is easy, but retaining them for debugging needs to be flagged somehow. Passing either collect2's -debug flag or -save-temps through the ltrans driver, make, gcc, and back into lto1 for -fwpa, quickly becomes convoluted. At the moment, I'm contemplating a simple check on an environment variable for whether to retain these files for debugging or delete them. Seem reasonable?

Thanks.

--
Google UK Limited | Registered Office: Belgrave House, 76 Buckingham
Palace Road, London SW1W 9TQ | Registered in England Number: 3977902


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]