Xref: utzoo comp.sys.att:7228 unix-pc.general:3522
Path: utzoo!utgpu!watmath!uunet!tut.cis.ohio-state.edu!rutgers!dptg!mtunb!jcm
From: jcm@mtunb.ATT.COM (was-John McMillan)
Newsgroups: comp.sys.att,unix-pc.general
Subject: Re: Getting symbols from /etc/lddrv/wind (was Re: sockets & ptys)
Message-ID: <1601@mtunb.ATT.COM>
Date: 8 Aug 89 11:51:33 GMT
References: <637@holin.ATT.COM> <2229@umbc3.UMBC.EDU> <945@icus.islp.ny.us>
Reply-To: jcm@mtunb.UUCP (John McMillan)
Organization: AT&T ISL Middletown NJ USA
Lines: 19

In article <945@icus.islp.ny.us> lenny@icus.islp.ny.us (Lenny Tropiano) writes:
:
>Why not use nlist(3C)?  That's what it was made for!   All you need
>to do is to set up a struct nlist with all the symbols (assuming you know
>the symbol name [which can be gotten with nm or looking at the ifile.wind])
>you need and then call nlist("/etc/lddrv/wind",&nl) ...
>
>The symbol and their appropriate addresses are returned right there
>for you.  Then you can do what you need with them ...

For speed purposes, you may choose to ALSO keep a binary file with the
info.  AFTER confirming it is more recent in mtime than /etc/lddrv/wind,
you can save considerable time just picking it rather than re-scanning
the name list -- the kernel name list is vastly larger than it should be.

Alternatively, you can scratch the binary file on re-boots, and build it each
first-time it's used -- like most SAR implementations, if I recall correctly.

john mcmillan	-- att!mtunb!jcm	-- mindless sexist GROWLER....