This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On Mon, May 23, 2011 at 04:21:38PM +0100, Nick Clifton wrote:
>   The problem here is that GCC has decided that since "g" is protected
>   it does not need a PLT entry.

Right.

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

Nope.  This sounds like a linker bug.  You don't actually need a plt
entry in the shared lib.  What you do need to do is be careful about
taking the address of "g".  The address should *not* resolve locally,
but rather to the same address used by the executable, ie. the plt
entry in the executable.  That just means that "g" must be dynamic.

>  (See the
>   definition of SYMBOL_REFERENCES_LOCAL in bfd/elf-bfd.h for more
>   information on this).

Ick, I see that comment is mine.  It needs clarifying and should have
been moved when _bfd_elf_symbol_refs_local_p was written.  "reference
the .plt" should have been "reference the .plt entry in the
executable".

	* elf-bfd.h (SYMBOL_REFERENCES_LOCAL): Remove most of comment.
	* elflink.c (_bfd_elf_symbol_refs_local_p): Expand
	local_protected comment.

Index: bfd/elf-bfd.h
===================================================================
RCS file: /cvs/src/src/bfd/elf-bfd.h,v
retrieving revision 1.319
diff -u -p -r1.319 elf-bfd.h
--- bfd/elf-bfd.h	23 May 2011 06:22:50 -0000	1.319
+++ bfd/elf-bfd.h	26 May 2011 04:13:18 -0000
@@ -232,11 +232,7 @@ struct elf_link_hash_entry
 };
 
 /* Will references to this symbol always reference the symbol
-   in this object?  STV_PROTECTED is excluded from the visibility test
-   here so that function pointer comparisons work properly.  Since
-   function symbols not defined in an app are set to their .plt entry,
-   it's necessary for shared libs to also reference the .plt even
-   though the symbol is really local to the shared lib.  */
+   in this object?  */
 #define SYMBOL_REFERENCES_LOCAL(INFO, H) \
   _bfd_elf_symbol_refs_local_p (H, INFO, 0)
 
Index: bfd/elflink.c
===================================================================
RCS file: /cvs/src/src/bfd/elflink.c,v
retrieving revision 1.405
diff -u -p -r1.405 elflink.c
--- bfd/elflink.c	18 May 2011 14:04:31 -0000	1.405
+++ bfd/elflink.c	26 May 2011 04:13:23 -0000
@@ -2881,8 +2881,10 @@ _bfd_elf_symbol_refs_local_p (struct elf
     return TRUE;
 
   /* Function pointer equality tests may require that STV_PROTECTED
-     symbols be treated as dynamic symbols, even when we know that the
-     dynamic linker will resolve them locally.  */
+     symbols be treated as dynamic symbols.  If the address of a
+     function not defined in an executable is set to that function's
+     plt entry in the executable, then the address of the function in
+     a shared library must also be the plt entry in the executable.  */
   return local_protected;
 }
 

-- 
Alan Modra
Australia Development Lab, IBM


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