From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21424 invoked by alias); 16 Jul 2013 18:13: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 21410 invoked by uid 89); 16 Jul 2013 18:13:36 -0000 X-Spam-SWARE-Status: No, score=-5.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RDNS_NONE,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.3.1 Received: from Unknown (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Tue, 16 Jul 2013 18:13:36 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r6GIDSjc031781 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 16 Jul 2013 14:13:28 -0400 Received: from barimba (ovpn-113-128.phx2.redhat.com [10.3.113.128]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r6GIDQ2Y003915 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 16 Jul 2013 14:13:27 -0400 From: Tom Tromey To: Doug Evans Cc: gdb-patches@sourceware.org Subject: Re: [RFA] Remove target_section.bfd References: Date: Tue, 16 Jul 2013 18:13:00 -0000 In-Reply-To: (Doug Evans's message of "Mon, 15 Jul 2013 15:42:33 -0700") Message-ID: <87oba2jruh.fsf@fleche.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2013-07/txt/msg00370.txt.bz2 >>>>> "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. 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. 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