public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Nick Clifton <nickc@redhat.com>
To: aoliva@redhat.com, law@redhat.com, rth@redhat.com
Cc: gcc-patches@gcc.gnu.org, binutils@sourceware.org
Subject: RFC/RFA: MN10300: Fix handling of protected functions in shared libraries.
Date: Mon, 23 May 2011 15:21:00 -0000	[thread overview]
Message-ID: <m3d3j9bfy5.fsf@redhat.com> (raw)

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.

Cheers
  Nick

Index: gcc/config/mn10300/mn10300.c
===================================================================
--- gcc/config/mn10300/mn10300.c	(revision 174069)
+++ gcc/config/mn10300/mn10300.c	(working copy)
@@ -3315,8 +3315,30 @@
     }
 }
 \f
+static bool
+mn10300_binds_local (const_tree exp)
+{
+  bool local = default_binds_local_p (exp);
+
+  /* The default binds_local function will decide that protected functions
+     bind locally.  Whilst technically this is true, in practice in PIC mode
+     protected functions still need a PLT entry so that function pointer
+     comparison will work.  */
+  if (local
+      && flag_pic
+      && DECL_P (exp)
+      && TREE_CODE (exp) == FUNCTION_DECL
+      && DECL_VISIBILITY (exp) == VISIBILITY_PROTECTED)
+    return false;
+
+  return local;
+}
+\f
 /* Initialize the GCC target structure.  */
 
+#undef  TARGET_BINDS_LOCAL_P
+#define TARGET_BINDS_LOCAL_P mn10300_binds_local
+
 #undef  TARGET_MACHINE_DEPENDENT_REORG
 #define TARGET_MACHINE_DEPENDENT_REORG mn10300_reorg
 
  

             reply	other threads:[~2011-05-23 15:21 UTC|newest]

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

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=m3d3j9bfy5.fsf@redhat.com \
    --to=nickc@redhat.com \
    --cc=aoliva@redhat.com \
    --cc=binutils@sourceware.org \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=law@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).