[Bug lto/86548] GCC could tmp file /tmp/ccDxn2Yd.ltrans0.ltrans.o could be based on the compiled file name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86548 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Martin Liška --- Fixed.
[Bug lto/86548] GCC could tmp file /tmp/ccDxn2Yd.ltrans0.ltrans.o could be based on the compiled file name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86548 --- Comment #8 from Martin Liška --- Author: marxin Date: Thu Jul 26 12:13:14 2018 New Revision: 262999 URL: https://gcc.gnu.org/viewcvs?rev=262999&root=gcc&view=rev Log: Add linker_output as prefix for LTO temps (PR lto/86548). 2018-07-26 Martin Liska PR lto/86548 * lto-wrapper.c: Add linker_output as prefix for ltrans_output_file. 2018-07-26 Martin Liska PR lto/86548 * libiberty.h (make_temp_file_with_prefix): New function. 2018-07-26 Martin Liska PR lto/86548 * make-temp-file.c (TEMP_FILE): Remove leading 'cc'. (make_temp_file): Call make_temp_file_with_prefix with first argument set to NULL. (make_temp_file_with_prefix): Support also prefix. Modified: trunk/gcc/ChangeLog trunk/gcc/lto-wrapper.c trunk/include/ChangeLog trunk/include/libiberty.h trunk/libiberty/ChangeLog trunk/libiberty/make-temp-file.c
[Bug lto/86548] GCC could tmp file /tmp/ccDxn2Yd.ltrans0.ltrans.o could be based on the compiled file name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86548 --- Comment #7 from Martin Liška --- Patch was sent to mailing list: https://gcc.gnu.org/ml/gcc-patches/2018-07/msg01612.html
[Bug lto/86548] GCC could tmp file /tmp/ccDxn2Yd.ltrans0.ltrans.o could be based on the compiled file name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86548 --- Comment #6 from Jonny Grant --- (In reply to Richard Biener from comment #3) > (In reply to Jonny Grant from comment #0) > > It's pretty hard to work out which file this o file comes from. Could it > > include the first file name in the tmp path to make it clearer where it came > > from? > > > > Currently: > > /tmp/ccDxn2Yd.ltrans0.ltrans.o > > > > Expected: > > /tmp/main.cpp.ccDxn2Yd.ltrans0.ltrans.o > > > > Example below of what I see > > > > jonny@asus:~/domains$ make > > g++-8 -std=c++11 -g -ggdb -pthread -O0 -Werror -Wextra -Wshadow > > -Wformat-nonliteral -Wall -Wnonnull -Wpedantic -fstack-protector-strong > > -Wdiv-by-zero -Wsign-conversion -Wnull-dereference -flto > > -Wno-nonnull-compare -o proc main.cpp test_whois.cpp > > /usr/bin/x86_64-linux-gnu-ld: Dwarf Error: Offset (1678049557) greater than > > or equal to .debug_str size (5846). > > ^^^ > > oh, and as for this DWARF section sizes are limited to 2GB as offsets are > 32bits only. The above offset is 0x64050115 which _may_ indicate an > overflow (and .debug_str is unlikely to be just 5846 bytes in size). > > If you do not use LTO how large are your .debug_* sections in the final > executable? Hi Richard, Thank you for your replies. I'll reply on the bug #86469
[Bug lto/86548] GCC could tmp file /tmp/ccDxn2Yd.ltrans0.ltrans.o could be based on the compiled file name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86548 --- Comment #5 from Richard Biener --- (In reply to Richard Biener from comment #3) > (In reply to Jonny Grant from comment #0) > > It's pretty hard to work out which file this o file comes from. Could it > > include the first file name in the tmp path to make it clearer where it came > > from? > > > > Currently: > > /tmp/ccDxn2Yd.ltrans0.ltrans.o > > > > Expected: > > /tmp/main.cpp.ccDxn2Yd.ltrans0.ltrans.o > > > > Example below of what I see > > > > jonny@asus:~/domains$ make > > g++-8 -std=c++11 -g -ggdb -pthread -O0 -Werror -Wextra -Wshadow > > -Wformat-nonliteral -Wall -Wnonnull -Wpedantic -fstack-protector-strong > > -Wdiv-by-zero -Wsign-conversion -Wnull-dereference -flto > > -Wno-nonnull-compare -o proc main.cpp test_whois.cpp > > /usr/bin/x86_64-linux-gnu-ld: Dwarf Error: Offset (1678049557) greater than > > or equal to .debug_str size (5846). > > ^^^ > > oh, and as for this DWARF section sizes are limited to 2GB as offsets are > 32bits only. The above offset is 0x64050115 which _may_ indicate an > overflow (and .debug_str is unlikely to be just 5846 bytes in size). > > If you do not use LTO how large are your .debug_* sections in the final > executable? Esp. .debug_str can get quite huge with LTO today since we partially link all early debug and that partial link doesn't perform string merging. If you do -save-temps -v you should see a /tmp/ccXYZdebugobjtem file that should contain the large .debug_str section. Maybe you can paste the output of readelf -S on that file here? .debug_str is concatenated from all .o file .gnu.debuglto_.debug.str sections, so first compiling with -c and then summing up those section sizes can reveal whether we really have an overflow here.
[Bug lto/86548] GCC could tmp file /tmp/ccDxn2Yd.ltrans0.ltrans.o could be based on the compiled file name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86548 --- Comment #4 from Jonny Grant --- (In reply to Martin Liška from comment #2) > I can implement that. Great! Happy to pay bounty of $100 to you or GNU. Could I ask for as short as possible tmp file name so output not too long. eg could abreviate "ltrans" to be "lt" to save our terminal output ;-) eg /tmp/main.cpp.ccDxn2Yd.lt0.lt.o
[Bug lto/86548] GCC could tmp file /tmp/ccDxn2Yd.ltrans0.ltrans.o could be based on the compiled file name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86548 --- Comment #3 from Richard Biener --- (In reply to Jonny Grant from comment #0) > It's pretty hard to work out which file this o file comes from. Could it > include the first file name in the tmp path to make it clearer where it came > from? > > Currently: > /tmp/ccDxn2Yd.ltrans0.ltrans.o > > Expected: > /tmp/main.cpp.ccDxn2Yd.ltrans0.ltrans.o > > Example below of what I see > > jonny@asus:~/domains$ make > g++-8 -std=c++11 -g -ggdb -pthread -O0 -Werror -Wextra -Wshadow > -Wformat-nonliteral -Wall -Wnonnull -Wpedantic -fstack-protector-strong > -Wdiv-by-zero -Wsign-conversion -Wnull-dereference -flto > -Wno-nonnull-compare -o proc main.cpp test_whois.cpp > /usr/bin/x86_64-linux-gnu-ld: Dwarf Error: Offset (1678049557) greater than > or equal to .debug_str size (5846). ^^^ oh, and as for this DWARF section sizes are limited to 2GB as offsets are 32bits only. The above offset is 0x64050115 which _may_ indicate an overflow (and .debug_str is unlikely to be just 5846 bytes in size). If you do not use LTO how large are your .debug_* sections in the final executable?
[Bug lto/86548] GCC could tmp file /tmp/ccDxn2Yd.ltrans0.ltrans.o could be based on the compiled file name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86548 Martin Liška changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org --- Comment #2 from Martin Liška --- I can implement that.
[Bug lto/86548] GCC could tmp file /tmp/ccDxn2Yd.ltrans0.ltrans.o could be based on the compiled file name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86548 Richard Biener changed: What|Removed |Added Keywords||lto Status|UNCONFIRMED |NEW Last reconfirmed||2018-07-17 CC||marxin at gcc dot gnu.org Component|c++ |lto Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- In other places we use the output filename (linker output name) for this when using -save-temps. But yes, all ltrans stuff ends up in /tmp ...
