From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16041 invoked by alias); 17 Nov 2014 02:13:44 -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 15937 invoked by uid 89); 17 Nov 2014 02:13:42 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-yk0-f175.google.com Received: from mail-yk0-f175.google.com (HELO mail-yk0-f175.google.com) (209.85.160.175) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Mon, 17 Nov 2014 02:13:38 +0000 Received: by mail-yk0-f175.google.com with SMTP id 200so4070075ykr.34 for ; Sun, 16 Nov 2014 18:13:36 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.170.196.72 with SMTP id n69mr22497yke.41.1416190416742; Sun, 16 Nov 2014 18:13:36 -0800 (PST) Received: by 10.170.81.68 with HTTP; Sun, 16 Nov 2014 18:13:36 -0800 (PST) In-Reply-To: <87h9xyha3c.fsf@codesourcery.com> References: <87h9xyha3c.fsf@codesourcery.com> Date: Mon, 17 Nov 2014 02:13:00 -0000 Message-ID: Subject: Re: [PATCH 4/5] struct symtab split part 1: buildsym api cleanup From: Doug Evans To: Yao Qi Cc: "gdb-patches@sourceware.org" Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2014-11/txt/msg00390.txt.bz2 On Sun, Nov 16, 2014 at 5:47 PM, Yao Qi wrote: > Doug Evans writes: > >> I realize there are a lot of globals in buildsym.c, and I'm not trying >> to get rid of them in this patch set, but if one thinks of >> buildsym as an object and start_symtab as a constructor, >> then there's no need to pass the compilation directory to >> start_subfile, and there's no need to pass objfile to end_symtab*. >> This patch applies these changes. > > Hi Doug, > I am worried about adding new static variables in buildsym.c. Why do > you have to the change like this? because part 2 needs such updated api? 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. > 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 opposite > 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. Note that buildsym has a *lot* of global state. Some of it is hidden because of the EXTERN hack that is used in buildsym.h. Cleaning up buildsym is a significant cleanup project in itself, but it's also entirely local to buildsym.c and the debug info readers, whereas cleaning up the symtab data structures provides a lot more benefit. Ergo deferring cleaning up buildsym.[ch] until after struct symtab and symbol lookup is improved.