From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 61789 invoked by alias); 17 Oct 2019 21:18:26 -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 61779 invoked by uid 89); 17 Oct 2019 21:18:25 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-7.7 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.1 spammy=long-term, longterm, judge X-HELO: userp2130.oracle.com Received: from userp2130.oracle.com (HELO userp2130.oracle.com) (156.151.31.86) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 17 Oct 2019 21:18:24 +0000 Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x9HL9Cjc117884; Thu, 17 Oct 2019 21:18:22 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=corp-2019-08-05; bh=vpooQrPR8Dw67DW/FDh9iF+L4G8mpI8P63jp/UMfU+k=; b=KTp32LOgfPUBihM8w1yS23t/4h+akXoBMb9RaMbwyFFTJ8qf0xXuni2c/3sBjmHZLFbF 6e4rINlhHK72Mj4CKyY7SmVeOeGh34mNlUbH+/DDdGo3kAM/qU+1qtSAv55Jwd+BP4w0 vmt1NL/fzgu4XcTMFz9vYD05+b3iQguY6zh/Y7jpikyfQ+rhG49Qf8zHbufCkXYG7lDC jX7IozCnKo7w+uC5a8Cqi3gqUQzRAViOogr7wlaRojBSXl1/rz3LcAkHLOxQJ7Di+XC2 evUso4kJZCsWzwkOZ1P1o636sLa3ZsgfiwJAs7IRKYM4VuIFnIvlf9Oqp0hS8VtsWMrm ig== Received: from userp3030.oracle.com (userp3030.oracle.com [156.151.31.80]) by userp2130.oracle.com with ESMTP id 2vk68v12yw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 17 Oct 2019 21:18:22 +0000 Received: from pps.filterd (userp3030.oracle.com [127.0.0.1]) by userp3030.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x9HL8IL7076904; Thu, 17 Oct 2019 21:18:22 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userp3030.oracle.com with ESMTP id 2vpvtmcj6h-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 17 Oct 2019 21:18:22 +0000 Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id x9HLIK7c022146; Thu, 17 Oct 2019 21:18:21 GMT Received: from [10.159.230.18] (/10.159.230.18) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 17 Oct 2019 21:18:20 +0000 Subject: Re: [PATCH v4 2/2] gdb: CTF support To: Tom Tromey Cc: gdb-patches@sourceware.org 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> <87v9spoj7w.fsf@tromey.com> From: Wei-min Pan Message-ID: Date: Thu, 17 Oct 2019 21:18:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <87v9spoj7w.fsf@tromey.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-SW-Source: 2019-10/txt/msg00587.txt.bz2 On 10/15/2019 1:18 PM, Tom Tromey wrote: >>>>>> 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 = { module=configure-gcc; on=all-binutils; }; >> dependencies = { module=all-binutils; on=all-libctf; }; >> dependencies = { module=all-gdb; on=all-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. Thanks for the explanation. It looks like that I will need to add gcc/Makefile.def (dependencies): all-gdb depends on all-libctf. > >>> 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. OK, will make the change. > >>> 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. OK. > >>> Instead of this function, it's more usual in gdb to use: >>> >>>        CORE_ADDR baseaddr >>>        = ANOFFSET (objfile->section_offsets, SECT_OFF_TEXT (objfile)); >>> >>> 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... ? You mean using SECT_OFF_TEXT to get the address? Will send out the diffs as soon as I'm done with these changes. Thanks again.