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

[mlimber]

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.

M

On Fri, May 15, 2020 at 2:33 PM mlimber <mlimber@gmail.com> wrote:

> Hrm. I've tried a number of smaller programs to repro this, including the
> steps in the comments using the attachment or building my own, X11, OpenGL,
> libicu tests, and also sample Qt apps that link `libicudata.so`. Alas, I
> cannot recreate it in small-ish form.
>
> I've tried various combinations of these on Ubuntu 14.04 x64 building with
> gcc 4.9 and also Ubuntu 20.04 x64 with gcc 9.3.
>
> I can reliably repro it with my full-scale Qt app, but I can't submit
> that. When I debug gdb itself, I see where it is going awry in my app --
> with libicudata.so.52, which is a weird data-only library.
>
> I have updated the patch to be a little cleaner by handling this case
> earlier rather than at the end since that the problem is apparently that we
> have a non-zero starting address but no text section. Thus, I think it fits
> better like:
>
> --- a/gdb/symfile.c
> +++ b/gdb/symfile.c
> @@ -829,7 +829,8 @@ struct symfile_segment_data *
>        ei->entry_point_p = 1;
>      }
>    else if (bfd_get_file_flags (objfile->obfd) & DYNAMIC
> -   && bfd_get_start_address (objfile->obfd) != 0)
> +   && bfd_get_start_address (objfile->obfd) != 0
> +   && objfile->sect_index_text != -1)
>      {
>        /* Some shared libraries may have entry points set and be
> runnable.  There's no clear way to indicate this, so just check
> for values other than zero.  */
>       ei->entry_point = bfd_get_start_address (objfile->obfd);
>       ei->entry_point_p = 1;
>      }
>    else
>      {
> -      /* Examination of non-executable.o files.  Short-circuit this
> stuff.  */
> +      /* Examination of non-executable.o files or shared library with
> +         no text segment.  Short-circuit this stuff.  */
>        ei->entry_point_p = 0;
>      }
>
> The issue description also says that one needs >2 segments, but I don't
> see where that comes in yet. Perhaps that's what I'm missing in trying to
> repro it?
>
> I'm willing to keep trying. Can you recommend any way for me to repro the
> issue in a small test case?
>
> Thanks!
>
> M
>
> On Thu, May 14, 2020 at 3:28 PM Simon Marchi <simark@simark.ca> wrote:
>
>> On 2020-05-14 3:12 p.m., mlimber via Gdb-patches wrote:
>> > Unfortunately, the simpler repro cases I have tried don't trigger the
>> > failure, e.g.,
>> >
>> > // main.c
>> > extern int g_global_var;
>> > int main()
>> >   {
>> >     return g_global_var;
>> >   }
>> >
>> > // libglobal.c
>> > extern int g_global_var;
>> > int g_global_var = 42;
>> >
>> > I build it like:
>> >
>> > gcc -shared -nostdlib -fPIC -o libglobal.so libglobal.c
>> > gcc -o main main.c -lglobal -L. -Wl,--rpath,\$ORIGIN
>> >
>> > Running it in GDB works fine. Seems like something more is required.
>> >
>> > Even following the repro steps listed in the first comment or linking
>> > against libicudata.so in a simple program like above work fine for me.
>> >
>> > My more complicated, real-world use case does consistently repro the bug
>> > before the patch but does not after.
>> >
>> > More digging required. Suggestions welcome!
>> >
>> > M
>>
>> If you can make a reproducer that uses Qt, that's a good start.  Then we
>> can
>> track down what's special about this use case, and try to make a
>> reproducer
>> that doesn't use it.
>>
>> But for the record, I was able to reproduce the crash using the
>> instructions
>> in the bug.  Keith (comment 3) did too.
>>
>> Simon
>>
>