This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


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

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>

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