From phk@critter.freebsd.dk  Sat May  9 15:17:15 2009
Return-Path: <phk@critter.freebsd.dk>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id ADE8E106567B
	for <FreeBSD-gnats-submit@freebsd.org>; Sat,  9 May 2009 15:17:15 +0000 (UTC)
	(envelope-from phk@critter.freebsd.dk)
Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222])
	by mx1.freebsd.org (Postfix) with ESMTP id 703EE8FC1B
	for <FreeBSD-gnats-submit@freebsd.org>; Sat,  9 May 2009 15:17:15 +0000 (UTC)
	(envelope-from phk@critter.freebsd.dk)
Received: from critter.freebsd.dk (unknown [192.168.64.3])
	by phk.freebsd.dk (Postfix) with ESMTP id B0BD078D03
	for <FreeBSD-gnats-submit@freebsd.org>; Sat,  9 May 2009 14:58:50 +0000 (UTC)
Received: from critter.freebsd.dk (localhost [127.0.0.1])
	by critter.freebsd.dk (8.14.3/8.14.3) with ESMTP id n49EwofS029190
	for <FreeBSD-gnats-submit@freebsd.org>; Sat, 9 May 2009 14:58:50 GMT
	(envelope-from phk@critter.freebsd.dk)
Received: (from phk@localhost)
	by critter.freebsd.dk (8.14.3/8.14.3/Submit) id n49EwnTF029189;
	Sat, 9 May 2009 14:58:50 GMT
	(envelope-from phk)
Message-Id: <200905091458.n49EwnTF029189@critter.freebsd.dk>
Date: Sat, 9 May 2009 14:58:50 GMT
From: Poul-Henning Kamp <phk@critter.freebsd.dk>
Reply-To: Poul-Henning Kamp <phk@critter.freebsd.dk>
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: dladdr(3) does effectively not work on main program.
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         134391
>Category:       kern
>Synopsis:       [libc] dladdr(3) does effectively not work on main program.
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sat May 09 15:20:01 UTC 2009
>Closed-Date:    
>Last-Modified:  Mon Sep 14 01:30:03 UTC 2009
>Originator:     Poul-Henning Kamp
>Release:        FreeBSD 8.0-CURRENT i386
>Organization:
>Environment:
System: FreeBSD critter.freebsd.dk 8.0-CURRENT FreeBSD 8.0-CURRENT #1 r191911: Fri May 8 09:42:35 UTC 2009 root@critter.freebsd.dk:/usr/obj/freebsd/head/sys/CRITTER i386

>Description:
	The dladdr(3) function does not return anything remotely
	useful for the main program, because it only examines the
	dynamic symbol table.

	The most common use for this function, is to construct a
	backtrace.

	ports/devel/libexecinfo is an example of this use.

>How-To-Repeat:
	#include <stdio.h>
	#include <dlfcn.h>

	extern void foo(const void *a);
	static void bar(void *a);

	int
	main(int argc, char **argv)
	{

		(void)argc;
		(void)argv;

		foo((const char *)bar + 4);
		return (0);
	}

	void foo(const void *a)
	{
		Dl_info info;
		int i;

		i = dladdr(a, &info);

		printf("i = %d (%p)\n", i, a);
		printf("fn = %s\n", info.dli_fname);
		printf("fb = %p\n", info.dli_fbase);
		printf("sn = %s\n", info.dli_sname);
		printf("sb = %p\n", info.dli_saddr);
	}

	static void bar(void *b)
	{
		printf("%p\n", b);
	}

>Fix:

	Linking the program with `-Wl,--export-dynamic fills the
	dynamic symbol table with all non-static symbols, which is
	a bit better, but still useless because all static functions
	are invisible.

	A simple correct solution escapes me, since we might not
	even be able to open the original binary again to read the
	DWARF symbol table.

	One, quasi-hackish way to solve this, is to notice that the
	program references dladdr(3) in the first place, and have rtld(1)
	load the DWARF-symbol table(s) also.
>Release-Note:
>Audit-Trail:

From: David Chisnall <csdavec@swansea.ac.uk>
To: bug-followup@FreeBSD.org, phk@critter.freebsd.dk
Cc:  
Subject: Re: kern/134391: [libc] dladdr(3) does effectively not work on main program.
Date: Mon, 14 Sep 2009 02:06:51 +0100

 I tried to submit something related to this bug a while ago, but send- 
 pr ate it...
 
 dlsym() on FreeBSD is similarly broken.  It's worth noting that nm is  
 capable of listing all of the symbols in an executable or shared  
 object, even when compiled without debug info, and so they must exist  
 in the binary, they are just not being added to the symbol table that  
 is exposed via these functions.  The behaviour of dladdr() is  
 particularly bad because, unlike dlsym() it doesn't return failure, it  
 simply returns the name of a different symbol from the same library.
 
 David
>Unformatted:
