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


> Hi Ralf,
>
> > 1. I recognized, that for any input file read by bfd one symboltab
> > is present, not one for any section. Isn't it 	?
>
> Err, I do not think that this is quite right.  For example dynamic
> sections have their own symbol table, seperate from the normal symbol
> table.
How are dynamic sections accessed ?
>
> > The best thing, I think, is in using the bfd structure to hold a
> > pointer to the cached canonicalized bfd symbol table. I've 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 would suggest keeping the number of changes to BFD small and so
> using usrdata to point to your own structure.

In the meantime I have already found such a structure in ldlang.h

typedef struct lang_input_statement_struct {
<snip>
  /* Symbol table of the file.  */
  asymbol **asymbols;
  unsigned int symbol_count;
<snip>

This structure is already used by ldmain.c: warning_callback() and ldcref.c:
check_refs(),
so I have created a new function ld_get_symbol_table(bfd *abfd, int *nsyms) and
added this
to the below mentioned functions:

ldmain.c: warning_callback()

ldcref.c: check_refs()

ldmisc:c  vfinfo()

pe-dll.c:
  process_def_file ()

  pe_walk_relocs_of_symbol()

  generate_reloc()

ei386pe.c: pe_find_data_imports ()

The result was saving about 16 MB of RAM on compiling a c++ lib with about 10000
input bfd (kde2libs/kdeui)

>
> > 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 ?
>
> Unless you want to modify large parts of bfd then I would say yes.
>
I have looked into the listed functions and with my current knowledge of ld it
seems to me, but I'm not 100% shure.

After applying this I have compiled some kde libs and apps (with the
auto-import-options) without errors,
but I don't know if there are be some side effects. Is a test suite for ld
available to verify this ?

> Cheers
>         Nick
>
>


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