This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
[questions] elflink.c, back-end-data
- From: msnyder at sonic dot net
- To: binutils at sourceware dot org
- Date: Wed, 25 Jul 2007 17:54:34 -0700 (PDT)
- Subject: [questions] elflink.c, back-end-data
Don't feel like I understand the issues well enough to submit a patch...
can somebody help me out here?
In _bfd_elf_fix_symbol_flags, we start with bed == NULL.
We only conditionally initialize it...
/* Backend specific symbol fixup. */
if (elf_hash_table (eif->info)->dynobj)
{
bed = get_elf_backend_data (elf_hash_table (eif->info)->dynobj);
But before long we use it as if confident it's been initialized:
(*bed->elf_backend_hide_symbol) (eif->info, h, force_local);
Then later, we eclipse it with a block-local version, which seems
to get initialized exactly the same as before (unles eif->info
or eif->info->dynobj can change...):
if (ELF_ST_VISIBILITY (h->other) != STV_DEFAULT
&& h->root.type == bfd_link_hash_undefweak)
{
const struct elf_backend_data *bed;
bed = get_elf_backend_data (elf_hash_table (eif->info)->dynobj);
(*bed->elf_backend_hide_symbol) (eif->info, h, TRUE);
}
And then a short time later, we use it again as if it had certainly
been initialized (seems to me this last use would have benefited
from the preceeding initialization, had there not been an eclipsing
block local):
(*bed->elf_backend_copy_indirect_symbol) (eif->info, weakdef, h);
Am I missing something?
Michael