RFC/RFA: MN10300: Fix handling of protected functions in shared libraries.

Jeff Law law@redhat.com
Mon May 23 17:58:00 GMT 2011


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 05/23/11 09:21, Nick Clifton wrote:
> Hi Alex, Hi Jeff, Hi Richard,
> 
>   Consider the following small test case:
> 
>     % cat test1.c
>     extern int g (void) __attribute__ ((visibility("protected")));
>     int f (void) { return g (); }
> 
>     % cat test2.c
>     extern int g(void) __attribute__ ((visibility("protected")));
>     int i;
>     int g (void) { return i; }
> 
>     % gcc -fPIC -c test1.c test2.c
>     % gcc -shared -o libtest_protected.so test1.o test2.o
> 
>   When compiled with a MN10300 toolchain based on the current FSF GCC
>   and binutils sources the final link will fail with:
>     
>     test1.o: In function `f':
>     test1.c:(.text+0x7): warning: error: inappropriate relocation type for shared library (did you forget -fpic?)
> 
>   The problem here is that GCC has decided that since "g" is protected
>   it does not need a PLT entry.  But the linker has decided that since
>   "g" is a function it does need a PLT entry (even though it is
>   protected) so that function pointer comparison will work.  (See the
>   definition of SYMBOL_REFERENCES_LOCAL in bfd/elf-bfd.h for more
>   information on this).
> 
>   I have a small patch that fixes this problem (see below), but I am not
>   sure if this is the correct solution.  As far as I can see, this is
>   not an MN10300 specific problem however, so surely other targets ought
>   to have similar problems ?  (But other targets do not seem to use
>   targetm.binds_local_p to decide if a symbol is global or local.  cf/
>   mn10300_encode_section_info).
> 
>   Anyway any advice or comments on the situation would be appreciated.
This isn't something I have much experience with; presumably we must
have the PLT entry even though "g" is considered protected?  If so, then
ISTM GCC will need to cope/adapt and your approach seems as good as any
other to me -- unless we wanted to move the code into a more generic
location.

jeff
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJN2ohHAAoJEBRtltQi2kC7lpcH/ihLGKBhkB7PG2ZjkXZJBH2l
WMuG7lVDSKiveqLTCI5o4bXRue2Xt+cusYGn/+nUGv5oMfPZCb5qmypT58e0IvVM
w1oFks9X+0DyhuIQ0gD4BEbS+R36KkkMlnI4zGqpUq4J+i6XJFIrurw4DghJ22Pe
tU7P7C7+uUeAH5f/Be3QIx1MNl0BnruyzPRSrXzGnrg5DP6yyXdwE8SmAhqEuUvJ
UkTqT1HWDVgS1eN+lh8tHUUu2ygqoTELpVOwVkvTXP1qrJKmwgbV+3Tvu8jMfvYJ
olm2HWUINPX2zvlaqfYUNB+5gFifkqVg7JXOF+NUasaUZwPIiReGaxbsRSFt7Ug=
=zrdM
-----END PGP SIGNATURE-----



More information about the Gcc-patches mailing list