From owner-svn-src-all@FreeBSD.ORG Tue May 22 18:03:24 2012 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 715CA106566B; Tue, 22 May 2012 18:03:24 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail02.syd.optusnet.com.au (mail02.syd.optusnet.com.au [211.29.132.183]) by mx1.freebsd.org (Postfix) with ESMTP id 084418FC14; Tue, 22 May 2012 18:03:23 +0000 (UTC) Received: from c122-106-171-232.carlnfd1.nsw.optusnet.com.au (c122-106-171-232.carlnfd1.nsw.optusnet.com.au [122.106.171.232]) by mail02.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q4MI38rn006979 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 May 2012 04:03:10 +1000 Date: Wed, 23 May 2012 04:03:08 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Hartmut Brandt In-Reply-To: Message-ID: <20120523023228.L2766@besplex.bde.org> References: <201205220723.q4M7Ng2I091715@svn.freebsd.org> <20120522212307.V1971@besplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Hartmut Brandt , Bruce Evans Subject: Re: svn commit: r235777 - head/sys/kern X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 18:03:24 -0000 On Tue, 22 May 2012, Hartmut Brandt wrote: > On Tue, 22 May 2012, Bruce Evans wrote: > > BE>On Tue, 22 May 2012, Hartmut Brandt wrote: > BE> > BE>> Log: > BE>> Make dumptid non-static. It is used by libkvm to detect whether > BE>> this is a VNET-kernel or not. gcc used to put the static symbol into > BE>> the symbol table, clang does not. This fixes the 'netstat: no namelist' > BE>> error seen on clang+VNET systems. > BE>> > BE>> Modified: > BE>> head/sys/kern/kern_shutdown.c > BE> > BE>That would be a bug in clang if it were done for static symbols generally, > BE>but here the bug seems to be that the symbol is not declared as __used. > > I don't get this. Why should a symbol declared static be in the symbol > table (except for debugging purposes) ? It must be there for debugging purposes and historical compatibility (mainly other debugging uses, including kvm). Static symbols are not really special here. The C standard doesn't even require a symbol table, and it is only implementation details and debugging and historical compatibility that require putting global symbols in symbol tables. > It has internal linkage and so has > a meaning only in the given file. What is the linker supposed to do with > several static symbols with the same name from several object files? Same as it always did. The names are in per-object-file namespaces for the linker, so they don't conflict for linking, but they mess up primitive debuggers starting with nm. > If > several files declared static dumptids, which one would kldsym be supposed > to return? libkvm and kldsym would be broken. I don't know of any even non-primitive debuggers that can handle this. In gdb the only way that I know of to print a non-unique variable is to display the source file that declares the variable using something like `l' on a function in that file; the variable scope is then that of the selected file. The address "file.c:foo" only works for displaying functions. The latter probably depends on a full symbol table. When there is no symbol table, `l' of course doesn't work; `disass foo" works. "disass file.c:foo" of course doesn't work. "disass file.o:foo" should work, but doesn't, even when there is a full symbol table. When the "file.*:" address doesn't work, this is is initially because it misparsed as the symbol "file". Actually, I know of the primitive way which works even using ddb with all symbols broken in ddb, and have had to use this several times: you find the address of things using nm or something less primitive on another system, and guess which address to use if several variables have the same name, and type it in. BTW, kernels have lots of conflicting symbols which mess up debugging using primitive debuggers like ddb. /usr/src/tools/tools/kernxref/kernxref.sh was supposed to be used to find and fix these as well as finding and fixing public variables that should be static, but it is rarely used. uniq reports removing 382 out of 28443 (non-unique) symbols in a fairly current kernel with not many features configured. Bruce