https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86548
--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> --- (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 <snip file list> > > /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.
