public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
* A symbol version bug
@ 2003-05-14  0:20 H. J. Lu
  2003-05-14  0:50 ` H. J. Lu
  2003-05-14  7:15 ` H. J. Lu
  0 siblings, 2 replies; 4+ messages in thread
From: H. J. Lu @ 2003-05-14  0:20 UTC (permalink / raw)
  To: Michael Kerrisk; +Cc: binutils, GNU C Library

[-- Attachment #1: Type: text/plain, Size: 2531 bytes --]

Michael found a bug between binutils and glibc. ld.so assumes the
first symbol from the hash table is the oldest (default) version.
Unfortunately, it is not always true. The question is if glibc
should depend on it or ld should guarantee it.


H.J.
----
On Tue, May 13, 2003 at 09:49:13PM +0200, Michael Kerrisk wrote:
Content-Description: Mail message body
> > On Fri, May 09, 2003 at 01:41:37PM +0200, Michael Kerrisk wrote:
> > > Hello HJ.,
> > > 
> > > Just to follow up on my earlier question.  Looking at the version scripts > > documentation in "info glibc", I understand well enough what the 
> > > following do:
> > > 
> > > __asm__(".symver old_foo,foo@VERS_1.1");
> > > __asm__(".symver old_foo1,foo@VERS_1.2");
> > > __asm__(".symver new_foo,foo@@VERS_2.0");
> > > 
> > > But there is also this example mentioned:
> > > 
> > > __asm__(".symver original_foo,foo@");
> > > 
> > > And the following text 
> > > 
> > > > In this example, `foo@' represents the symbol `foo' bound to the 
> > > > unspecified base version of the symbol. The source file that contains
> > > > this example would define 4 C functions: `original_foo', `old_foo',
> > > > `old_foo1', and `new_foo'.
> > > 
> > > However, I can't seem to find anything that usefully works with the foo@
> > > syntax.  Do you know / could you explain to me where and when this syntax > > is useful?
> > > 
> > > I tried the following (unsuccessful) experiment:
> > 
> > It works for me. Here is my example.
> > 
> > # make
> > cc    -c -o new.o new.c
> > cc -Wl,-soname,libfoo.so,--version-script=foo.v -shared -o libnew.so new.o
> > cc    -c -o main.o main.c
> > cc -o new libnew.so main.o -Wl,-rpath,
> > cc -fPIC   -c -o old.o old.c
> > cc -Wl,-soname,libfoo.so -shared -o libold.so old.o
> > cc -o old libold.so main.o -Wl,-rpath,
> > ln -sf libnew.so libfoo.so
> > ./old
> > original_foo
> > ./new
> > new_foo
> > ln -sf libold.so libfoo.so
> > ./old
> > foo
> > ./new
> > ./new: libfoo.so: no version information available (required by ./new)
> > foo
> 
> Hello H.J.,
> 
> I know this sounds bizarre, but I made one change to your code: I renamed 
> the global symbol "foo" to "xyz", and now things no longer work as they 
> did for you above.  Instead, I get the behavior I described in my earlier 
> mail, as shown in the script below.  I have banged my head on this for 
> quite a while and concluded that something extremely weird is going on, or 
> that I'm being very blind.  Can you enlighten me?  (I've attached my 
> modified version of your code.)


[-- Attachment #2: test_mtk.tar.gz --]
[-- Type: application/x-gzip, Size: 650 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: A symbol version bug
  2003-05-14  0:20 A symbol version bug H. J. Lu
@ 2003-05-14  0:50 ` H. J. Lu
  2003-05-14 15:33   ` PATCH: " H. J. Lu
  2003-05-14  7:15 ` H. J. Lu
  1 sibling, 1 reply; 4+ messages in thread
From: H. J. Lu @ 2003-05-14  0:50 UTC (permalink / raw)
  To: Michael Kerrisk; +Cc: binutils, GNU C Library

On Tue, May 13, 2003 at 05:20:26PM -0700, H. J. Lu wrote:
> Michael found a bug between binutils and glibc. ld.so assumes the
> first symbol from the hash table is the oldest (default) version.
> Unfortunately, it is not always true. The question is if glibc
> should depend on it or ld should guarantee it.
> 
> 

There are one glibc bug and one binutils bug. Both should take base
version into account.


H.J.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* PATCH: A symbol version bug
  2003-05-14  0:20 A symbol version bug H. J. Lu
  2003-05-14  0:50 ` H. J. Lu
@ 2003-05-14  7:15 ` H. J. Lu
  1 sibling, 0 replies; 4+ messages in thread
From: H. J. Lu @ 2003-05-14  7:15 UTC (permalink / raw)
  To: Michael Kerrisk; +Cc: binutils, GNU C Library

[-- Attachment #1: Type: text/plain, Size: 436 bytes --]

On Tue, May 13, 2003 at 05:20:26PM -0700, H. J. Lu wrote:
> Michael found a bug between binutils and glibc. ld.so assumes the
> first symbol from the hash table is the oldest (default) version.
> Unfortunately, it is not always true. The question is if glibc
> should depend on it or ld should guarantee it.
> 
> 

I believe it is a glibc bug. The problem is we didn't handle hidden
base version right. This patch should fix it.


H.J.

[-- Attachment #2: libc-base.patch --]
[-- Type: text/plain, Size: 1598 bytes --]

2003-05-14  <hongjiu.lu@intel.com>

	* elf/do-lookup.h (FCT): Try the base version, the first
	version and then the default version, in that order, for
	the old unversioned reference.

--- elf/do-lookup.h.base	2003-05-13 14:37:50.000000000 -0700
+++ elf/do-lookup.h	2003-05-14 00:00:09.000000000 -0700
@@ -53,6 +53,8 @@ FCT (const char *undef_name, unsigned lo
 #if ! VERSIONED
       int num_versions = 0;
       const ElfW(Sym) *versioned_sym = NULL;
+      const ElfW(Sym) *first_version = NULL;
+      const ElfW(Sym) *base_version = NULL;
 #endif
 
       map = list[i];
@@ -155,13 +157,22 @@ FCT (const char *undef_name, unsigned lo
 	     public interface should be returned.  */
 	  if (verstab != NULL)
 	    {
-	      if ((verstab[symidx] & 0x7fff)
-		  >= ((flags & DL_LOOKUP_RETURN_NEWEST) ? 2 : 3))
+	      ElfW(Half) ndx = verstab[symidx] & 0x7fff;
+	      if (ndx >= ((flags & DL_LOOKUP_RETURN_NEWEST) ? 2 : 3))
 		{
 		  /* Don't accept hidden symbols.  */
 		  if ((verstab[symidx] & 0x8000) == 0 && num_versions++ == 0)
 		    /* No version so far.  */
 		    versioned_sym = sym;
+		  
+		  continue;
+		}
+	      if ((flags & DL_LOOKUP_RETURN_NEWEST) == 0)
+		{
+		  if (ndx == 1)
+		    base_version = sym;
+		  else if (ndx == 2)
+		    first_version = sym;
 
 		  continue;
 		}
@@ -179,7 +190,8 @@ FCT (const char *undef_name, unsigned lo
 #if VERSIONED
       sym = NULL;
 #else
-      sym = num_versions == 1 ? versioned_sym : NULL;
+      sym = base_version ?: (first_version ?: (num_versions == 1
+					       ? versioned_sym : NULL));
 #endif
 
       if (sym != NULL)

^ permalink raw reply	[flat|nested] 4+ messages in thread

* PATCH: A symbol version bug
  2003-05-14  0:50 ` H. J. Lu
@ 2003-05-14 15:33   ` H. J. Lu
  0 siblings, 0 replies; 4+ messages in thread
From: H. J. Lu @ 2003-05-14 15:33 UTC (permalink / raw)
  To: binutils

[-- Attachment #1: Type: text/plain, Size: 523 bytes --]

On Tue, May 13, 2003 at 05:50:53PM -0700, H. J. Lu wrote:
> On Tue, May 13, 2003 at 05:20:26PM -0700, H. J. Lu wrote:
> > Michael found a bug between binutils and glibc. ld.so assumes the
> > first symbol from the hash table is the oldest (default) version.
> > Unfortunately, it is not always true. The question is if glibc
> > should depend on it or ld should guarantee it.
> > 
> > 
> 
> There are one glibc bug and one binutils bug. Both should take base
> version into account.

Here is the patch for binutils.


H.J.

[-- Attachment #2: bfd-base.patch --]
[-- Type: text/plain, Size: 929 bytes --]

2003-05-14  H.J. Lu <hongjiu.lu@intel.com>

	* elflink.h (elf_link_check_versioned_symbol): Also allow
	the base version.

--- bfd/elflink.h.base	2003-05-09 08:13:31.000000000 -0700
+++ bfd/elflink.h	2003-05-14 08:30:10.000000000 -0700
@@ -4334,6 +4334,7 @@ elf_link_check_versioned_symbol (info, h
 	{
 	  const char *name;
 	  Elf_Internal_Versym iver;
+	  unsigned short version_index;
 
 	  if (ELF_ST_BIND (isym->st_info) == STB_LOCAL
 	      || isym->st_shndx == SHN_UNDEF)
@@ -4354,9 +4355,10 @@ elf_link_check_versioned_symbol (info, h
 	      abort ();
 	    }
 
-	  if ((iver.vs_vers & VERSYM_VERSION) == 2)
+	  version_index = iver.vs_vers & VERSYM_VERSION;
+	  if (version_index == 1 || version_index == 2)
 	    {
-	      /* This is the oldest (default) sym.  We can use it.  */
+	      /* This is the base or first version.  We can use it.  */
 	      free (extversym);
 	      free (isymbuf);
 	      return TRUE;

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2003-05-14 15:33 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-05-14  0:20 A symbol version bug H. J. Lu
2003-05-14  0:50 ` H. J. Lu
2003-05-14 15:33   ` PATCH: " H. J. Lu
2003-05-14  7:15 ` H. J. Lu

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