From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id VX1mNc3X8mF+VwAAWB0awg (envelope-from ) for ; Thu, 27 Jan 2022 12:35:09 -0500 Received: by simark.ca (Postfix, from userid 112) id C82A31F3B6; Thu, 27 Jan 2022 12:35:09 -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 0770E1ECEB for ; Thu, 27 Jan 2022 12:35:09 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 3C8AD385DC31 for ; Thu, 27 Jan 2022 17:35:08 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 3C8AD385DC31 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1643304908; bh=vSCDFL2Jk+3M9JEQDyXTnDERZMpPBTZhef7fYYW36YA=; h=Date:To:Subject:In-Reply-To:References:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=tFEPs/sIm7keO4IrDXZWzEeY8SunCiN07K0qq7s72tKL3B0GvcgLXWu39C386UzrH TZRdci/Q4fpPaxBuuMTrSBdFCUY+IgO/x+wuGlJThTdKgogmSfICUyWCy8b8/9Ja2A EP4S03SUxLSk01cB7sgElzRpJpwlNvxN4bP1VKD0= Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 7FBDE385DC31 for ; Thu, 27 Jan 2022 17:34:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7FBDE385DC31 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-300-FG4hVGtMN_afxpqxsO78VQ-1; Thu, 27 Jan 2022 12:34:43 -0500 X-MC-Unique: FG4hVGtMN_afxpqxsO78VQ-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id C0F9718C8C00; Thu, 27 Jan 2022 17:34:42 +0000 (UTC) Received: from f35-zws-1 (unknown [10.2.16.28]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 3F9F610A48C5; Thu, 27 Jan 2022 17:34:42 +0000 (UTC) Date: Thu, 27 Jan 2022 10:34:40 -0700 To: Tom Tromey Subject: Re: [PATCH] Fix GDB internal error by using text (instead of data) section offset Message-ID: <20220127103440.0f4ac135@f35-zws-1> In-Reply-To: <87r18u9xxm.fsf@tromey.com> References: <20220125230429.3329876-1-kevinb@redhat.com> <87r18u9xxm.fsf@tromey.com> Organization: Red Hat MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 Cc: gdb-patches@sourceware.org Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" On Wed, 26 Jan 2022 11:03:33 -0700 Tom Tromey wrote: > Kevin> #3 0x000000000097c630 in stap_probe::get_relocated_address (this=0xa1a17a0, > Kevin> objfile=0x4fa48f0) > Kevin> at gdb/stap-probe.c:1341 > > One oddity here is that get_relocated_address calls this->get_address(), > which returns m_address, which is documented as: > > /* The address where the probe is inserted, relative to > SECT_OFF_TEXT. */ > CORE_ADDR m_address; > > So using SECT_OFF_DATA here seems wrong in the first place. Agreed. (And, thanks for finding that.) > Kevin> The obvious solution is to use some other section offset instead - as > Kevin> I recall, on Linux, the section offsets (for those sections which > Kevin> exist) will all be the same. > > Is this a Linux thing or an ELF thing? I don't know. Some ABIs specify that the difference between two addresses in memory must be the same difference between those same addresses specified by the executable. The System V ABI, which most (though not all) Linux systems use, is one such ABI. Take a look at the first paragraph in the section titled "Base Address" in: http://www.sco.com/developers/gabi/2012-12-31/ch5.pheader.html The key part from that paragraph (for this discussion) is this: Because position-independent code on those platforms uses relative addressing between segments, the difference between virtual addresses in memory must match the difference between virtual addresses in the file. The differences between the virtual address of any segment in memory and the corresponding virtual address in the file is thus a single constant value for any one executable or shared object in a given process. One ABI which does not have this property is the FDPIC ABI: ftp://ftp.redhat.com/pub/redhat/gnupro/FRV/FDPIC-ABI.txt The FDPIC ABI was first created for the Fujitsu FR-V processor, but a search shows that variations have been used by some ARM and SH Linux implementations. It's useful for processors which lack an MMU. In such a system, all processes share the same address space; read-only sections such as .text can be shared among processes, but processes will each have their own copy/version of writeable sections such as .data. That being the case, the difference between addresses in .text and .data will be different for each process and will also almost certainly be different from the addresses specified by the executable. > Kevin> So, what happens if there's no .text section? > > Not probe-related but this is already a way to crash gdb: > > https://sourceware.org/bugzilla/show_bug.cgi?id=19342 > https://sourceware.org/bugzilla/show_bug.cgi?id=25678 > > ... which is why I was curious about the ELF thing. Like perhaps this > could all be made more robust somehow. I've looked at those bugs and skimmed Simon's RFC patches for dealing with the lack of a .text section in GDB. In the second patch, he introduces a function, find_bfd_section_for_address(). I think this is the right thing to do. I have some quibbles with some other things which are done in that series, but I'll try to raise those if/when Simon resurrects that series. > Your patch seems fine to me, though I don't have any idea if the dtrace > part is correct. Thanks for looking it over! I'll push it after making some revisions to the commit log. (E.g. I'll remove the part about it being a Linux thing and instead say that it's ABI dependent. I'll also add some additional info mentioning existing bugs to the part about the .text section.)