From owner-freebsd-hackers  Sat Feb 20 13:54:37 1999
Delivered-To: freebsd-hackers@freebsd.org
Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134])
	by hub.freebsd.org (Postfix) with ESMTP id DD7611194A
	for <hackers@FreeBSD.ORG>; Sat, 20 Feb 1999 13:54:35 -0800 (PST)
	(envelope-from tlambert@usr08.primenet.com)
Received: (from daemon@localhost)
	by smtp04.primenet.com (8.8.8/8.8.8) id PAA20898;
	Sat, 20 Feb 1999 15:11:23 -0700 (MST)
Received: from usr08.primenet.com(206.165.6.208)
 via SMTP by smtp04.primenet.com, id smtpd020845; Sat Feb 20 15:11:10 1999
Received: (from tlambert@localhost)
	by usr08.primenet.com (8.8.5/8.8.5) id OAA18160;
	Sat, 20 Feb 1999 14:54:20 -0700 (MST)
From: Terry Lambert <tlambert@primenet.com>
Message-Id: <199902202154.OAA18160@usr08.primenet.com>
Subject: Interesting ld.so bug
To: jdp@polstra.com (John Polstra)
Date: Sat, 20 Feb 1999 21:54:19 +0000 (GMT)
Cc: tlambert@primenet.com, hackers@FreeBSD.ORG
In-Reply-To: <XFMail.990219163650.jdp@polstra.com> from "John Polstra" at Feb 19, 99 04:36:50 pm
X-Mailer: ELM [version 2.4 PL25]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-hackers@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

There appears to be a bug with ld.so.  The following steps illustrate
the bug:


Create a shared library A, containing two functions, one dependent on
the other:

	int
	A( int i)
	{
		int	r;

		i++;
		r = B( i);

		return( r);
	}


	int
	B( int i)
	{
		int	r;

		r = i + 2;

		return( r);
	}

Create a shared library F, containing a function that calls the dependent
function A from the shared library:

	int
	F( int i)
	{
		int	r;
		
		i++;
		r = A( i);

		return( r);
	}

Link shared library F against shared library A, such that you see
it in the output of:

	objdump --all-headers libF.so.1 | grep NEEDS

Create a shared object X; in it, call function F:

	void
	X( void)
	{
		int	i;

		i = F( 5);

		printf( "F( 5) is %d\n", i);
	}

Link the shared object X against the shared library F, such that you
see it in the output of:

	objdump --all-headers X.So | grep NEEDS

Now the fun part:

o	create a program that dlopen's X.So, and calls X()
o	gdb it
o	breakpoint dlopen
o	run
o	step through until A is called, and note that A is called
	correctly
o	step until just prior to calling B
o	note prior to the call to B that the jump table contains
	the correct fixup data; verify this by examining library
	libA.so.1 with ``objdump''
o	attempt to step through the call to B
o	SIGSEGV

Apparently, symbols in indirectly dependent libraries which are
used by the indirectly dependent libraries are not fixed up
correctly.  It appears to be a failure to recurse on the leaf
library so that it can self-reference its own symbols.

This was noticed while attempting to implement a JNI in KAFFE,
which uses dlopen's of shared objects to implement JNI.


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message