[PATCH] [PR 25678] gdb crashes with "internal-error: sect_index_text not initialized" when .text

Simon Marchi simark@simark.ca
Sat May 16 21:05:42 GMT 2020


On 2020-05-16 4:39 p.m., mlimber wrote:
> Thanks, with the comment you left on the issue and the attached libtestcase.so, I can repro it. However, neither of my two patches (which are basically the same anyway) fully fix it because it just bombs out later. More work required, which I'm willing to attempt.
> 
> In the name of building all tests from source, can you advise on how to create an so like libtestcase.so? I've tried to fiddle with options and version scripts to no avail. My objdump looks close but not exact, and my attempts don't repro the error.

I was also looking at that right now.

The particularity of libtestcase.so is that it has a .debug_info section, so
the DWARF debug info reader (dwarf/read.c) kicks in to read the partial symbols
(a quick pass to read the debug symbols, to gather just enough things to build
some index of what's in it) but there is no .text section.  The DWARF-reading
code assumes that there is a .text section, hence the failed assertion.

For reference, the DWARF in the file is the following:

.debug_info contents:
0x00000000: Compile Unit: length = 0x00000032 version = 0x0005 unit_type = DW_UT_compile abbr_offset = 0x0000 addr_size = 0x08 (next unit at 0x00000036)

0x0000000c: DW_TAG_compile_unit
              DW_AT_name        ("scratch.kyuu")
              DW_AT_use_UTF8    (true)

0x0000001a:   DW_TAG_variable
                DW_AT_name      ("foo")
                DW_AT_external  (0x00)
                DW_AT_type      (0x0000002e "s32")
                DW_AT_location  (DW_OP_addr 0x2250)

0x0000002e:   DW_TAG_base_type
                DW_AT_name      ("s32")
                DW_AT_encoding  (DW_ATE_signed)
                DW_AT_byte_size (0x04)

0x00000035:   NULL


I am not sure how to end up there in a "legitimate" way.  Even when I compile
a shared library with gcc with just a single global variable, a .text section is
created. So perhaps that was created with some particular options, or some other tool

In any case, GDB should be fixed, because even with some invalid / crafted input,
we shouldn't hit an assertion.

It shouldn't be difficult to craft an executable like this I suppose, just compile
a standard shared library with debug info and remove .text using objcopy?  I don't
have time to try that right now.

For the test case that will go into gdb's testsuite, it can either be that (remove
the section using objcopy) or some manually-crafted DWARF (see other examples in
testsuite/gdb.dwarf2).

Simon


More information about the Gdb-patches mailing list