From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 537 invoked by alias); 17 Nov 2014 02:58:39 -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 523 invoked by uid 89); 17 Nov 2014 02:58:38 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 17 Nov 2014 02:58:36 +0000 Received: from svr-orw-fem-04.mgc.mentorg.com ([147.34.97.41]) by relay1.mentorg.com with esmtp id 1XqCWP-0004JJ-Oa from Yao_Qi@mentor.com ; Sun, 16 Nov 2014 18:58:33 -0800 Received: from GreenOnly (147.34.91.1) by svr-orw-fem-04.mgc.mentorg.com (147.34.97.41) with Microsoft SMTP Server id 14.3.181.6; Sun, 16 Nov 2014 18:58:33 -0800 From: Yao Qi To: Doug Evans CC: "gdb-patches@sourceware.org" Subject: Re: [PATCH 4/5] struct symtab split part 1: buildsym api cleanup References: <87h9xyha3c.fsf@codesourcery.com> Date: Mon, 17 Nov 2014 02:58:00 -0000 In-Reply-To: (Doug Evans's message of "Sun, 16 Nov 2014 18:13:36 -0800") Message-ID: <87d28mh6sl.fsf@codesourcery.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2014-11/txt/msg00391.txt.bz2 Doug Evans writes: > Whether something is "needed" can be debatable, but the intent here is > to lay the groundwork for part 2. > The static globals get moved into a struct that contains some of the > buildsym state in part 2. Oh, right, they are moved into a struct in patch 09/21. That is good. > >> I can't estimate the date that buildsym is rewritten as an object in >> c++, so in foreseeable future, the structure of buildsym still remains >> nearly unchanged, I assume. Adding static variables runes in the opposi= te >> direction, IMO. Secondly, shouldn't be buildsym a stateless processor, >> which gets objfile as input and ouputs symbols? In this way, isn't it >> nicer to have argument objfile for the api? I don't know much on >> buildsym, so I may miss something. > > I understand where you're coming from. > The way I look at it, buildsym is what it is. > It's not where I want it to be, but OTOH cleaning it up is a lower > priority than other things. > > This patch actually heads in the right direction because the API of > buildsym becomes more what I want it to be (not entirely so, just more > so). > I don't mind a few internal (local to buildsym.c) steps "backwards" in > the process. > Plus as mentioned above these static globals disappear in part 2. OK, that is fine by me. --=20 Yao (=E9=BD=90=E5=B0=A7)