This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: Bug in >64k-section ELF handling when linking (with -r)
- From: Alan Modra <amodra at bigpond dot net dot au>
- To: Hans-Peter Nilsson <hans-peter dot nilsson at axis dot com>
- Cc: ac131313 at redhat dot com, binutils at sources dot redhat dot com
- Date: Tue, 5 Nov 2002 08:44:19 +1030
- Subject: Re: Bug in >64k-section ELF handling when linking (with -r)
- References: <3DC68ADA.7020500@redhat.com> <200211041621.gA4GLIKI005106@ignucius.axis.se>
On Mon, Nov 04, 2002 at 05:21:18PM +0100, Hans-Peter Nilsson wrote:
> > Date: Mon, 04 Nov 2002 09:57:30 -0500
> > From: Andrew Cagney <ac131313@redhat.com>
> > More seriously, is there any chance that someone will find the time to
> > improve BFD's performance?
You should have seen how long my original >64k code took in bfd.. The
section hash table improved things greatly, but the recent hash table
size reduction in response to complaints about ld's memory usage when
linking thousands of files has no doubt made it a little slower. If
someone has some spare cycles, converting bfd over to use the auto-
expanding hash table functions in libiberty/hashtab.c would be a
useful exercise. I don't see any reason to keep bfd/hash.c now that
libiberty/hashtab.c returns gracefully when out of memory.
> This is a linker problem, nothing in BFD eats time for these
> cases. Watch ldlang.c:lang_place_orphans() and the ELF linker
> emulation code called from it walk up and down lists.
Yes. Hashing the lang_output_section_statement list would make
"ld -r" go faster. Then someone would complain that gas takes too
long in subseg_set_rest. ;-)
--
Alan Modra
IBM OzLabs - Linux Technology Centre