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

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