xref: /openbsd-src/usr.sbin/procmap/procmap.1 (revision 850e275390052b330d93020bf619a739a3c277ac)
1.\"	$OpenBSD: procmap.1,v 1.11 2008/09/18 11:17:32 jmc Exp $
2.\"	$NetBSD: pmap.1,v 1.6 2003/01/19 21:25:43 atatat Exp $
3.\"
4.\" Copyright (c) 2002 The NetBSD Foundation, Inc.
5.\" All rights reserved.
6.\"
7.\" This code is derived from software contributed to The NetBSD Foundation
8.\" by Andrew Brown.
9.\"
10.\" Redistribution and use in source and binary forms, with or without
11.\" modification, are permitted provided that the following conditions
12.\" are met:
13.\" 1. Redistributions of source code must retain the above copyright
14.\"    notice, this list of conditions and the following disclaimer.
15.\" 2. Redistributions in binary form must reproduce the above copyright
16.\"    notice, this list of conditions and the following disclaimer in the
17.\"    documentation and/or other materials provided with the distribution.
18.\"
19.\" THIS SOFTWARE IS PROVIDED BY THE NETBSD FOUNDATION, INC. AND CONTRIBUTORS
20.\" ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
21.\" TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
22.\" PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL THE FOUNDATION OR CONTRIBUTORS
23.\" BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
24.\" CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
25.\" SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
26.\" INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
27.\" CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
28.\" ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
29.\" POSSIBILITY OF SUCH DAMAGE.
30.\"
31.Dd $Mdocdate: September 18 2008 $
32.Dt PROCMAP 1
33.Os
34.Sh NAME
35.Nm procmap
36.Nd display process memory map
37.Sh SYNOPSIS
38.Nm
39.Op Fl AadlmPsv
40.Op Fl D Ar number
41.Op Fl M Ar core
42.Op Fl N Ar system
43.Op Fl p Ar pid
44.Op Ar pid ...
45.Sh DESCRIPTION
46The
47.Nm
48utility lists the virtual memory mappings underlying the given
49process.
50The start address of each entry is always given, and,
51depending on the options given, other information such as the end
52address, the underlying file's device and inode numbers, and various
53protection information will be displayed, along with the path to the
54file, if such data is available.
55.Pp
56By default,
57.Nm
58displays information for its parent process, so that when run from a
59shell prompt, the shell's memory information is displayed.
60If other
61PIDs are given as arguments on the command line, information for those
62processes will be printed also.
63If the special PID of 0 is given,
64then information for the kernel's memory map is printed.
65.Pp
66The options are as follows:
67.Bl -tag -width XXXnumberXX
68.It Fl A
69Print more detailed information on anonymous map usage.
70.It Fl a
71Display
72.Dq all
73information from the process's memory map.
74This output
75mode is an amalgam of the contents of the Solaris, Linux, and
76.Ox
77style output modes.
78.It Fl D Ar number
79Enable various debug facilities.
80The
81.Ar number
82is a bit mask of the values:
83.Pp
84.Bl -tag -width flag -compact
85.It Cm 1
86dump the process's vmspace structure
87.It Cm 2
88dump the process's vm_map structure
89.It Cm 4
90dump the vm_map.header structure
91.It Cm 8
92dump each vm_map_entry in its entirety
93.It Cm 16
94dump the namei cache as it is traversed
95.El
96.It Fl d
97Dumps the vm_map and vm_map_entry structures in a style similar to
98that of
99.Xr ddb 4 .
100When combined with the
101.Fl v
102option, the device number, inode number, name, vnode addresses, or
103other identifying information from the vm_map_entry fields will be
104printed.
105.It Fl l
106Dumps information in a format like the contents of the maps
107pseudo-file under the
108.Pa /proc
109file system which was, in turn, modeled after the similarly named entry
110in the Linux
111.Pa /proc
112file system.
113When combined with the
114.Fl v
115option, identifiers for all entries are printed.
116.It Fl M Ar core
117Extract values associated with the name list from the specified core
118instead of the default
119.Pa /dev/kmem .
120.It Fl m
121Dumps information in the same format as the map pseudo-file of the
122.Pa /proc
123file system.
124When the
125.Fl v
126option is also given, device number, inode number, and filename
127or other identifying information is printed.
128.It Fl N Ar system
129Extract the name list from the specified system instead of the
130running kernel.
131.It Fl P
132Causes
133.Nm
134to print information about itself.
135.It Fl p Ar pid
136Tells
137.Nm
138to print information about the given process.
139If
140.Fl p Ar pid
141occurs last on the command line, the
142.Fl p
143is optional.
144.\" .It Fl R
145.\" Recurse into submaps.
146.\" In some cases, a vm_map_entry in the kernel
147.\" will point to a submap.
148.\" Using this flag tells
149.\" .Nm
150.\" to print the entries of the submap as well.
151.\" The submap output is
152.\" indented, and does not affect any total printed at the bottom of the
153.\" output.
154.It Fl s
155The Solaris style output format, modeled after the Solaris command
156.Dq pmap .
157This is the default output style.
158.It Fl v
159Verbose output.
160When used with
161.Fl d ,
162.Fl l ,
163or
164.Fl m ,
165more information is printed, possibly including device and inode
166numbers, file path names, or other identifying information.
167If specified more than once, a
168.Sq *
169will be printed in between two
170entries that are not adjacent, making the visual identification of
171spaces in the process's map easier to see.
172.El
173.Pp
174The
175.Fl P
176and
177.Fl p
178options override each other, so the last one to appear on the command
179line takes effect.
180If you do wish to see information about
181.Nm
182and another process as the same time, simply omit the
183.Fl p
184and place the extra PID at the end of the command line.
185.Pp
186.Nm
187exits 0 on success, and \*(Gt0 if an error occurred.
188.Sh EXAMPLES
189While the meaning most of the output is self-evident, some pieces of
190it may appear to be a little inscrutable.
191.Pp
192Here a portion of the default output from
193.Nm
194being run at a
195.Xr sh 1
196prompt shows the starting address of the map entry, the size of the
197map entry, the current protection level of the map entry, and either
198the name of the file backing the entry or some other descriptive text.
199.Bd -literal -offset indent
200$ procmap
20108048000    420K read/exec         /bin/sh
202080B1000      8K read/write        /bin/sh
203080B3000     28K read/write          [ anon ]
204080BA000     16K read/write/exec     [ heap ]
205\&...
206.Ed
207.Pp
208When the
209.Xr ddb 4
210output style is selected, the first thing printed is the contents of
211the vm_map structure, followed by the individual map entries.
212.Bd -literal -offset indent
213$ procmap -d
214MAP 0xcf7cac84: [0x0-\*(Gt0xbfbfe000]
215        #ent=8, sz=34041856, ref=1, version=20, flags=0x21
216        pmap=0xcf44cee0(resident=\*(Ltunknown\*(Gt)
217 - 0xcfa3a358: 0x8048000-\*(Gt0x80b1000: obj=0xcf45a8e8/0x0, amap=0x0/0
218        submap=F, cow=T, nc=T, prot(max)=5/7, inh=1, wc=0, adv=0
219\&...
220.Ed
221.Pp
222The value of the flags field (in hexadecimal) is taken from
223the include file
224.Aq Pa uvm/uvm_map.h :
225.Bl -column VM_MAP_WIREFUTURE VM_MAP_WIREFUTURE -offset indent
226.It Dv "VM_MAP_PAGEABLE"   Ta No "0x01   ro: entries are pageable"
227.It Dv "VM_MAP_INTRSAFE"   Ta No "0x02   ro: interrupt safe map"
228.It Dv "VM_MAP_WIREFUTURE" Ta No "0x04   rw: wire future mappings"
229.It Dv "VM_MAP_BUSY"       Ta No "0x08   rw: map is busy"
230.It Dv "VM_MAP_WANTLOCK"   Ta No "0x10   rw: want to write-lock"
231.El
232.Pp
233The
234.Dq submap ,
235.Dq cow ,
236and
237.Dq nc
238fields are true or false, and indicate whether the map is a submap,
239whether it is marked for copy on write, and whether it needs a copy.
240The
241.Dq prot
242(or protection) field, along with
243.Dq max
244(maximum protection allowed) are made up of the following flags from
245.Aq Pa uvm/uvm_extern.h :
246.\" this column width specifically chosen so that all the header file
247.\" excerpts appear to line up cleanly
248.Bl -column VM_MAP_WIREFUTURE VM_MAP_WIREFUTURE -offset indent
249.It Dv "UVM_PROT_READ"  Ta No "0x01   read allowed"
250.It Dv "UVM_PROT_WRITE" Ta No "0x02   write allowed"
251.It Dv "UVM_PROT_EXEC"  Ta No "0x04   execute allowed"
252.El
253.Pp
254The
255.Dq obj
256and
257.Dq amap
258fields are pointers to, and offsets into, the underlying uvm_object or
259vm_amap object.
260The value for resident is always unknown because digging such
261information out of the kernel is beyond the scope of this application.
262.Pp
263The two output styles that mirror the contents of the
264.Pa /proc
265file system
266appear as follows:
267.Bd -literal -offset indent
268$ procmap -m
2690x8048000 0x80b1000 r-x rwx COW NC 1 0 0
2700x80b1000 0x80b3000 rw- rwx COW NC 1 0 0
2710x80b3000 0x80ba000 rw- rwx COW NNC 1 0 0
2720x80ba000 0x80be000 rwx rwx COW NNC 1 0 0
273\&...
274
275$ procmap -l
27608048000-080b1000 r-xp 00000000 00:00 70173     /bin/sh
277080b1000-080b3000 rw-p 00068000 00:00 70173     /bin/sh
278080b3000-080ba000 rw-p 00000000 00:00 0
279080ba000-080be000 rwxp 00000000 00:00 0
280\&...
281.Ed
282.Pp
283Here the protection and maximum protection values are indicated with
284.Sq r ,
285.Sq w ,
286and
287.Sq x
288characters, indicating read permission, write permission, and execute
289permission, respectively.
290The
291.Dq COW ,
292.Dq NC ,
293and
294.Dq NNC
295values that follow indicate, again, that the map is marked for copy on
296write and either needs or does not need a copy.
297It is also possible
298to see the value
299.Dq NCOW
300here, which indicates that an entry will not be copied.
301The three
302following numbers indicate the inheritance type of the map, the wired
303count of the map, and any advice value assigned via
304.Xr madvise 2 .
305.Pp
306In the second form, the permissions indicated are followed by a
307.Sq p
308or
309.Sq s
310character indicating whether the map entry is private or shared (copy
311on write or not), and the numbers are the offset into the underlying
312object, the device and numbers of the object if it is a file, and the
313path to the file (if available).
314.Pp
315As noted above (see section
316.Sx DESCRIPTION ) ,
317the
318.Dq all
319output format is an amalgam of the previous output formats.
320.Bd -literal -offset indent
321$ procmap -a
322Start    End         Size  Offset   rwxpc  RWX  I/W/A ...
32308048000-080b0fff     420k 00000000 r-xp+ (rwx) 1/0/0 ...
324\&...
325.Ed
326.Pp
327In this format, the column labeled
328.Dq rwxpc
329contains the permissions for the mapping along with the shared/private
330flag, and a character indicating whether the mapping needs to be
331copied on write
332.Pq Sq +
333or has already been copied
334.Pq Sq -
335and is followed by a column that indicates the maximum permissions for
336the map entry.
337The column labeled
338.Dq I/W/A
339indicates the inheritance, wired, and advice values for the map entry,
340as previously described.
341.Sh SEE ALSO
342.Xr ls 1 ,
343.\" .Xr stat 1 ,
344.Xr madvise 2 ,
345.Xr mmap 2 ,
346.Xr kvm 3 ,
347.Xr ddb 4 ,
348.Xr mount_procfs 8 ,
349.Xr namei 9 ,
350.Xr vnode 9
351.Sh HISTORY
352The
353.Nm
354utility first appeared in
355.Ox 3.5 .
356It was derived from the
357.Nx
358utility known as
359.Dq pmap .
360.Sh AUTHORS
361The
362.Nm
363utility and documentation was written by
364.An Andrew Brown Aq atatat@netbsd.org .
365.Sh BUGS
366Very little will work unless
367.Nm
368is reading from the correct kernel in order to retrieve the
369proper symbol information.
370.Pp
371Since processes can change state while
372.Nm
373is running, some of the information printed may be inaccurate.
374This is especially important to consider when examining the kernel's map,
375since merely executing
376.Nm
377will cause some of the information to change.
378.Pp
379The pathnames to files backing certain vnodes (such as the text and
380data sections of programs and shared libraries) are extracted from the
381kernel's namei cache which is considerably volatile.
382If a path is not
383found there in its entirety, as much information as was available
384will be printed.
385In most cases, simply running
386.Xr ls 1
387.\" or
388.\" .Xr stat 1
389with the expected path to the file will cause the information to be
390reentered into the cache.
391.Pp
392The Solaris version
393.Pq Dq pmap
394has some interesting command line flags that would be nice to emulate here.
395In particular, the
396.Fl r
397option that lists a process's reserved addresses, and the
398.Fl x
399option that prints resident/shared/private mapping details for each
400entry.
401.Pp
402Some of the output modes can be or are wider than the standard 80
403columns of a terminal.
404Some sort of formatting might be nice.
405