Date: Wed, 23 May 2012 04:03:08 +1000 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Hartmut Brandt <hartmut.brandt@dlr.de> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Hartmut Brandt <harti@freebsd.org>, Bruce Evans <brde@optusnet.com.au> Subject: Re: svn commit: r235777 - head/sys/kern Message-ID: <20120523023228.L2766@besplex.bde.org> In-Reply-To: <alpine.BSF.2.00.1205221359070.7484@KNOP-BEAGLE.kn.op.dlr.de> References: <201205220723.q4M7Ng2I091715@svn.freebsd.org> <20120522212307.V1971@besplex.bde.org> <alpine.BSF.2.00.1205221359070.7484@KNOP-BEAGLE.kn.op.dlr.de>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120523023228.L2766>