From owner-freebsd-net@FreeBSD.ORG Mon May 5 18:07:01 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 431BA1065675 for ; Mon, 5 May 2008 18:07:01 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.29]) by mx1.freebsd.org (Postfix) with ESMTP id EB71B8FC15 for ; Mon, 5 May 2008 18:07:00 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so504864ywe.13 for ; Mon, 05 May 2008 11:06:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=NMVOUW+lCFxAfSNZHjTtRxyGhQmrtvtUjW7qqQWjGsg=; b=lDcIZJW88EjWNYuSQ31qjz6P7Qt4ykMYGNMjaN/3ulDaP7mW/HjfJURvDUWTcvqDrZiwtTXLpf5VSd1kAhZ6x7xylwo+a26JMc7hv7CnO6BUuEfJ2RZJiIDAH8s47Or3UvJDU7YY2eAtrbwS1u2W9yZw5Q7zFeYsShARHSDQMk8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=HkZWjSGlN7Y8SU3pRdz6RIIc88sjmPghjVn+1YVB5bVInVVsKxN5bj9lsqvEUBrONA+YZAxLAKeJBJV/VFpwvjuVCZ2S3G+p7263je9sGuwZ+/42iqHahLbPQAcDxVd+R/AX3NlyMBrMh4hzjhnrHG8z89LBBfg5GwbTYJqahPs= Received: by 10.150.49.1 with SMTP id w1mr6361181ybw.4.1210010815000; Mon, 05 May 2008 11:06:55 -0700 (PDT) Received: by 10.151.11.1 with HTTP; Mon, 5 May 2008 11:06:54 -0700 (PDT) Message-ID: <3c0b01820805051106k5faf368etec0851e65de109f8@mail.gmail.com> Date: Mon, 5 May 2008 14:06:54 -0400 From: "Alexander Sack" To: "Kostik Belousov" In-Reply-To: <20080505163249.GU18958@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <5D267A3F22FD854F8F48B3D2B523819324F09D65FA@IRVEXCHCCR01.corp.ad.broadcom.com> <3c0b01820805021315i482fe0acg3e9238a2f412770e@mail.gmail.com> <5D267A3F22FD854F8F48B3D2B523819324F09D6896@IRVEXCHCCR01.corp.ad.broadcom.com> <3c0b01820805030750k2fc389b0y500914c36069e6cf@mail.gmail.com> <5D267A3F22FD854F8F48B3D2B523819324F09D6A52@IRVEXCHCCR01.corp.ad.broadcom.com> <20080505163249.GU18958@deviant.kiev.zoral.com.ua> Cc: "freebsd-net@freebsd.org" , David Christensen Subject: Re: Not All Symbols Present in a Loadable Kernel Module X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2008 18:07:01 -0000 For my own edification, unless you specifically mark a function inline, will gcc really optimize them out? That seems a little overboard unless there is some compiler option that says its okay to do that. I guess that would be very easy to test if you do as you say, just sock away the function address pointer somewhere and you should be okay... -aps On Mon, May 5, 2008 at 12:32 PM, Kostik Belousov wrote: > > On Mon, May 05, 2008 at 09:27:10AM -0700, David Christensen wrote: > > > > Yes, I'm building a debug kernel. I have the line listed above as > > > well > > > > as the following: > > > > > > > > options KDB > > > > options DDB > > > > options GDB > > > > options INVARIANTS > > > > options INVARIANT_SUPPORT > > > > options WITNESS > > > > options WITNESS_SKIPSPIN > > > > > > Dave: > > > > > > What symbols can you not access exactly and how are you > > > installing/setting up debugging? > > > > > > I just built a RELENG_7 with DDB and I'm able to access bce symbols > > > without a problem. I can examine them and call them. I'm not using > > > options GDB however, only KDB/DDB. > > > > > > I would: > > > > > > - Make sure you have the right if_bce.ko/if_bce.ko.symbols files > > > generated/installed which contains the debug sections of your ko (from > > > the objcopy calls during the build - the binary is stripped with a > > > section pointer to the if_bce.ko.symbols file for debugging > > > information I believe) > > > - If you are using GDB, make sure its pointed to the right source base > > > so it can retrieve symbol information correctly > > > - If you are using GDB, stub it out and just use DDB to verify that > > > your build is sane (it works for me!) > > > - If all else fails, you can always build bce statically (just to move > > > forward etc.) > > > > - Enable the kernel debugger as described above > > - Build the driver in the /usr/src/sys/modules/bce directory with the > > command "make". > > - Run the command "nm if_bce.ko | grep dump_stat" in the same directory > > with the kernel module just built. > > > > In my case I only see a symbol for bce_dump_status_block, but there is a > > second routine called bce_dump_stats_block. In my working build there > > are 23 functions that start with "bce_dump" but only 8 are displayed with > > the command "nm if_bce.ko | grep bce_dump". Of course, I also get the > > symbol not present error when I try to use any of those missing symbols > > through a "call" command in the debugger. > > Most likely, they are optimized out, gcc likes to inline once-called > static functions. Aside from playing with the optimization options, > the easiest way seems to use functions somewhere else, e.g., put the > addresses into some table. Just guessing. >