From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13924 invoked by alias); 16 Jul 2013 18:27:36 -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 13899 invoked by uid 89); 16 Jul 2013 18:27:35 -0000 X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_40,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE,RDNS_NONE,SPF_PASS autolearn=ham version=3.3.1 Received: from Unknown (HELO mail-ie0-f176.google.com) (209.85.223.176) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Tue, 16 Jul 2013 18:27:34 +0000 Received: by mail-ie0-f176.google.com with SMTP id ar20so2334793iec.35 for ; Tue, 16 Jul 2013 11:27:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=eUpVYWBEMc9/V4sczAcHIvag8SGG+DfCq+RMM6I5zH8=; b=p5MK18ElfswiPFUV5ERNrmeeGkHXnoX0RtXLH4NLfP1zkXMgwKjtyggLU/QHL+/qv8 F3AdQBTLc/cwlQZSfNAJ2NypdNulSPNu4E45FgdH6APPVmagNaCFHaUFxCzFy6G/CBMw tWoo+ZA2T403Tm25RxfF7WGdqfOI0k28fb2+sGRiHXSxLBDSf3e0mgX80kIk76UiiX0G bluCqitGn/FwdeZd9QWMQQ0ecQO4CIon40fhBbnWX9DIKToh1Jlu+PnWa5aZyJv0LWpy cRbj9M/FIG6jzoZ5Riaeh+ZrGDZxfQxxvC79gU/OS8+ZpszbXlfDsWqxT6DGEKTdQs3G 6MJg== MIME-Version: 1.0 X-Received: by 10.43.181.136 with SMTP id pi8mr2200875icc.10.1373999247458; Tue, 16 Jul 2013 11:27:27 -0700 (PDT) Received: by 10.64.62.67 with HTTP; Tue, 16 Jul 2013 11:27:27 -0700 (PDT) In-Reply-To: <87oba2jruh.fsf@fleche.redhat.com> References: <87oba2jruh.fsf@fleche.redhat.com> Date: Tue, 16 Jul 2013 18:27:00 -0000 Message-ID: Subject: Re: [RFA] Remove target_section.bfd From: Doug Evans To: Tom Tromey Cc: gdb-patches Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQm+rI6DVeJKROICWkB4+sWdiYFRjmq3Iu21kpz8aO+gyiZlDODDg2CxpwG9PK2sB6LIAszkcp0UqtwVKTRCOvq3LM05VT+0fQNDTrTUx3Q+OwjGUs5qPvS12YUkfRxZl4abOmPnVmpCQiV0BG3qF2PCheY3ZwgO8wYFtXFFo1GMY6cemcMUH7+4NiNKnbuhjjA1fjy+fbAV4zVPveLsF/oACwegwQ== X-SW-Source: 2013-07/txt/msg00371.txt.bz2 On Tue, Jul 16, 2013 at 11:13 AM, Tom Tromey wrote: >>>>>> "Doug" == Doug Evans writes: > > Doug> While reviewing the remove-symbol-file patchset I came across > Doug> target_section.bfd. > Doug> Unnecessarily storing copies of things can lead to confusion and bugs. > Doug> This patch isn't intended to be a space savings, simply a cleanup. > > I think it is a nice cleanup. Thanks. > > Doug> We already liberally reference bfd_section.owner, so I have no problem > Doug> with adding more references here. > > The only danger is that some BFD sections do not have an owner. For > example, this is true of the absolute section, which is shared by all > BFDs, something I found out the hard way. Now, I think this is wrong of > BFD to do, but fixing it seemed hard. Righto. I've taken those into account (or at least tried to ...). [There's a FIXME in bfd for this btw. Don't know if it'll ever get implemented.] > Sometimes it is safe to use the section owner nevertheless; for instance > if you're sure that an ownerless section will never be used in this > context. > > I don't know whether this applies in this case. Perhaps not because > build_section_table uses bfd_map_over_sections, and I think that doesn't > include the ownerless sections. I looked at this. bfd_map_over_sections does this: void bfd_map_over_sections (bfd *abfd, void (*operation) (bfd *, asection *, void *), void *user_storage) { asection *sect; unsigned int i = 0; for (sect = abfd->sections; sect != NULL; i++, sect = sect->next) (*operation) (abfd, sect, user_storage); if (i != abfd->section_count) /* Debugging */ abort (); } That can't work for "global" sections (abs,com,und, etc.). And that's the only way the sections we care about here get added in gdb (AFAICT). > Doug> [Ideally bfd would provide accessor functions/macros for struct > Doug> bfd_section, but none exist at all, and I'm not inclined to add all of > Doug> them just for this patch.] > > I went through that same thought process. > > Doug> Ok to check in? > > I think it is fine; but if you could verify about bfd_map_over_sections, > that would be good. > > Tom