This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Another linker performance issue

2012/3/2 Pascal Obry <>:
> 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]