Coding pmap in Solaris

Question

I'm currently attempting to write my own program that mirrors the pmap command, specifically on Solaris 9. I'm having trouble resolving the names and paths of the libraries. Output of the Solaris command looks something like this, from a bash shell:

bash-2.05# pmap $$
2427:   bash
00010000     496K r-x--  /usr/bin/bash
0009A000      80K rwx--  /usr/bin/bash
000AE000     120K rwx--    [ heap ]
FF100000     688K r-x--  /usr/lib/libc.so.1
FF1BC000      24K rwx--  /usr/lib/libc.so.1
FF1C2000       8K rwx--  /usr/lib/libc.so.1
FF200000     568K r-x--  /usr/lib/libnsl.so.1
FF29E000      32K rwx--  /usr/lib/libnsl.so.1
FF2A6000      32K rwx--  /usr/lib/libnsl.so.1
FF2F0000       8K rwx--    [ anon ]
FF300000      16K r-x--  /usr/lib/libmp.so.2
FF314000       8K rwx--  /usr/lib/libmp.so.2
FF320000       8K r-x--  /usr/platform/sun4u-us3/lib/libc_psr.so.1
FF330000      40K r-x--  /usr/lib/libsocket.so.1
FF34A000       8K rwx--  /usr/lib/libsocket.so.1
FF350000     168K r-x--  /usr/lib/libcurses.so.1
FF38A000      32K rwx--  /usr/lib/libcurses.so.1
FF392000       8K rwx--  /usr/lib/libcurses.so.1
FF3A0000       8K r-x--  /usr/lib/libdl.so.1
FF3B0000       8K rwx--    [ anon ]
FF3C0000     152K r-x--  /usr/lib/ld.so.1
FF3F6000       8K rwx--  /usr/lib/ld.so.1
FFBFC000      16K rw---    [ stack ]
 total      2536K

I can mostly duplicate the program's basic features by reading /proc/$$/map, but what remains is figuring out how to resolve the library names, shown on the right. /proc/$$/map only gives the names of the files in /proc/$$/object, which are just generic names. On Solaris 10 (a box I have), I seem to be able to use /proc/$$/path, which contains symbolic links, but the box I'm working on doesn't have these. Does anyone have any straightforward ideas on how to get these library names? When I truss the program, it seems to open up /proc/$$/as and look through the memory and somehow find them, but I haven't been able to figure out where it's looking or why quite yet.

Answer 1

The Solaris implementation of pmap is actually available in source form via OpenSolaris,pmap.c. But this is very complex stuff; the basics are simpler to achieve.

Solaris has three /proc handles for maps:

1. /proc/<PID>/map which contains struct prmap data that reflects the "usual" working set size
2. /proc/<PID>/rmap which also contains struct prmap data but for the virtual set size (VSZ), i.e. reflecting mapped VA ranges even if the mapping is uncommitted.
3. /proc/<PID>/xmap which contains struct prxmap data, which actually trawls the address space to identify memory-resident regions.

The pmap utility looks into these when you pass either no args (map), -r (rmap) or -x (xmap), but as you've found it does a lot more than simply opening/reading the map proc files. That's largely what makes the sourcecode hard to parse.

Nonetheless, you can construct a trivial Solaris [rx]map (use struct prxmap instead of struct prmap if you access xmap of course) parser via code like:

char mappath[MAXPATHLEN];
sprintf(mappath, "/proc/%d/map", getpid());
int fd = open(mappath, O_RDONLY);
size_t nread;
size_t mapsz = (1 << 20);                 /* start at 1MB */
struct prmap *cur*mapbuf = malloc(mapsz);

while ((nread = pread(fd, mapbuf, mapsz, 0)) == mapsz) {
    free(mapbuf);
    mapsz *= 2;
    mapbuf = malloc(mapsz);
}
for (cur = mapbuf; nread; cur++, nread -= sizeof(*mapbuf))
    prettyprint(cur);
free(mapbuf);

A few hints:

• don't try to mmap() the map file, that won't work (procfs doesn't allow it)
• don't try to sequentially read parts of it; the above (re-reading the whole from the beginning into a resized buffer) is faster than doing a contiguous sequence of read(). Always read from the beginning (use pread as in the example, or lseek(..., 0, SEEK_SET) before any read).

Enjoy experimenting !

Edit:

Since you've set your mind on finding the pathnames behind mappings, that's one of the really difficult tasks. pmap doesn't deal with that itself but uses the facilities of libproc to resolve these names, which, as you've found by truss, may trawl through the process address space to extract these, but also uses a few other techniques. It's essentially the "iter" functions in libproc/Psymtab.c which do this. There's differences between Solaris 9 and later versions as well ... can't remember, too long ago ...