This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: RFC/RFA: MN10300: Fix handling of protected functions in shared libraries.
- From: Alan Modra <amodra at gmail dot com>
- To: Nick Clifton <nickc at redhat dot com>
- Cc: aoliva at redhat dot com, law at redhat dot com, rth at redhat dot com, gcc-patches at gcc dot gnu dot org, binutils at sourceware dot org
- Date: Thu, 26 May 2011 13:52:21 +0930
- Subject: Re: RFC/RFA: MN10300: Fix handling of protected functions in shared libraries.
- References: <m3d3j9bfy5.fsf@redhat.com>
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