From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 114711 invoked by alias); 15 Oct 2019 20:19:12 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 114701 invoked by uid 89); 15 Oct 2019 20:19:12 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-6.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS autolearn=ham version=3.3.1 spammy=typedefs X-HELO: gateway33.websitewelcome.com Received: from gateway33.websitewelcome.com (HELO gateway33.websitewelcome.com) (192.185.145.190) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 15 Oct 2019 20:19:10 +0000 Received: from cm16.websitewelcome.com (cm16.websitewelcome.com [100.42.49.19]) by gateway33.websitewelcome.com (Postfix) with ESMTP id 454EE4B69F01 for ; Tue, 15 Oct 2019 15:19:01 -0500 (CDT) Received: from box5379.bluehost.com ([162.241.216.53]) by cmsmtp with SMTP id KTHZiWMHdOdBHKTHZiwQRO; Tue, 15 Oct 2019 15:19:01 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tromey.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID: In-Reply-To:Date:References:Subject:Cc:To:From:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=d7taim18UYvs6MaEAs+Tp4Y8t5wqLuv4nP73/xcUvjU=; b=P1fxI68jDhmrdd9+SWXDYOmKjq vbzByIbgsu84pOpkBOEyjCs6hOkXa4LHSK4Ker40JXaYs/q0XSENdVGW6HiNVIDWbcEVk1/DCbHmd zi3zyfUCME+06FNIWNPxREg/E; Received: from 174-29-53-230.hlrn.qwest.net ([174.29.53.230]:57290 helo=murgatroyd) by box5379.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1iKTHZ-0029Wp-1d; Tue, 15 Oct 2019 14:19:01 -0600 From: Tom Tromey To: Wei-min Pan Cc: Tom Tromey , gdb-patches@sourceware.org Subject: Re: [PATCH v4 2/2] gdb: CTF support References: <1570220592-5541-1-git-send-email-weimin.pan@oracle.com> <1570220592-5541-2-git-send-email-weimin.pan@oracle.com> <87ftk1erzn.fsf@tromey.com> Date: Tue, 15 Oct 2019 20:19:00 -0000 In-Reply-To: (Wei-min Pan's message of "Thu, 10 Oct 2019 12:05:44 -0700") Message-ID: <87v9spoj7w.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-SW-Source: 2019-10/txt/msg00453.txt.bz2 >>>>> Wei-min Pan writes: >> I didn't look, did the top-level changes go in to gcc? >> The top-level configury code is canonically maintained there. > Given the following rules in Makefile.def: > dependencies =3D { module=3Dconfigure-gcc; on=3Dall-binutils; }; > dependencies =3D { module=3Dall-binutils; on=3Dall-libctf; }; > dependencies =3D { module=3Dall-gdb; on=3Dall-libctf; }; > binutils gets built before gcc does. It's not clear why making changes > into gcc is needed? Sorry, I was not clear enough. Most top-level files, like Makefile.def, are shared between gcc and gdb+binutils. However, gcc and gdb have different source repositories. In order to reduce the possibility of long-term divergence, the gcc repository was declared the canonical repository -- in general (there are exceptions) -- changes are checked in first there, then brought over to the gdb repository. My question was whether you did this. >> It's preferable to use the type-safe registry approach in new code. > This register key was not intended to manage the object with new/delete > but to be used to close file descriptors that are associated with the > ctf file/archive. It's still preferable to use the type-safe approach. You can easily introduce a new deleter object that works just as you like. In fact the code will nearly be identical -- just type-safe. >> gdb doesn't generally use typedefs like this, especially now that it's >> in C++. > It seems there are several places, e.g. aarch64-tdep.c, event-loop.c, > linespec.c, procfs.c, that do. We can drop "typedef" if you prefer. Yes, I'm afraid you can't always judge the current standard in gdb by the existing code, because the transition from C to C++ did not also involve updating every single thing -- just the important things. >> Instead of this function, it's more usual in gdb to use: >>=20 >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 CORE_ADDR baseaddr >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =3D ANOFFSET (objfile->section_offs= ets, SECT_OFF_TEXT (objfile)); >>=20 >> Maybe this function is even wrong in some situation, I'm not sure. > You suspect that bfd_get_section_by_name might return a wrong *asection? > Yes, we can use ANOFFSET, as you suggested, for the text base but still > need to get the size of the text section. I'm not sure if it can or not. Anyway it seems you can use SECT_OFF_TEXT to also get the size... ? thanks, Tom