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!!!


At 01:24 04.10.00, Ulrich Drepper wrote:
>Franz Sirl <Franz.Sirl-kernel@lauterbach.com> writes:
>
> > $ LD_LIBRARY_PATH=./22/ LD_BIND_NOW=1 ./tA
> > 0x10010818
> > Segmentation fault (core dumped)
>
>I'm seeing the same result on x86 but this does not mean we have to
>handle this.  Weak symbol handling is misdesigned (or better: cannot
>actually be done correctly).  User-level programs should not use it
>and since we haven't seen any complain about this there are hopefully
>no users.

Did you see this with adding -fpic to the last compile command (on the 
first testcase foo was already relocated statically)? Because with -fpic 
it's the _exactly same_ problem I see with __gmon_start__. The testcase 
describes how the situation has changed on PPC between glibc-2.1.3 
executable/crt*/sharedlib setup vs __gmon_start__, namely an executable 
that is compiled on a glibc-2.2 system against a 2.1.3-style shared lib. 
Now the shared lib is recompiled to 2.2 style and the executable breaks.

The problem is that under 2.1.3 each shared lib and each executable 
contains a weak dummy __gmon_start__ function, pulled in with the crt*.o 
files. Now the executable is recompiled under 2.2, but still against a 
2.1.3 style shared lib. Somehow this makes the shared linker behave wrong 
then if the 2.1.3 style shared lib is replaced with a 2.2 style shared lib, 
the GLOB_DAT entry gets relocated, even though neither the executable nor 
the shared lib contain any definition of foo.

When loading the testcase into the debugger, the relocation entry is still 
0. But as soon as I actually run the testcase, the entry gets relocated and 
thus the test against !=0 always succeeds and foo gets called, even though 
there is no code for it (some space got reserved though for foo, but it is 
zero).

I start to believe this is a problem in the static linker not correctly 
setting some flags and values in the executable. Eg. on alpha st_value for 
foo is 0 in the executable, but on PPC it seems to be set to the size of 
foo in the 2.1.3 shared lib (0x1c/28). Also st_other is set to 0x80 on 
alpha, but 0 on PPC.

>The only thing which is important now is getting the startup code
>working.  Forget about this test case.

As I said above, IMHO the testcase exactly resembles the situation we face 
with the changed handling of __gmon_start__.

>Also: what has this problem actually to do with the zlib library?  I
>cannot find a use of weak in the zlib sources.  So the problem with it
>is also the startup code?

zlib is just the smallest real-life testcase we have so far, and what's 
going wrong is the handling of __gmon_start__, the executable always calls 
__gmon_start__, even though there is no more definition of it when started 
with a 2.2 style shared lib, which has been compiled with 2.2 startup files.

Franz.


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