This is the mail archive of the
binutils@sourceware.org
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 ktietz70@googlemail.com designates 10.182.14.97 as permitted sender) smtp.mail=ktietz70@googlemail.com; dkim=pass header.i=ktietz70@googlemail.com
- References: <4F4E427E.7040603@obry.net> <4F4E557D.5040206@bitwagon.com> <4F4FD62F.1060102@obry.net> <4F505712.4090504@bitwagon.com> <4F5075EB.1000005@obry.net>
2012/3/2 Pascal Obry <pascal@obry.net>:
> John,
>
>> 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
> or
> ? @_<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?
>
> Thanks.
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
Kai