From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-158340-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 8197 invoked by alias); 26 Nov 2009 06:04:50 -0000
Received: (qmail 8048 invoked by uid 22791); 26 Nov 2009 06:04:49 -0000
X-SWARE-Spam-Status: No, hits=0.0 required=5.0 	tests=AWL,BAYES_05,HK_OBFDOM,SARE_MSGID_LONG40,SPF_PASS
X-Spam-Check-By: sourceware.org
Received: from mail-pw0-f57.google.com (HELO mail-pw0-f57.google.com) (209.85.160.57)     by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 26 Nov 2009 06:04:42 +0000
Received: by pwi2 with SMTP id 2so320022pwi.16         for <gcc@gcc.gnu.org>; Wed, 25 Nov 2009 22:04:41 -0800 (PST)
MIME-Version: 1.0
Received: by 10.143.154.14 with SMTP id g14mr907688wfo.266.1259215481010; Wed,  	25 Nov 2009 22:04:41 -0800 (PST)
In-Reply-To: <4B0DF1EC.30001@redhat.com>
References: <4df04b840911231758md5a545el2d417b663af1647f@mail.gmail.com> 	 <4df04b840911251824j71fa1d33i2cecc9481617dda5@mail.gmail.com> 	 <4B0DF1EC.30001@redhat.com>
Date: Thu, 26 Nov 2009 06:04:00 -0000
Message-ID: <4df04b840911252204g33297e18m8e189c62a0662378@mail.gmail.com>
Subject: Re: No .got section in ELF
From: yunfeng zhang <zyf.zeroos@gmail.com>
To: Richard Henderson <rth@redhat.com>
Cc: gcc@gcc.gnu.org, Andrew Haley <aph@redhat.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc/>
List-Post: <mailto:gcc@gcc.gnu.org>
List-Help: <http://gcc.gnu.org/ml/>
Sender: gcc-owner@gcc.gnu.org
X-SW-Source: 2009-11/txt/msg00740.txt.bz2

The result is the same

#include<stdio.h>

extern int g __attribute__((visibility("hidden")));
int g;

int foo(int a, int b)
{
        g =3D a + b;
        printf("%x, %x", &g, foo);
        return g;
}

load and call `foo' in the library, an outputting (with vdso) is
    cc15bc, cc03fc
and open f.map
    0x15bc, 0x3fc

It shows Linux simply maps the library to memory *using* library segment la=
yout.

Using e.cc to call it

#include <exception>
#include <typeinfo>
#include <cstddef>
#include <dlfcn.h>
#include <stdio.h>

int main(void)
{
                void* handle =3D dlopen("./f.so", RTLD_NOW);
                typedef int (*gso)(int, int);
                gso f;
                *(void**) (&f) =3D dlsym(handle, "foo");
                f(1, 2);
        return 0;
}

gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-44).

2009/11/26 Richard Henderson <rth@redhat.com>:
> On 11/25/2009 06:24 PM, yunfeng zhang wrote:
>>
>> It seems that original limitation isn't clear or sufficient
>>
>> For a sample:
>>
>> // f.c
>> int g;
>> void foo(void)
>> {
>> =A0 =A0 =A0 =A0g =3D 1;
>> }
>>
>> compile with `gcc -shared -fPIC -Wl,-soname,f.so,-Map,f.map -o f.so
>> f.c'...
>
> With -fPIC, the variable G may be overridden by another variable of the s=
ame
> name from another shared object earlier in the search path. =A0That is, t=
he
> offset is *not* fixed because the final address of G may reside in a
> different .so file.
>
> Change your program to
>
> =A0static int g;
>
> or
>
> =A0extern int g __attribute__((visibility("hidden")));
> =A0int g;
>
> and compare the results. =A0In either case G is known to resolve to the
> instance present in f.so. =A0In either case we'll use a constant offset.
>
> You really need to understand how ELF actually works before suggesting th=
at
> it's broken.
>
>
> r~
>