aha. Now to test with 4.5.0. :)
jay@xlin2:~$ cat 1.c
void F1() { }
void* F2() { return F1; }
jay@xlin2:~$ gcc -fPIC -shared 1.c -fvisibility=protected
/usr/bin/ld: /tmp/ccEWCXGw.o: relocation R_386_GOTOFF against protected function `F1' can not be used when making a shared object
/usr/bin/ld: final link failed: Bad value
collect2: ld returned 1 exit status
jay@xlin2:~$ gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.2-1.1' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-targets=all --enable-cld --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.3.2 (Debian 4.3.2-1.1)
- Jay
----------------------------------------
> From: jay.krell@xxxxxxxxxxx
> To: gcc-help@xxxxxxxxxxx
> Subject: ideal visibility setting?
> Date: Mon, 17 May 2010 12:08:38 +0000
>
>
> We generate gcc trees.
>
>
> I'm aware of "visibility"
> Is something exported or not?
> If it is exported, do I reference it "directly" or allow for interposition?
>
>
> What I would like is..basically the NT model, but without __declspec(dllimport)
> which is "just" an optimization for functions, but, granted,
> more than that for data.
> I promise not to import/export data.
> I want all symbols, for codegen purposes, to be default assumed to be
> neither exported nor imported. I want to reference functions directly.
> No GOT or PLT references in the "main" code.
> No "interposition".
>
>
> If I mark a function somehow as exported, I want that just to be a note
> to the linker.
>
>
> If the linker resolves a function against a shared object, I want
> it to generate a little stub that does the necessary indirection.
>
>
> I'm assuming that most inter-function calls are intra-shared object.
> To the extent that that is true, this is simple and efficient.
> To the extent that that is false, it is a deoptimization.
> It absolves anyone from knowing at compile time which functions are where.
>
>
> This is how things work on NT and it seems nice.
> I realize NT doesn't offer position independence, so the use
> of linker generated stubs would be more inefficient in
> what I am describing, vs. inlining them at the call site.
> But again, I'm optimizing for the intra-shared object references
> which I assume are more common.
>
>
> Any ideas how to achieve this?
>
>
> I hit problems before getting very far.
> When I mark functions as VISIBILITY_PROTECTED, references within the same
> objecte file still use the GOT and I get:
>
>
> /usr/bin/ld: Region.mo: relocation R_386_GOTOFF against protected function `Region__Meet' can not be used when making a shared object
> /usr/bin/ld: final link failed: Bad value
>
>
> Thanks,
> - Jay
>
