From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id mhCjETuC8GHiBgAAWB0awg (envelope-from ) for ; Tue, 25 Jan 2022 18:05:31 -0500 Received: by simark.ca (Postfix, from userid 112) id 37FB51F3B6; Tue, 25 Jan 2022 18:05:31 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,RDNS_DYNAMIC,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (ip-8-43-85-97.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 763741EE18 for ; Tue, 25 Jan 2022 18:05:30 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id DE472385E82D for ; Tue, 25 Jan 2022 23:05:29 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org DE472385E82D DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1643151929; bh=FbwOZOq3WYseI/L1tYhJr9NDo+THjIfba+FnShMV4nQ=; h=To:Subject:Date:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:From; b=eAamgTQ9rcgmqncGq2dFjH/HSzOctlhyWmIr0eC+nw9Xha3032cF+7/BZyfQW0npg e/mEEmJHM/rjrOzEVChVCrhnSWfUsuaV5xxaCRA87QjoSo5ngsgrTMc9255+DRc6g8 TgyQi7Uz5J5z0y1AeuzysGoFnQVPDqHvt+43AO1w= Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 42FA8385E440 for ; Tue, 25 Jan 2022 23:05:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 42FA8385E440 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-511-ENlnDmanMYeykGgL-QX97Q-1; Tue, 25 Jan 2022 18:05:08 -0500 X-MC-Unique: ENlnDmanMYeykGgL-QX97Q-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 560BA1934100 for ; Tue, 25 Jan 2022 23:05:07 +0000 (UTC) Received: from f35-1.lan (unknown [10.2.16.28]) by smtp.corp.redhat.com (Postfix) with ESMTP id C9D4C4698C; Tue, 25 Jan 2022 23:05:06 +0000 (UTC) To: gdb-patches@sourceware.org Subject: [PATCH] Fix GDB internal error by using text (instead of data) section offset Date: Tue, 25 Jan 2022 16:04:29 -0700 Message-Id: <20220125230429.3329876-1-kevinb@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="US-ASCII" X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Kevin Buettner via Gdb-patches Reply-To: Kevin Buettner Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" 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. Summary: * gdb/dtrace-probe.c (dtrace_probe::get_relocated_address): Use method text_section_offset instead of data_section_offset. * gdb/stap-probe.c (relocate_address): Likewise. --- gdb/dtrace-probe.c | 2 +- gdb/stap-probe.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/gdb/dtrace-probe.c b/gdb/dtrace-probe.c index ea4999ccebe..9aeefb6060c 100644 --- a/gdb/dtrace-probe.c +++ b/gdb/dtrace-probe.c @@ -684,7 +684,7 @@ dtrace_probe::is_enabled () const CORE_ADDR dtrace_probe::get_relocated_address (struct objfile *objfile) { - return this->get_address () + objfile->data_section_offset (); + return this->get_address () + objfile->text_section_offset (); } /* Implementation of the get_argument_count method. */ diff --git a/gdb/stap-probe.c b/gdb/stap-probe.c index 2310fdec86d..c4b24df7564 100644 --- a/gdb/stap-probe.c +++ b/gdb/stap-probe.c @@ -1330,7 +1330,7 @@ stap_probe::parse_arguments (struct gdbarch *gdbarch) static CORE_ADDR relocate_address (CORE_ADDR address, struct objfile *objfile) { - return address + objfile->data_section_offset (); + return address + objfile->text_section_offset (); } /* Implementation of the get_relocated_address method. */ -- 2.34.1