This is the mail archive of the
mailing list for the binutils project.
Re: Another linker performance issue
- From: Kai Tietz <ktietz70 at googlemail dot com>
- To: pascal at obry dot net
- Cc: John Reiser <jreiser at bitwagon dot com>, binutils at sourceware dot org
- Date: Fri, 2 Mar 2012 09:34:32 +0100
- Subject: Re: Another linker performance issue
- Authentication-results: mr.google.com; spf=pass (google.com: domain of firstname.lastname@example.org designates 10.182.14.97 as permitted sender) email@example.com; dkim=pass firstname.lastname@example.org
- References: <4F4E427E.email@example.com> <4F4E557D.firstname.lastname@example.org> <4F4FD62F.email@example.com> <4F505712.firstname.lastname@example.org> <4F5075EB.email@example.com>
2012/3/2 Pascal Obry <firstname.lastname@example.org>:
>> Another idea, more along the lines of different global strategy:
>> Do the calls to pe_find_cdecl_alias_match() come in batches,
>> such as all the symbols needing alias resolution are checked together?
>> Then for each batch, build an array of pointers to the undefined symbols only.
>> Run bfd_link_hash_traverse() once to just count the undefined symbols;
>> allocate an array of that many pointers. ?Then run bfd_link_hash_traverse()
>> again, filling in the array. ?Now do an entire batch of alias matching
>> on the array of undefined symbols. ?Then free() the array of pointers.
> A bit complex, not sure it would work (I do not know well the internal
> of this circuitry). When an alias is found, the corresponding hash table
> is updated. So looking first for all undef then checking for alias is
> not equivalent. But maybe this does not matters here, again I do not
> know the internal.
> I've CC Kai which has implemented this part (back in Nov 2009).
> Another possible option:
> It looks like we need to traverse this hash table because we are looking
> for patterns like:
> ? _<name>@nn
> ? @_<name>@@nn
> The @nn is the annoying part of course. We could maybe create a new hash
> table, before the big loop in pe_process_import_defs, containing all
> undefined symbols with stripped @nn. Then looking for the cdecl alias
> can be done with two lookups:
> ? lookup ("_<name>")
> ? lookup ("@_<name>")
> But as I said this table is updated in add_bfd_to_link (also in
> pe-dll.c). So we probably want to add the new symbols into this new
> table at this point. Things here is that my binutils knowledge is not
> good enough to know if this is possible or not.
> Kai, John, how does that sounds?
Hmm, we could also do in the first call for bfd_link_hash_traverse
build up a table for undefined-symbol names only.
And then do the actual operations based on this candidate list only?
We avoid here at least to run over all symbols in hash_table multiple times