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

[Simon Marchi <simark@simark.ca>]

On 2020-05-20 9:24 a.m., mlimber wrote:
> On Tue, May 19, 2020 at 10:50 AM Simon Marchi <simark@simark.ca <mailto:simark@simark.ca>> wrote:
> 
>     Are we inspecting the same library?  In the libicudata.so.52 you've sent, there
>     are three load segments:
> 
>     $ readelf -l libicudata.so.52.2 | grep LOAD
>       LOAD           0x000000 0x0000000000000000 0x0000000000000000 0x166a940 0x166a940 R   0x200000
>       LOAD           0x166af30 0x000000000186af30 0x000000000186af30 0x0000d0 0x0000d0 RW  0x200000
>       LOAD           0x166c000 0x000000000186b000 0x000000000186b000 0x000180 0x000180 RW  0x1000
> 
> 
> Ah, my bad. The lib freshly rebuilt from source has two segments, but the one I uploaded has three because I manually set the RPATH on it. (The data lib doesn't really need to be on this since it doesn't have other dependencies, but it just got caught up in a glob of all the ICU libs.)
> 
> So the additional step needed after building from source is to run `patchelf --set-rpath \$ORIGIN libicudata.so.52.2`.

Ah that explains the three segments.  Good to know, thanks!

> To reduce confusion (maybe), I have added two files to the same dropbox folder -- libicudata-unpatched.so.52.2 and libicudata-with-rpath.so.52.2. (I have left the original files I uploaded there for now.)

Thanks, it should now be trivial to reproduce with a dummy library knowing
what you said above.

> (For my own application, I have rebuilt libicu* again after running `./configure --enable-rpath=yes`, and then I get the RPATHs I need so I don't need the patchelf at all. Thus my app's problem is resolved.)
>  
> 
>     I successfully reproduced the bug using your lib.  Since there's no DWARF
>     info, it fails in init_entry_point_info.  With my lib, it fails earlier,
>     when the DWARF info is read.  Anyway, it's all variations of the same bug,
>     some code assumes that sect_index_text is set to some valid value.<
> 
> 
> I can now also repro the original bug in a rinky-dink program suitable for unit testing. Can you supply the steps to build a small program to repro the DWARF-related bug?

You mean as part of the GDB testsuite?  You can check and use this test I've made here:

  https://sourceware.org/pipermail/gdb-patches/2020-May/168769.html

It's not complete, it's missing license headers for example.

Once applied in your repo, it can be ran with:

  $ make check TESTS="gdb.base/solib-no-text.exp"

The transcript then be read at gdb/testsuite/gdb.log.

> Will both bugs be fixed by a change in one place? That is, is my second patch irrelevant because we'll ultimately fix both bugs at some higher level? If the patch is still valid, I could work to submit an updated patch and test case for my non-DWARF bug now, and then you (or you and I) can work up a test case and fix -- possibly under a new bug ticket -- for the DWARF bug.

There are two paths forward I see:

(1) make sure sect_index_text is always initialized, even if there's no .text section
(2) make GDB aware that sect_index_text could be left to -1

If we chose (1), then the fixes in your patches wouldn't be needed, as sect_index_text will
never be -1.

If we chose (2), then we should get rid of the code that invents a sect_index_text value
when there's no .text section.  The fixes in your patches would be needed (or something
equivalent), but there would be many other similar fixes needed.

I posted this RFC patch that summarizes the problem and starts to implement (2):

  https://sourceware.org/pipermail/gdb-patches/2020-May/168767.html

Simon