Date: Wed, 30 Dec 1998 15:07:43 +0800 From: Peter Wemm <peter@netplex.com.au> To: Darren Reed <darrenr@reed.wattle.id.au> Cc: phk@FreeBSD.ORG, committers@FreeBSD.ORG Subject: Re: kvm_nlist emulation of n_type from kld symbol table at runtime. Message-ID: <199812300707.PAA84781@spinner.netplex.com.au> In-Reply-To: Your message of "Wed, 30 Dec 1998 17:45:09 %2B1100." <199812300645.RAA16732@avalon.reed.wattle.id.au>
next in thread | previous in thread | raw e-mail | index | archive | help
Darren Reed wrote:
>
> If you're exporting symbols through something like a /dev/ksyms where
> you can do "nm /dev/ksyms" and get a human-readable listing of the in-kernel
> table, then n_type is essential (for obvious reasons).
Yes, I thought about that a few times and I'm fairly convinced that doing
a /dev/ksyms will be Really Hard (tm) and/or resource expensive given the
way things are presently implemented.
In a situation where there is a single loaded symbol table, this is easy.
However, we have multiple symbol tables and in multiple formats. At
present, I think the majority of cases have an a.out kernel symbol table
and ELF module symbols. A coherent symbol table would have to be
constructed, and that would take a large block of memory to do it in one
chunk... Otherwise making lseek()/read() work across a (say) 4K staging
buffer in kernel memory would be messy, especially when there is potential
for loads/unloads inbetween reads of the device.
I'm really not sure how to best get large synthetic blocks of data out to
the user. I know sysctl(2) has enough trouble.
Speaking of sysctl(), it's been suggested that I try and use it rather
than a syscall interface. I'm a little concerned about the implications
of that, but then again I don't understand the implementation that well.
As I understand it, for looking up a kernel symbol ("msgbuf"), a symbolic
name (kern.syms.msgbuf) would first be translated into a numeric OID via a
sysctl syscall. Then, the numeric OID would be looked up, and presumably
an opaque (to sysctl(2)) block would be returned for the caller to
interpret. If this is the case, then we hit the symbol tables in one call
to locate the symbol, and then later hit it again to get the value using
the previous key. If there is significant time in between the two calls
the address found previously could change.
Of course, I could be underestimating sysctl(2)'s capabilities. I suppose
there isn't much stopping a numeric OID lookup to start with, where the mib
number was actually an address of the symbol name to be copyinstr()'ed.
In this case too, it should be pretty simple to do address->name lookups.
If the second case is closer to reality, then presumably we can use the
sysctl() infrastructure to lock process memory while preparing a large
writeout in order to dump the symbol table... To do anything like this I
will need pointers and/or help. Poul-Henning?
> Darren
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?199812300707.PAA84781>