[RFC] PR 34481 arbitrary limit on decompressed size of .dwo files

PR34481 exposes a failure of a heuristic in bfd_section_size_insane
dealing with compressed sections.  The assumption there is that a
compressed section would not be more than ten times the total file
size.  This of course is foolish since one highly compressed section
can easily exceed ten times the total file size.  However, it mostly
worked for real object files.  The claim in pr34481 is that the limit
has been hit for .dwo files in a real C++ codebase.  I don't find that
claim unbelievable.

While we could work around the .dwo problem with the following patch,
I'm inclined to simply remove the whole "size / 10 > filesize" block.

My reasoning is that this is anti-fuzzer code.  If we allow a .dwo
hole then the anti-fuzzer code may as well not be there.  Fuzzers will
soon find the hole.

What do you all think?

	* section.c (bfd_section_size_insane): Do not attempt to limit
	.dwo section sizes.

diff --git a/bfd/section.c b/bfd/section.c
index 457486b0f89..13cb2fdeb2d 100644
--- a/bfd/section.c
+++ b/bfd/section.c
@@ -1774,11 +1774,17 @@ bfd_section_size_insane (bfd *abfd, asection *sec)
 	 "int aaa..a;" with "a" repeated enough times can result in
 	 compression ratios without limit for .debug_str, whereas such
 	 a file will usually also have the enormous symbol
-	 uncompressed in .symtab.  */
+	 uncompressed in .symtab.  PR34481: For separare dwarf info
+	 files we won't have a .symtab section so can't make any
+	 assumptions about decompressed section sizes.  */
      if (size / 10 > filesize)
        {
-	 bfd_set_error (bfd_error_bad_value);
-	 return true;
+	 size_t len = strlen (sec->name);
+	 if (len < 4 || memcmp (sec->name + len - 4, ".dwo", 4) != 0)
+	   {
+	     bfd_set_error (bfd_error_bad_value);
+	     return true;
+	   }
        }
      size = sec->compressed_size;
     }

-- 
Alan Modra