From owner-freebsd-hackers Tue Apr 2 11: 6: 0 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by hub.freebsd.org (Postfix) with ESMTP id 7DF2E37B425 for ; Tue, 2 Apr 2002 11:05:52 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1192) id 5D591AE1C6; Tue, 2 Apr 2002 11:05:52 -0800 (PST) Date: Tue, 2 Apr 2002 11:05:52 -0800 From: Alfred Perlstein To: "E.B. Dreger" Cc: hackers@freebsd.org Subject: Re: dlopen(), ld.so, and library wrappers Message-ID: <20020402190552.GT93885@elvis.mu.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.27i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * E.B. Dreger [020402 10:29] wrote: > Greetings all, > > > I wish to accomplish the following: > > 1. Program "foo" loads shared object "bar" using dlopen() and > dlsym() > > 2. "bar" needs certain symbols resolved, which "foo" intercepts. > > For example, "foo" might wrap malloc() or open() to provide its > own behavior... much like subclassing window procedures on that > OS from Redmond, only I'm wrapping library calls instead of > window callback procedures. > > Any suggestions, or should I get busy hacking ld-elf.so? > > And, yes, I know that one must be very careful when playing with > fire. If anyone wishes to tell of monsters or horror stories, > I'd appreciate those as well. From the dlopen manpage: If dlsym() is called with the special handle RTLD_NEXT, then the search for the symbol is limited to the shared objects which were loaded after the one issuing the call to dlsym(). Thus, if the function is called from the main program, all the shared libraries are searched. If it is called from a shared library, all subsequent shared libraries are searched. RTLD_NEXT is useful for implementing wrappers around library functions. For example, a wrapper function getpid() could access the ``real'' getpid() with dlsym(RTLD_NEXT, "getpid"). How does that sound? -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message