This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: Versioning mess proved!!!
> Reply-To: drepper@cygnus.com (Ulrich Drepper)
> From: Ulrich Drepper <drepper@redhat.com>
> Date: 01 Oct 2000 16:57:45 -0700
> > It just means that the PLT entry will jump to location 0, but that
> > should never happen because the entry in the GOT will be zero since
> > the symbol is never defined.
>
> Right. And ld.so handles this correctly in general. So why are you
> seeing the crashes? I still have not seen any explanation.
Just to be clear, I don't have a working glibc 2.1.9* system at
present, due to tool & hardware & OS problems. I plan to spend some
time on getting one going this week, but I'm very limited on the
amount of time I can spend on glibc without getting behind on other
things...
Anyway, from the previous discussion it seems that the problem is that
the executable has a PLT entry for __gmon_start__, which is
reasonable, but that the GOT entry in libz.so is referring to this PLT
entry even when __gmon_start__ is not defined anywhere, which is wrong
(it would be OK if __gmon_start__ was defined, but it's undefined).
To fix this, the do_lookup routines in libc/elf/do-lookup.h need to be
changed so that if this condition has not triggered:
if (sym->st_value == 0 || /* No value. */
(noplt && sym->st_shndx == SHN_UNDEF))
continue;
and if:
- sym->st_shndx == SHN_UNDEF
- the reference we are processing is weak (this is optional, it's an
optimisation to save having to do two symbol lookups all the time)
- the symbol is not actually defined anywhere
then this symbol doesn't match.
--
- Geoffrey Keating <geoffk@cygnus.com>