From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id bbmhNUis8WEbMQAAWB0awg (envelope-from ) for ; Wed, 26 Jan 2022 15:17:12 -0500 Received: by simark.ca (Postfix, from userid 112) id C8B4E1F3B6; Wed, 26 Jan 2022 15:17:12 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-3.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,NICE_REPLY_A,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.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 2BA401EE18 for ; Wed, 26 Jan 2022 15:17:12 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 7D18A3858D39 for ; Wed, 26 Jan 2022 20:17:11 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 7D18A3858D39 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1643228231; bh=GuHKcVnOW6+cAta7bRbBBk0JLrKcnEnFBko3jscv4vM=; h=Date:Subject:To:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=VhjGZ9P8V0+VMDAChvtiFP+qMhznmh/PHQG7z8Mk5uTRIf79cjFcILHly0QvG142A EtXERZvJ42i3v1IACJDpXEVqITwYHXpv+bbfqF+7VJ7ZVIeKoFSMaE2Pmc5VVZaEum pHZKA6j/506DP47LlurmKFvvmZC8b4+7WCY/81ps= Received: from smtp.polymtl.ca (smtp.polymtl.ca [132.207.4.11]) by sourceware.org (Postfix) with ESMTPS id 2C5973858D20 for ; Wed, 26 Jan 2022 20:16:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2C5973858D20 Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id 20QKGkci015611 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 26 Jan 2022 15:16:51 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 20QKGkci015611 Received: from [10.0.0.11] (192-222-157-6.qc.cable.ebox.net [192.222.157.6]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 413AC1EE18; Wed, 26 Jan 2022 15:16:46 -0500 (EST) Message-ID: <60d1b552-944f-686c-72f0-7df8762cef8d@polymtl.ca> Date: Wed, 26 Jan 2022 15:16:45 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: [PATCH] Fix GDB internal error by using text (instead of data) section offset Content-Language: en-US To: Kevin Buettner , gdb-patches@sourceware.org References: <20220125230429.3329876-1-kevinb@redhat.com> In-Reply-To: <20220125230429.3329876-1-kevinb@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Wed, 26 Jan 2022 20:16:46 +0000 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: Simon Marchi via Gdb-patches Reply-To: Simon Marchi Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" 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