public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Geoff Keating <geoffk@ozemail.com.au>
To: rth@twiddle.net
Cc: hjl@lucon.org, drepper@cygnus.com, ian@cygnus.com,
	binutils@sourceware.cygnus.com,
	libc-hacker@sourceware.cygnus.com, jgg@ualberta.ca
Subject: Re: A glibc dynamic linker or gld bug?
Date: Tue, 06 Jul 1999 01:01:00 -0000	[thread overview]
Message-ID: <199907060800.SAA01123@geoffk.wattle.id.au> (raw)
In-Reply-To: <19990705204814.A26423@twiddle.net>

> Mailing-List: contact libc-hacker-help@sourceware.cygnus.com; run by ezmlm
> Date: Mon, 5 Jul 1999 20:48:14 -0700
> From: Richard Henderson <rth@twiddle.net>
> Cc: hjl@lucon.org, drepper@cygnus.com, ian@cygnus.com,
>         binutils@sourceware.cygnus.com, libc-hacker@sourceware.cygnus.com,
>         jgg@ualberta.ca
> 
> On Mon, Jul 05, 1999 at 02:55:51PM +1000, Geoff Keating wrote:
> > There is no way that a weak symbol defined in an
> > executable can be overriden by anything else, so there should be no
> > relocations referring to it.
> 
> In the weak model prefered by glibc and SGI, sure there is.
> A strong symbol defined in a shared library will override 
> the weak symbol in the main executable.
> 
> But this is not the model Sun prefers, since it kills their
> cute lazy loading scheme.

I now understand the bug report.  The problem on powerpc would look
similar if ld was trying to implement that weak symbol model.

However, clearly it is not, at least not for data objects.  The
problem is that, for instance in the executable given, it is necessary
to emit a R_*_COPY reloc for any data objects which are defined weak.

The current linker (well, the 981225 snapshot), however, only does
this for data objects that go in the .dyn.bss pseudo-section, at least on
i386, sparc, and ppc; that is, data objects that are not defined in
the application.

Note that in this case, ld.so is responsible for determining where the
'true' data for the data object is, and using it for the R_*_COPY
reloc.  It is also responsible for not doing the copy if it turned out
that there is never a strong definition of the symbol.

It must also ensure that any relocs to the weak symbol (from shared
libraries) end up pointed to the copy in the application, in the same
way that relocs to functions in shared libraries end up pointed to a
PLT entry in the application instead of the real function.

To make all this clear, I attach a shell script.  On ppc, it prints
the following at the end:

+ ./weak-w-wp-wm
1 1 1 
+ ./weak-w-sp-wm
1 2 1 
+ ./weak-wp-wm-s
1 1 1 
+ ./weak-sp-wm-s
1 1 1 

On sparc-solaris it prints:

+ ./weak-w-wp-wm 
1 1 1 
+ ./weak-w-sp-wm 
1 1 1 
+ ./weak-wp-wm-s 
1 1 1 
+ ./weak-sp-wm-s 
1 1 1 

which is what I expected.

You're saying that it should print, on glibc

+ ./weak-w-wp-wm
1 1 1 
+ ./weak-w-sp-wm
2 2 2
+ ./weak-wp-wm-s
1 1 1 
+ ./weak-sp-wm-s
1 1 1 

-- 
Geoffrey Keating <geoffk@ozemail.com.au>

===File ~/glibc-tests/weaktest.c============================
#define CONCAT(x,y) x ## y
#define CONCAT2(x,y) CONCAT(x,y)
#define STRING(x) #x
#define STRING2(x) STRING(x)

#ifdef WEAKDATA
#pragma weak dataitem
#endif

const char *dataitem = "weaktest-" STRING2(NUM) ".c";

const char *CONCAT2(getdataitem_,NUM)(void) 
{
  return dataitem;
}

extern const char *getdataitem_1(void);
extern const char *getdataitem_2(void);
extern const char *getdataitem_3(void);
extern const char *getdataitem_4(void);

#ifdef MAIN
#include <stdio.h>
int main(void)
{
  static const char *(*const (funcs[MAIN]))(void) = {
    getdataitem_1,
#if MAIN >= 2
    getdataitem_2,
#endif
#if MAIN >= 3
    getdataitem_3,
#endif
#if MAIN >= 4
    getdataitem_4
#endif
  };
  int i;

  for (i = 0; i < MAIN; i++)
    if (funcs[i])
      printf("getdataitem_%d has getdataitem defined in %s\n", i+1,
	     funcs[i]());
    else
      printf("getdataitem_%d is NULL\n", i+1);
}
#endif
============================================================

===File ~/glibc-tests/weaktest.sh===========================
#!/bin/sh
set -x
set -e
gcc -c -DNUM=1 weaktest.c -O -o weak1-strong.o
gcc -c -DNUM=1 -DWEAKDATA weaktest.c -O -o weak1-weak.o
gcc -c -DNUM=1 -fpic -DWEAKDATA weaktest.c -O -o weak1-weak-pic.o
gcc -shared -DNUM=2 -DWEAKDATA -fpic weaktest.c -O -o weak2-weak-pic.so
gcc -shared -DNUM=2 -DWEAKDATA -fpic weaktest.c -O -o weak2-strong-pic.so
gcc -c -DNUM=3 -DWEAKDATA -DMAIN=3 weaktest.c -O -o weak3-weak-main.o

gcc weak1-weak.o ./weak2-weak-pic.so weak3-weak-main.o -o weak-w-wp-wm
gcc weak1-weak.o ./weak2-strong-pic.so weak3-weak-main.o -o weak-w-sp-wm
gcc weak1-strong.o ./weak2-strong-pic.so weak3-weak-main.o -o weak-s-sp-wm
gcc ./weak2-strong-pic.so weak3-weak-main.o weak1-strong.o -o weak-sp-wm-s

============================================================

  reply	other threads:[~1999-07-06  1:01 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-07-04 13:52 H.J. Lu
1999-07-05  2:38 ` Geoff Keating
1999-07-05  7:41   ` Jason Gunthorpe
1999-07-05 20:48   ` Richard Henderson
1999-07-06  1:01     ` Geoff Keating [this message]
1999-07-06 12:16       ` Geoff Keating
1999-07-06 19:11     ` Ian Lance Taylor
1999-07-06 19:28       ` Richard Henderson
1999-07-06 19:31         ` Ian Lance Taylor
1999-07-06 21:45       ` H.J. Lu
1999-07-07  7:36         ` Ian Lance Taylor
1999-07-07  7:39           ` H.J. Lu
1999-07-07  7:44             ` Ian Lance Taylor
1999-07-07  7:57               ` H.J. Lu
1999-07-07  8:03                 ` Ian Lance Taylor
1999-07-07 20:12               ` Geoff Keating
1999-07-07 20:16                 ` Ian Lance Taylor
1999-07-07  1:33       ` Geoff Keating
1999-07-07  7:35         ` Ian Lance Taylor
1999-07-07 11:22         ` Ian Lance Taylor
1999-07-07 20:13           ` Geoff Keating
1999-07-07 20:28             ` Ian Lance Taylor
1999-07-08 17:29               ` Geoff Keating
1999-07-09  6:11                 ` Franz Sirl
1999-07-10  3:14                   ` Geoff Keating
1999-07-10  5:40                     ` Ian Lance Taylor

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=199907060800.SAA01123@geoffk.wattle.id.au \
    --to=geoffk@ozemail.com.au \
    --cc=binutils@sourceware.cygnus.com \
    --cc=drepper@cygnus.com \
    --cc=hjl@lucon.org \
    --cc=ian@cygnus.com \
    --cc=jgg@ualberta.ca \
    --cc=libc-hacker@sourceware.cygnus.com \
    --cc=rth@twiddle.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).