https://sourceware.org/bugzilla/show_bug.cgi?id=32260
--- Comment #6 from Michael Matz <matz at suse dot de> --- Okay, so the errors need to be dealt with more reasonably here, it's really an extreme example: XXX bfdtab->count=1751 table->nbuckets=524288 XXX sec->size=2872400096 XXX added=1436200049 So the input section (most likely one of the .debug_str ones) is 2.8GB in size. We heavily overestimate this as potentially adding 1G strings. Obviously we can do much better than this but I was waiting for that to see testcases that exhibit that. But: this size is quickly approaching the limit that can be represented with DWARF 32bit. This is the format used universally, also on 64bit machines (DWARF-64bit has _very_ high overhead). So, while this immediate problem can be dealt with in binutils you're going to run into issues ultimately when you're adding debug string sizes like that :) (I can only imagine that this is caused by LTO not deduplicating the debug_str sections, but rather just also catting them together. At least the number from your last bug report indicate that there's very high duplication within such a single debug_str section. But there's not much that can be done about this expect reducing the size of LTO partitions or adding such deduplication within the compiler). -- You are receiving this mail because: You are on the CC list for the bug.
