This is the mail archive of the
binutils@sourceware.cygnus.com
mailing list for the binutils project.
Re: PATCH for uninitialized junk in .dynsym
From: Franz Sirl <Franz.Sirl-kernel@lauterbach.com>
Date: Tue, 15 Jun 1999 23:46:24 +0200
>It's because of this:
>
> for (c = 0, s = output_bfd->sections; s != NULL; s = s->next)
> {
> if ((s->flags & SEC_LINKER_CREATED) != 0
> || (s->flags & SEC_ALLOC) == 0)
> {
> elf_section_data (s)->dynindx = -1;
> continue;
> }
>
> /* These symbols will have no names, so we don't need to
> fiddle with dynstr_index. */
>
> elf_section_data (s)->dynindx = c + 1;
>
> c++;
> }
>
>For some reason the elf32-ppc back-end is giving some sections dynindx
>-1. It should use zero instead; that's the convention for "no dynamic
>symbol table index" in elf_section_data, so far as I can tell. If you
>make that -1 into a zero, my guess is your problems will be over.
That didn't help :-(. And I don't think this is correct either. dynindx is
checked against -1 all over the place. Maybe this comment I found clarifies it
a bit:
/* h->dynindx may be -1 if this symbol was marked to
become local. */
And AFA I could see dynindx entries containing eg. 2 were zeroed too,
decremented by one on every call.
Actually, that is a different field in a different struct which also
happens to be named dynindx.
However, in general, I agree. I think -1, not 0, should be used as
the value to indicate that the section has no associated dynamic
symbol.
If there is a section dynindx field which is decremented such that it
becomes 0, I think there may be a problem somewhere.
Ian