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

[Simon Marchi <simark@simark.ca>]

On 2020-05-18 5:11 p.m., mlimber wrote:
> I built libicudata.so.52.2 from source (no customizations; just needed the particular version my version of Qt was looking for, and I modified the RPATH of the three ICU .so's to look in $ORIGIN for their dependencies since I distribute my app with its dependencies). Note that someone else also reported the libicudata.so being the culprit and that I have not yet triggered the error with the libicudata.so in a smaller program.
> 
> The build steps for the offending .so right out of the build log for the library is:
> ```
> gcc -D_REENTRANT  -DU_HAVE_ELF_H=1 -DU_HAVE_ATOMIC=1  -DU_ATTRIBUTE_DEPRECATED= -O2 -std=c99 -Wall -pedantic -Wshadow -Wpointer-arith -Wmissing-prototypes -Wwrite-strings   -c -I../common -I../common -DPIC -fPIC -o ./out/tmp/icudt52l_dat.o ./out/tmp/icudt52l_dat.s
> gcc -O2 -std=c99 -Wall -pedantic -Wshadow -Wpointer-arith -Wmissing-prototypes -Wwrite-strings   -static-libstdc++  -shared -Wl,-Bsymbolic -nodefaultlibs -nostdlib -o ../lib/libicudata.so.52.2 ./out/tmp/icudt52l_dat.o -Wl,-soname -Wl,libicudata.so.52  -Wl,-Bsymbolic
> ```
> 
> The assembly file is generated at build-time and is of the form:
> ```
> .globl icudt52_dat
> .section .note.GNU-stack,"",%progbits
> .section .rodata
> .balign 16
> .type icudt52_dat,%object
> icudt52_dat:
> 
> .long 0x27DA0080,0x14,0x020000,0x446E6D43,1,3,0x706F4320,0x67697279,0x28207468,0x32202943,0x2C333130,0x746E4920,0x616E7265,0x6E6F6974,0x42206C61,0x6E697375,0x20737365,0x6863614D,0x73656E69,0x726F4320,0x61726F70,0x6E6F6974,0x646E6120,0x68746F20,0x2E737265,0x6C6C4120,0x67695220,0x20737468,0x65736552,0x64657672,0x202E,0
> .long 0x0C64,0x6324,0x018370,0x6334,0x01B900,0x6347,0x01B9A0,0x635A,0x01BA00,0x636B,0x01C580,0x637F,0x01C5E0,0x638F,0x01CF90,0x63A2,0x01CFF0,0x63B2,0x020420,0x63C5,0x020480,0x63D5,0x026160,0x63E9,0x0261C0,0x63FC,0x026220,0x640F,0x026280,0x6422,0x0262E0,0x6435
> [snip lots more data]
> ```
> I can make the binary of the .so available to you if desired (it is 23 MB).

If you can upload it somewhere, it wouldn't hurt.  I'm also trying to build
icu from the same release.

Right now I'm trying to make some sense of the `symfile_find_segment_sections`
function here:

https://github.com/bminor/binutils-gdb/blob/966dc1a27c55ccb298cb8c7c41c9cc2985cc321a/gdb/symfile.c#L3701

I suspect it's buggy, and "hides" the bug when using some shared libraries
(including the one I build myself) which would explain why we see it with some
libraries that are missing a .text section and not others.

When called for a library that has no .text section, if that library has two
segments (which is the case of the library I created), then that function will
initialize objfile::sect_index_text to 0 (or some other value that insinuates
that there is a .text section).  That sounds wrong to me: if the library has no
.text section, it would be better to leave sect_index_text to -1, and make sure
the rest of the code can cope with that.  If I remove `symfile_find_segment_sections`
completely, sect_index_text stays -1 for my library and I hit the assertion.  I then
believe that the correct way forward would be to update the dwarf2/read.c code to
deal with a .text section not present.  Normally, if there's no .text section, there
should be no debug info describing code stuff (only data stuff), so it shouldn't be
necessary to use sect_index_text.

The library attached to the bug (libtestcase.so) has the particularity of having
3 segments.  So `symfile_find_segment_sections` is skipped, sect_index_text stays
-1, and we see the assertion.

So I'm curious, in your libicudata.so library, how many segments there are.  That
can be checked with:

  $ readelf -l libicudata.so.52 | grep LOAD

If the libicudata.so.52 is really the problematic one, I'm a bit surprised that you
don't always see the problem when debugging a program that uses it.

Simon