Date: Wed, 30 Dec 1998 14:25:47 +0800 From: Peter Wemm <peter@netplex.com.au> To: committers@FreeBSD.ORG Subject: kvm_nlist emulation of n_type from kld symbol table at runtime. Message-ID: <199812300625.OAA84600@spinner.netplex.com.au>
next in thread | raw e-mail | index | archive | help
Nutshell: Can anybody forsee the need to export symbol type to userland? Now for the details.. :-) The in-kernel linker keeps a small symbol table (of global symbols only for a stripped kernel). This is used for loading and unloading, to provide DDB with lookup capabilities, etc. Obviously, with a massively modular kernel (something we don't have yet, and hopefully we won't go overboard on), doing a kvm_mkdb(8) on /kernel at boot time and having kvm_nlist() read those is going to become rather useless rather quickly. The obvious solution is to provide access to the current symbol table to userland. However, the symbol table is an opaque entity within the kernel (it's kept in native format by the per-object format handlers). To get to the information, it's exported in a generic format. To date, this data contains value and size, and not type. (global, weak, text/data/bss etc). This is a problem for emulating kvm_nlist() from this information, as it provides an a.out n_type value. After having looked over the tree, we do not look at the contents of n_type (from kvm_nlist) at all other than as a 'was this symbol found?' boolean value. My initial thoughts were to just set it to an arbitary value (N_TXT | N_EXT) if it's defined, or 0 if not. However... what's in the tree now isn't necessarily a good indication of what will be needed later. And it doesn't give enough information to do a realistic nm-like symbol dump of the running kernel. (since kvm_mkdb will become useless over time, so will "nm /kernel | sort | more".) Because unstripped symbol tables are full of assorted junk, this might be needed. We need a replacement for the nm functionality, perhaps something like "kldsymdump | sort | more" that shows the usual nm-like info. So, perhaps it isn't enough after all.. Perhaps some sort of type value is needed after all, that can at least seperate text/data/etc from the misc junk that turns up in an unstripped kernel. Perhaps even a containing object number should be included so that we can see which symbol comes from what file - although this should be obvious when comparing against load addresses. Any constructive comments would be appreciated. :-) Cheers, -Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199812300625.OAA84600>