public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Alan Modra <amodra@gmail.com>
To: Nick Clifton <nickc@redhat.com>
Cc: aoliva@redhat.com, law@redhat.com, rth@redhat.com,
	gcc-patches@gcc.gnu.org, binutils@sourceware.org
Subject: Re: RFC/RFA: MN10300: Fix handling of protected functions in shared libraries.
Date: Thu, 26 May 2011 04:22:00 -0000	[thread overview]
Message-ID: <20110526042221.GC16286@bubble.grove.modra.org> (raw)
In-Reply-To: <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

      parent reply	other threads:[~2011-05-26  4:22 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-23 15:21 Nick Clifton
2011-05-23 16:16 ` Jeff Law
2011-05-26  4:22 ` Alan Modra [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110526042221.GC16286@bubble.grove.modra.org \
    --to=amodra@gmail.com \
    --cc=aoliva@redhat.com \
    --cc=binutils@sourceware.org \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=law@redhat.com \
    --cc=nickc@redhat.com \
    --cc=rth@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).