This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: DLL linking performance
Hello Pascal,
if you plan to switch to v1, this is a really bad idea in general.
Anyway, just to make point out for others, the cause for this DLL
load-delay isn't caused by the ld-code in any case. It is an issue of
the pseudo-relocation code in use of runtime. Older code has here
shown some issue about doing section-write-permission changes for each
relocation-entry instead of doing it once per relocated section.
So this issue is nothing to be solved in binutils at all. There is a
fix for this issue already present in mingw-w64's startup-code, but
this patch can't be used in mingw.org's runtime, as there some
required startup-features for hasing sections are not present .
The link-delay you are noticing for v1 is caused by section-attribute
changes for allowing write on read-only sections. There is actual no
real time-difference between v1 and v2, beside that sections getting
marked temporary writeable. The amount of relocation between both
versions is identical.
Regards,
Kai
2012/3/29 Pascal Obry <pascal@obry.net>:
>
> Hi There!
>
> Following the previous discussion with Kai about the DLL load time
> performance I have switched the linker to use the runtime pseudo reloc
> v1 circuitry.
>
> This indeed has made a big difference in loading the DLL, it is now
> almost instantaneous where it was more than 2 minutes before.
>
> But now the DLL *link* time has regressed at lot. My initial test shows
> that creating the DLL is 5 times slower.
>
> I've been analyzing this issue. Here are my findings:
>
> - There is two sorts routines un ldlang.c
>
> ?wild_sort and wild_sort_fast
>
> ?As the later imply it is fast and the former is slow.
>
> - Those sort routines get called from
>
> ?output_section_callback and output_section_callback_fast respectively.
>
> - Those routines are called from wild:
>
> ? static void
> ? wild (lang_wild_statement_type *s,
> ? ? ? ? const char *target ATTRIBUTE_UNUSED,
> ? ? ? ? lang_output_section_statement_type *output)
> ? {
> ? ? struct wildcard_list *sec;
>
> ? ? if (s->handler_data[0]
> ? ? ? ? && s->handler_data[0]->spec.sorted == by_name
> ? ? ? ? && !s->filenames_sorted)
> ? ? ? {
> ? ? ? ? lang_section_bst_type *tree;
>
> ? ? ? ? walk_wild (s, output_section_callback_fast, output);
>
> ? ? ? ? tree = s->tree;
> ? ? ? ? if (tree)
> ? ? ? ? ? {
> ? ? ? ? ? ? output_section_callback_tree_to_list (s, tree, output);
> ? ? ? ? ? ? s->tree = NULL;
> ? ? ? ? ? }
> ? ? ? }
> ? ? else
> ? ? ? walk_wild (s, output_section_callback, output);
>
>
> The fast routine is called when the data are sorted. Do you think this
> can be improved? ?Where is this sort should be done?
>
> My initial investigation seems to indicate that this sorting status is
> done on the linker script (SORT_BY_NAME), but I'm lost in the code...
>
> Any guidance will be much appreciated.
>
> Thanks.
>
> Pascal.
>
> --
>
> --|------------------------------------------------------
> --| Pascal Obry ? ? ? ? ? ? ? ? ? ? ? ? ? Team-Ada Member
> --| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
> --|------------------------------------------------------
> --| ? ?http://www.obry.net ?- ?http://v2p.fr.eu.org
> --| "The best way to travel is by means of imagination"
> --|
> --| gpg --keyserver keys.gnupg.net --recv-key F949BD3B
>
--
|? (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination