This is the mail archive of the binutils@sources.redhat.com 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]

RE: ld-auto-import memory bug fixing


>
> I have looked into the relating stuff and found, that for any section of any
> input bfd a symbol tab is allocated.
> For this I have two questions:
>
> 1. I recognized, that for any input file read by bfd one symboltab is present,
> not one for any section. Isn't it 	?
> If this is true (and it seems so, because I have applied a patch and have
> compiled about 20 dll's with it), I have
> found a way to solve this problem.  (moving symboltable allocating in
> the first
> for loop)
>
> (This patch contains some debugging stuff, which needs other files
> patch. It is
> for dicsussion only)
>
> pe-dll.c
>    for (b = info->input_bfds; b; b = b->link_next)
>      {
> -      arelent **relocs;
> -      int relsize, nrelocs, i;
> +         int nsyms, symsize;
> +         asymbol **symbols;
>
> +         symsize = bfd_get_symtab_upper_bound (b);
> +         symbols = (asymbol **) xmalloc (symsize);
> +         nsyms = bfd_canonicalize_symtab (b, symbols);
> +
>        for (s = b->sections; s; s = s->next)
>         {
> -         asymbol **symbols;
> -         int nsyms, symsize;
> +      int relsize, nrelocs, i;
> +           arelent **relocs;
>           int flags = bfd_get_section_flags (b, s);
>
>           /* Skip discarded linkonce sections */
>           if (flags & SEC_LINK_ONCE
> -             && s->output_section == bfd_abs_section_ptr)
> +                     && s->output_section == bfd_abs_section_ptr) {
> +                               if (pe_dll_extra_pe_debug & 4)
> +                                       printf("\t section->name=%s -->
> ignored\n",s->name);
>             continue;
> -
> +                       }
>           current_sec=s;
>
> -         symsize = bfd_get_symtab_upper_bound (b);
> -         symbols = (asymbol **) xmalloc (symsize);
> -         nsyms = bfd_canonicalize_symtab (b, symbols);
> -
>           relsize = bfd_get_reloc_upper_bound (b, s);
>           relocs = (arelent **) xmalloc ((size_t) relsize);
>           nrelocs = bfd_canonicalize_reloc (b, s, relocs, symbols);
>
> 2. Relating to this bug, I have found that allocating symbol tables is done
> several times in ld. Using a symbol
>    cache would be save much memory.
>
> 			pe_find_data_imports ()
> 	ei386pe.c:         symsize = bfd_get_symtab_upper_bound (b);
>
> 			gld_i386pe_after_open ()
> 	ei386pe.c:         symsize = bfd_get_symtab_upper_bound (is->the_bfd);
>
> 			pe_walk_relocs_of_symbol (info, name, cb)
> 	pe-dll.c:         symsize = bfd_get_symtab_upper_bound (b);
>
> 			process_def_file (abfd, info)
> 	pe-dll.c:         symsize = bfd_get_symtab_upper_bound (b);
>
> 			generate_reloc (abfd, info)
> 	pe-dll.c:         symsize = bfd_get_symtab_upper_bound (b);
>
> 	ldcref.c:      symsize = bfd_get_symtab_upper_bound (abfd);
> 	ldmain.c:         symsize = bfd_get_symtab_upper_bound (abfd);
> 	ldmisc.c:                   symsize = bfd_get_symtab_upper_bound (abfd);
>
> What about creating a symbol cache list in ld using pointer to loaded symbols
> tables or by extending bfd structure with a pointer to a "symbol cache entry",
> which can be filled by client code and later reused by other code.
> Extending bfd would minimize the overhead to handle this cache, so I
> think this would be the best way.

Currently I have implemented a symbol cache table for holding bfd symbol tables
(referenced by pe-dll.c functions) in a simple vector . It works, but needs too
much lookup time because of the number of contained entries (compiling kdelibs
produces about 10.000 bfd's). Using this cache saves additional about 15 MB on
compiling kdeui with regards to the previous fix, which saves about 100 MB).

The alternatives are to implement a better lookup function like binary search or
use another strategy.

Te best thing, I think, is in using the bfd structure to hold a pointer to the
cached canonicalized bfd symbol table.
Ive found a bfd struct member called "usrdata" which was used by ldlang.c, which
seems to hold ld specific data relating to bfd's in a lang_input_statement_type
struct

My question currently is which the better is, adding members to this struct or
to add additional members to the bfd struct.


> I have to say one limitation to this. Such cached symbol tables should not be
> manipulated. They should be used only read only. Is this real ?
>
> Regards Ralf
>
>


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