This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
RE: ld-auto-import memory bug fixing
- To: "Binutils" <binutils at sources dot redhat dot com>
- Subject: RE: ld-auto-import memory bug fixing
- From: "Ralf Habacker" <Ralf dot Habacker at freenet dot de>
- Date: Sat, 15 Sep 2001 18:48:30 +0200
> 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
>
>