Re: [PATCH] Throw error when creating an overly large gdb-index file

[Kevin Buettner <kevinb@redhat.com>]

On Tue, 12 Sep 2023 10:07:49 -0600
Tom Tromey <tom@tromey.com> wrote:

> >>>>> "Kevin" == Kevin Buettner via Gdb-patches <gdb-patches@sourceware.org> writes:  
> 
> Kevin> The header in a .gdb_index section uses 32-bit unsigned offsets to
> Kevin> refer to other areas of the section.  Thus, there is a size limit of
> Kevin> 2^32-1 which is currently unaccounted for by GDB's code for outputting
> Kevin> these sections.  
> ...
> Kevin> This commit prevents the internal error from occurring by calling error()
> Kevin> when the file size exceeds 2^32-1.  
> 
> I don't have a problem with this but... why is the section too long?
> I wonder if this is covering up some other bug, like maybe not enough
> symbol de-duplication.

The problematic shared object is named libgraph_tool_inference.so and
was created while building the python-graph-tool package on Fedora.

The shared object is 3 GiB in size and the gdb-index section for it is
4.3 GiB in size.

objdump -h shows that the largest section is .debug_str with a size
of 0x81fe181e, which is a little over 2 GiB.  The next largest is
.debug_info with a size of 0x19691516 or about 406.6 MiB.  Here is
some of the objdump -h output:

libgraph_tool_inference.so:     file format elf64-x86-64

Sections:
Idx Name          Size      VMA               LMA               File off  Algn
[...]
 28 .debug_aranges 00004d70  0000000000000000  0000000000000000  083dd180  2**0
                  CONTENTS, READONLY, DEBUGGING, OCTETS
 29 .debug_info   19691516  0000000000000000  0000000000000000  083e1ef0  2**0
                  CONTENTS, READONLY, DEBUGGING, OCTETS
 30 .debug_abbrev 0012e28b  0000000000000000  0000000000000000  21a73406  2**0
                  CONTENTS, READONLY, DEBUGGING, OCTETS
 31 .debug_line   03b842f5  0000000000000000  0000000000000000  21ba1691  2**0
                  CONTENTS, READONLY, DEBUGGING, OCTETS
 32 .debug_str    81fe181e  0000000000000000  0000000000000000  25725986  2**0
                  CONTENTS, READONLY, DEBUGGING, OCTETS
 33 .debug_line_str 0000656b  0000000000000000  0000000000000000  a77071a4  2**0
                  CONTENTS, READONLY, DEBUGGING, OCTETS
 34 .debug_loclists 090b9227  0000000000000000  0000000000000000  a770d70f  2**0
                  CONTENTS, READONLY, DEBUGGING, OCTETS
 35 .debug_rnglists 01e6cd27  0000000000000000  0000000000000000  b07c6936  2**0
                  CONTENTS, READONLY, DEBUGGING, OCTETS

I extracted .debug_str using obj_copy, replaced the \0 characters
with newlines, and then used sort and uniq on that output.  There
were no duplicate lines.  Altogether, there are 1,212,620 strings
in .debug_str.

I can't say that I fully understand the layout of the constant pool,
but it appears that all of the strings from .debug_str will end in the
latter part of it.  So, if I'm right, that alone accounts for nearly
half the size of the index file.

Kevin