From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31742 invoked by alias); 10 Oct 2019 19:05:41 -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 31734 invoked by uid 89); 10 Oct 2019 19:05:40 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-15.2 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_0,GIT_PATCH_1,SPF_HELO_PASS autolearn=ham version=3.3.1 spammy= X-HELO: aserp2120.oracle.com Received: from aserp2120.oracle.com (HELO aserp2120.oracle.com) (141.146.126.78) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 10 Oct 2019 19:05:39 +0000 Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x9AInfj7072961; Thu, 10 Oct 2019 19:05:38 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=SB2EBV1QfIgcsEr7/FaHmu/t7KIRJEFzzbOz/eiox1Y=; b=Pjo7x2EZmpjlLeVLTkvlc/9pBB5EM0+T8rP2HudJ77eVApUXVj7bKkZRJnpE3FPw0NaJ KmYCBdFQvCkL2LznHWAg7O7xKVgMorJ5IJwd4s6I1dh/lrE7cfxaRHWLnMZCEOgEFrKz 84QMq6Eirlr9hT8x5IZbWaVKsdsYbsxKcsCclmRIo9ckpiiUzgXFrqGvaXUIm1VH8GIu IG45kp5am3CCCBfqedgJ91E6KgleQQ3bggOI1RXrP8awFXOI7h/0zx0pPSjczwrtfLxM wHc0VZsShmvfDT/VVH3OBMIcIGgGKxrGUVu1pOurtUcHZSkpyAxvf8ClPI3SKUsX1h7J Mg== Received: from userp3020.oracle.com (userp3020.oracle.com [156.151.31.79]) by aserp2120.oracle.com with ESMTP id 2vek4qw4xw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 10 Oct 2019 19:05:37 +0000 Received: from pps.filterd (userp3020.oracle.com [127.0.0.1]) by userp3020.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x9AImvCg089314; Thu, 10 Oct 2019 19:05:37 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userp3020.oracle.com with ESMTP id 2vj9qsuw0c-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 10 Oct 2019 19:05:36 +0000 Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id x9AJ5Ziq022613; Thu, 10 Oct 2019 19:05:36 GMT Received: from [10.159.225.58] (/10.159.225.58) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 10 Oct 2019 12:05:35 -0700 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> From: Wei-min Pan Message-ID: Date: Thu, 10 Oct 2019 19:05: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: <87ftk1erzn.fsf@tromey.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-SW-Source: 2019-10/txt/msg00286.txt.bz2 On 10/9/2019 10:41 AM, Tom Tromey wrote: >>>>>> Weimin Pan writes: > >> This patch adds the CTF (Compact Ansi-C Type Format) support in gdb. > > This went in by mistake, but since it was on the road to going in > anyway, I guess we'll just live with that.  We all make mistakes, but at > the same time, please do try to be careful. I'm sure that the lesson learned from all this will be remembered and the mistake won't be repeated. > >> diff --git a/Makefile.def b/Makefile.def >> index 6f5e881..311feb9 100644 > [...] > > 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? > >> +static const struct objfile_data *ctf_file_key; > > 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. >>> +typedef struct ctf_context >> +{ >> +  ctf_file_t *fp; >> +  struct objfile *of; >> +  struct buildsym_compunit *builder; >> +} ctf_context_t; > > 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. > >> +/* Get text segment base for OBJFILE, TSIZE contains the segment size.  */ >> + >> +static CORE_ADDR >> +get_objfile_text_range (struct objfile *of, int *tsize) >> +{ >> +  CORE_ADDR text_base; >> +  bfd *abfd = of->obfd; >> +  const asection *codes; >> + >> +  codes = bfd_get_section_by_name (abfd, ".text"); > > 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.