This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: Make bfd.link_next field a union
- From: Alan Modra <amodra at gmail dot com>
- To: Michael Eager <eager at eagerm dot com>
- Cc: binutils at sourceware dot org
- Date: Sat, 14 Jun 2014 10:31:22 +0930
- Subject: Re: Make bfd.link_next field a union
- Authentication-results: sourceware.org; auth=none
- References: <20140613094841 dot GE7683 at bubble dot grove dot modra dot org> <539B27D5 dot 8070300 at eagerm dot com>
On Fri, Jun 13, 2014 at 09:33:25AM -0700, Michael Eager wrote:
> On 06/13/14 02:48, Alan Modra wrote:
> >This is the first of four patches aimed at fixing PR17047, a problem
> >that arose from people fussing over the linker not freeing the main
> >hash table before exit. In hindsight, I probably should have just
> >reverted the original patch and HP's more recent fix..
> >
> >The link_next field of struct bfd is currently only used to chain
> >together linker input files. This patch prepares to use the field to
> >stash the linker hash table, which is always created on the linker
> >output file.
>
> Is there a reason not to create a link_hash field, rather than
> overload/reuse link_next? I've never been fond of using unions
> to store unrelated data.
Memory is a finite resource. I've never been fond of wasting it. :)
In the case of struct bfd this isn't so important, where ld might only
have thousands of these structs in memory. It becomes rather more
important in struct bfd_section, and critical in struct
bfd_link_hash_entry. We even get complaints about the assembler using
too much memory,
eg. https://sourceware.org/bugzilla/show_bug.cgi?id=15930
--
Alan Modra
Australia Development Lab, IBM