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