Blame SOURCES/gdb-rhbz2042664-fix-sect_index_data-internal-error.patch

b94e32
From FEDORA_PATCHES Mon Sep 17 00:00:00 2001
b94e32
From: Kevin Buettner <kevinb@redhat.com>
b94e32
Date: Tue, 1 Feb 2022 11:32:48 -0700
b94e32
Subject: gdb-rhbz2042664-fix-sect_index_data-internal-error.patch
b94e32
b94e32
;; Backport fix which fixes internal error due to libcc_s lacking a
b94e32
;; .data section.
b94e32
b94e32
Fix GDB internal error by using text (instead of data) section offset
b94e32
b94e32
Fedora Rawhide is now using gcc-12.0.  As part of updating to the
b94e32
gcc-12.0 package set, Rawhide is also now using a version of libgcc_s
b94e32
which lacks a .data section.  This causes gdb to fail in the following
b94e32
fashion while debugging a program (such as gdb) which uses libgcc_s:
b94e32
b94e32
    (top-gdb) run
b94e32
    Starting program: rawhide-master/bld/gdb/gdb
b94e32
    ...
b94e32
    objfiles.h:467: internal-error: sect_index_data not initialized
b94e32
    A problem internal to GDB has been detected,
b94e32
    further debugging may prove unreliable.
b94e32
    ...
b94e32
b94e32
I snipped the backtrace from the above output.  Instead, here's a
b94e32
portion of a backtrace obtained using GDB's backtrace command.
b94e32
(Obviously, in order to obtain it, I used a GDB which has been patched
b94e32
with this commit.)
b94e32
b94e32
    #0  internal_error (
b94e32
	file=0xc6a508 "gdb/objfiles.h", line=467,
b94e32
	fmt=0xc6a4e8 "sect_index_data not initialized")
b94e32
	at gdbsupport/errors.cc:51
b94e32
    #1  0x00000000005f9651 in objfile::data_section_offset (this=0x4fa48f0)
b94e32
	at gdb/objfiles.h:467
b94e32
    #2  0x000000000097c5f8 in relocate_address (address=0x17244, objfile=0x4fa48f0)
b94e32
	at gdb/stap-probe.c:1333
b94e32
    #3  0x000000000097c630 in stap_probe::get_relocated_address (this=0xa1a17a0,
b94e32
	objfile=0x4fa48f0)
b94e32
	at gdb/stap-probe.c:1341
b94e32
    #4  0x00000000004d7025 in create_exception_master_breakpoint_probe (
b94e32
	objfile=0x4fa48f0)
b94e32
	at gdb/breakpoint.c:3505
b94e32
    #5  0x00000000004d7426 in create_exception_master_breakpoint ()
b94e32
	at gdb/breakpoint.c:3575
b94e32
    #6  0x00000000004efcc1 in breakpoint_re_set ()
b94e32
	at gdb/breakpoint.c:13407
b94e32
    #7  0x0000000000956998 in solib_add (pattern=0x0, from_tty=0, readsyms=1)
b94e32
	at gdb/solib.c:1001
b94e32
    #8  0x00000000009576a8 in handle_solib_event ()
b94e32
	at gdb/solib.c:1269
b94e32
    ...
b94e32
b94e32
The function 'relocate_address' in gdb/stap-probe.c attempts to do
b94e32
its "relocation" by using objfile->data_section_offset().  That
b94e32
method, data_section_offset() is defined as follows in objfiles.h:
b94e32
b94e32
  CORE_ADDR data_section_offset () const
b94e32
  {
b94e32
    return section_offsets[SECT_OFF_DATA (this)];
b94e32
  }
b94e32
b94e32
The internal error occurs when the SECT_OFF_DATA macro finds that the
b94e32
'sect_index_data' field is -1:
b94e32
b94e32
    #define SECT_OFF_DATA(objfile) \
b94e32
	 ((objfile->sect_index_data == -1) \
b94e32
	  ? (internal_error (__FILE__, __LINE__, \
b94e32
			     _("sect_index_data not initialized")), -1)	\
b94e32
	  : objfile->sect_index_data)
b94e32
b94e32
relocate_address() is obtaining the section offset in order to compute
b94e32
a relocated address.  For some ABIs, such as the System V ABI, the
b94e32
section offsets will all be the same.  So for those ABIs, it doesn't
b94e32
matter which offset is used.  However, other ABIs, such as the FDPIC
b94e32
ABI, will have different offsets for the various sections.  Thus, for
b94e32
those ABIs, it is vital that this and other relocation code use the
b94e32
correct offset.
b94e32
b94e32
In stap_probe::get_relocated_address, the address to which to add the
b94e32
offset (thus forming the relocated address) is obtained via
b94e32
this->get_address (); get_address is a getter for m_address in
b94e32
probe.h.  It's documented/defined as follows (also in probe.h):
b94e32
b94e32
  /* The address where the probe is inserted, relative to
b94e32
     SECT_OFF_TEXT.  */
b94e32
  CORE_ADDR m_address;
b94e32
b94e32
(Thanks to Tom Tromey for this observation.)
b94e32
b94e32
So, based on this, the current use of data_section_offset /
b94e32
SECT_OFF_DATA is wrong.  This relocation code should have been using
b94e32
text_section_offset / SECT_OFF_TEXT all along.  That being the
b94e32
case, I've adjusted the stap-probe.c relocation code accordingly.
b94e32
b94e32
Searching the sources turned up one other use of data_section_offset,
b94e32
in gdb/dtrace-probe.c, so I've updated that code as well.  The same
b94e32
reasoning presented above applies to this case too.
b94e32
b94e32
Summary:
b94e32
b94e32
	* gdb/dtrace-probe.c (dtrace_probe::get_relocated_address):
b94e32
	Use method text_section_offset instead of data_section_offset.
b94e32
	* gdb/stap-probe.c (relocate_address): Likewise.
b94e32
b94e32
diff --git a/gdb/dtrace-probe.c b/gdb/dtrace-probe.c
b94e32
--- a/gdb/dtrace-probe.c
b94e32
+++ b/gdb/dtrace-probe.c
b94e32
@@ -684,7 +684,7 @@ dtrace_probe::is_enabled () const
b94e32
 CORE_ADDR
b94e32
 dtrace_probe::get_relocated_address (struct objfile *objfile)
b94e32
 {
b94e32
-  return this->get_address () + objfile->data_section_offset ();
b94e32
+  return this->get_address () + objfile->text_section_offset ();
b94e32
 }
b94e32
 
b94e32
 /* Implementation of the get_argument_count method.  */
b94e32
diff --git a/gdb/stap-probe.c b/gdb/stap-probe.c
b94e32
--- a/gdb/stap-probe.c
b94e32
+++ b/gdb/stap-probe.c
b94e32
@@ -1330,7 +1330,7 @@ stap_probe::parse_arguments (struct gdbarch *gdbarch)
b94e32
 static CORE_ADDR
b94e32
 relocate_address (CORE_ADDR address, struct objfile *objfile)
b94e32
 {
b94e32
-  return address + objfile->data_section_offset ();
b94e32
+  return address + objfile->text_section_offset ();
b94e32
 }
b94e32
 
b94e32
 /* Implementation of the get_relocated_address method.  */