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

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