Re: [PATCH] Fix GDB internal error by using text (instead of data) section offset

[Simon Marchi via Gdb-patches <gdb-patches@sourceware.org>]

On 2022-01-25 18:04, Kevin Buettner via Gdb-patches wrote:
> Fedora Rawhide is now using gcc-12.0.  As part of updating to the
> gcc-12.0 package set, Rawhide is also now using a version of libgcc_s
> which lacks a .data section.  This causes gdb to fail in the following
> fashion while debugging a program (such as gdb) which uses libgcc_s:
> 
>     (top-gdb) run
>     Starting program: rawhide-master/bld/gdb/gdb
>     ...
>     objfiles.h:467: internal-error: sect_index_data not initialized
>     A problem internal to GDB has been detected,
>     further debugging may prove unreliable.
>     ...
> 
> I snipped the backtrace from the above output.  Instead, here's a
> portion of a backtrace obtained using GDB's backtrace command.
> (Obviously, in order to obtain it, I used a GDB which has been patched
> with this commit.)
> 
>     #0  internal_error (
> 	file=0xc6a508 "gdb/objfiles.h", line=467,
> 	fmt=0xc6a4e8 "sect_index_data not initialized")
> 	at gdbsupport/errors.cc:51
>     #1  0x00000000005f9651 in objfile::data_section_offset (this=0x4fa48f0)
> 	at gdb/objfiles.h:467
>     #2  0x000000000097c5f8 in relocate_address (address=0x17244, objfile=0x4fa48f0)
> 	at gdb/stap-probe.c:1333
>     #3  0x000000000097c630 in stap_probe::get_relocated_address (this=0xa1a17a0,
> 	objfile=0x4fa48f0)
> 	at gdb/stap-probe.c:1341
>     #4  0x00000000004d7025 in create_exception_master_breakpoint_probe (
> 	objfile=0x4fa48f0)
> 	at gdb/breakpoint.c:3505
>     #5  0x00000000004d7426 in create_exception_master_breakpoint ()
> 	at gdb/breakpoint.c:3575
>     #6  0x00000000004efcc1 in breakpoint_re_set ()
> 	at gdb/breakpoint.c:13407
>     #7  0x0000000000956998 in solib_add (pattern=0x0, from_tty=0, readsyms=1)
> 	at gdb/solib.c:1001
>     #8  0x00000000009576a8 in handle_solib_event ()
> 	at gdb/solib.c:1269
>     ...
> 
> The function 'relocate_address' in gdb/stap-probe.c attempts to do
> its "relocation" by using objfile->data_section_offset().  That
> method, data_section_offset() is defined as follows in objfiles.h:
> 
>   CORE_ADDR data_section_offset () const
>   {
>     return section_offsets[SECT_OFF_DATA (this)];
>   }
> 
> The internal error occurs when the SECT_OFF_DATA macro finds that the
> 'sect_index_data' field is -1:
> 
>     #define SECT_OFF_DATA(objfile) \
> 	 ((objfile->sect_index_data == -1) \
> 	  ? (internal_error (__FILE__, __LINE__, \
> 			     _("sect_index_data not initialized")), -1)	\
> 	  : objfile->sect_index_data)
> 
> The obvious solution is to use some other section offset instead - as
> I recall, on Linux, the section offsets (for those sections which
> exist) will all be the same.  SECT_OFF_TEXT / text_section_offset
> seems like a logical choice, so that's what I've used.  Actually, in
> this context, I think that text_section_offset is a better choice even
> setting aside the current difficulty.  (The breakpoint related code
> which calls it is dealing with code addresses, not data addresses.
> Therefore it's more likely to be correct even on OSes for which
> section offsets can differ.)
> 
> Searching the sources turned up one other use of data_section_offset,
> in gdb/dtrace-probe.c, so I've updated that code as well.  (I'd
> guess that one was copied from the other.)
> 
> So, what happens if there's no .text section?  If that were to
> occur, GDB would be in real trouble elsewhere since a search
> for "text_section_offset" reveals 55 uses of this method, 27
> of which are in DWARF related code.

There's a bug about this, shared lib without a .text section:

  https://sourceware.org/bugzilla/show_bug.cgi?id=25678

Simon