pagestuff file [-arch arch_flag] [-a] [-p] [pagenumber…]
Information about the specified logical pages of file in Mach-O executable format.
For each specified page of code, symbols (function and static data structure names) are displayed.
If no pages are specified, symbols for all pages in the __TEXT section are displayed.
In the following examples a small C program was compiled to a.out in only Mach-O 64-bit executable x86_64.
-arch arch_type |
vmmap [-w[ide]] [-v[erbose]] [-resident] [-dirty] [-swapped] [-purge] [-submap][-allSplitLibs] [-noCoalesce]
[-interleaved] [-pages] [-summary] pid | partial-executable-name
Displays the virtual memory regions allocated in a specified process, helping a programmer understand how memory is
being used, and what the purposes of memory at a given address may be.
The process can be specified by process ID or by full or partial executable name.
-w |
-verbose
The first column names the purpose of the memory: malloc regions, stack, text, data segment, etc.
vm_allocate reserves pages, but they won't be allocated until touched.
The share mode typically describes the general mode controlling the region. For example, as copy-on-write pages are modified, they become private to the application. Even with the private pages, the region is still COW until all pages
become private. Once all pages are private, then the share mode would change to private.
For regions loaded from binaries, the far right shows the library loaded into the memory.
For example, one submap contains the read-only portions of the most common dynamic libraries. These libraries are needed by most programs on the system, and because they are read-only, they will never be changed. As a result, the operating system shares these pages between all the processes, and only needs to create a single data structure to describe how this memory is laid out in every process.
That section of memory is referred to as the "split library region", and it is shared system-wide. So, technically, all of the dynamic libraries that have been loaded into that region are in the VM map of every process, even though some pro- cesses may not be using some of those libraries. By default, vmmap shows only those shared system split libraries that have been loaded into the specified target process. If the -allSplitLibs flags is given, information about all shared system split libraries will be printed, regardless of whether they've been loaded into the specified target process or not.
If the contents of a machine-wide submap are changed -- for example, the debugger makes a section of memory for a dylib writable so it can insert debugging traps -- then the submap becomes local, and the kernel will allocate memory to store the extra copy.
heap, leaks, and malloc_history commands display aspects of a process's memory usage.
> heap
Usage: heap [-guessNonObjects] [-sumObjectFields] [-showSizes] [-addresses all | classes-pattern] [-noContent] pid
-guessNonObjects try to identify non-object malloc nodes which are referenced by fields of other objects
-sumObjectFields accumulate those fields into the entry for that object
-showSizes show distribution of each malloc size for each object, instead of summing and averaging
-addresses=all|matching-pattern outputs the addresses of matching objects found on the heap in ascending address order
-noContent do not show object content in -addresses mode
> leaks
leaks: Search through a process for leaked memory.
Usage: leaks [-hq] [--nocontext] [--nostacks] pid/partial-process-name [--trace address>]
-e/--exclude sym exclude leaked blocks whose backtraces include the specified symbol
-q/--quiet suppress the process description header and footer
--nocontext do not output the binary contexts of discovered leaks
--nostacks do not output backtraces, even when available
--trace=address output chains of references from process 'roots' (e.g., global data) to the given block
> malloc_history
malloc_history: Displays/aggregates allocation histories in a process
Usage: malloc_history pid/partial-process-name [options] mode [address ...]
'mode' should be one of {-callTree, -allBySize, -allByCount, -allEvents, or one or more addresses}
-allBySize [mode]
-allByCount [mode]
-allEvents [mode]
-callTree [mode]
-highWaterMark
-showContent (-calltree only)
-invert (-calltree only)
-ignoreThreads (-calltree only)
-collapseRecursion (-calltree only)
-chargeSystemLibraries (-calltree only)
-consolidateAllBySymbol (-calltree only)
-consolidateSystemFramesBySymbol (-calltree only)
lsof can be used to get a list of open and mapped files in one or more processes, which can help determine
why a volume can't be unmounted or ejected.
The Xcode developer tools include Instruments, a graphical application that gives similar information.
Allocations graphically displays dynamic, real-time information about the object and
memory use in an application (including VM allocations), as well as backtraces of where the allocations occured. VM Tracker in the Allocations template graphically displays information about the virtual memory regions in a process.
NXGetAllArchInfos, NXGetLocalArchInfo, NXGetArchInfoFromName, NXGetArchInfoFromCpuType, NXFindBestFatArch,
NXCombineCpuSubtypes -- get architecture information
#include
extern const NXArchInfo *
NXGetAllArchInfos(void);
extern const NXArchInfo *
NXGetLocalArchInfo(void);
extern const NXArchInfo *
NXGetArchInfoFromName(const char *name);
extern const NXArchInfo *
NXGetArchInfoFromCpuType(cpu_type_t cputype, cpu_subtype_t cpusubtype);
extern struct fat_arch *
NXFindBestFatArch(cpu_type_t cputype, cpu_subtype_t cpusubtype, struct fat_arch *fat_archs, uint32_t nfat_archs);
extern cpu_subtype_t
NXCombineCpuSubtypes(cpu_type_t cputype, cpu_subtype_t cpusubtype1, cpu_subtype_t cpusubtype2);
Functions are for use in programs that have to deal with universal files or programs that can target multiple architectures.-arch name, where this
specifies an architecture. These functions and data structures provide some help for processing architecture flags and
then processing the contents .
The structure NXArchInfo is defined in <mach-o/arch.h>:
typedef struct {
const char *name;
cpu_type_t cputype;
cpu_subtype_t cpusubtype;
enum NXByteOrder byteorder;
const char *description;
} NXArchInfo;
It is used to hold the name of the architecture and the corresponding CPU type and CPU subtype, together with the architecture's byte order and a brief description string.
The currently known architectures are:
Name CPU Type CPU Subtype Description
x86_64 CPU_TYPE_X86_64 CPU_SUBTYPE_X86_64_ALL Intel x86-64
i386 CPU_TYPE_I386 CPU_SUBTYPE_I386_ALL Intel 80x86
arm CPU_TYPE_ARM CPU_SUBTYPE_ARM_ALL ARM
arm64 CPU_TYPE_ARM64 CPU_SUBTYPE_ARM64_ALL ARM64
ppc CPU_TYPE_POWERPC CPU_SUBTYPE_POWERPC_ALL PowerPC
ppc64 CPU_TYPE_POWERPC64 CPU_SUBTYPE_POWERPC64_ALL PowerPC 64-bit
m68k CPU_TYPE_MC680x0 CPU_SUBTYPE_MC680x0_ALL Motorola 68K
hppa CPU_TYPE_HPPA CPU_SUBTYPE_HPPA_ALL HP-PA
i860 CPU_TYPE_I860 CPU_SUBTYPE_I860_ALL Intel 860
m88k CPU_TYPE_MC88000 CPU_SUBTYPE_MC88000_ALL Motorola 88K
sparc CPU_TYPE_SPARC CPU_SUBTYPE_SPARC_ALL SPARC
i486 CPU_TYPE_I386 CPU_SUBTYPE_486 Intel 486
i486SX CPU_TYPE_I386 CPU_SUBTYPE_486SX Intel 486SX
pentium CPU_TYPE_I386 CPU_SUBTYPE_PENT Intel Pentium
i586 CPU_TYPE_I386 CPU_SUBTYPE_586 Intel 586
pentpro CPU_TYPE_I386 CPU_SUBTYPE_PENTPRO Intel Pentium Pro
i686 CPU_TYPE_I386 CPU_SUBTYPE_PENTPRO Intel Pentium Pro
pentIIm3 CPU_TYPE_I386 CPU_SUBTYPE_PENTII_M3 Intel Pentium II Model 3
pentIIm5 CPU_TYPE_I386 CPU_SUBTYPE_PENTII_M5 Intel Pentium II Model 5
pentium4 CPU_TYPE_I386 CPU_SUBTYPE_PENTIUM_4 Intel Pentium 4
armv4t CPU_TYPE_ARM CPU_SUBTYPE_ARM_V4T arm v4t
armv5 CPU_TYPE_ARM CPU_SUBTYPE_ARM_V5TEJ arm v5
xscale CPU_TYPE_ARM CPU_SUBTYPE_ARM_XSCALE arm xscale
armv6 CPU_TYPE_ARM CPU_SUBTYPE_ARM_V6 arm v6
armv6m CPU_TYPE_ARM CPU_SUBTYPE_ARM_V6M arm v6m
armv7 CPU_TYPE_ARM CPU_SUBTYPE_ARM_V7 arm v7
armv7f CPU_TYPE_ARM CPU_SUBTYPE_ARM_V7F arm v7f
armv7s CPU_TYPE_ARM CPU_SUBTYPE_ARM_V7S arm v7s
armv7k CPU_TYPE_ARM CPU_SUBTYPE_ARM_V7K arm v7k
armv7m CPU_TYPE_ARM CPU_SUBTYPE_ARM_V7M arm v7m
armv7em CPU_TYPE_ARM CPU_SUBTYPE_ARM_V7EM arm v7em
armv8 CPU_TYPE_ARM CPU_SUBTYPE_ARM_V8 arm v8
arm64 CPU_TYPE_ARM64 CPU_SUBTYPE_ARM64_V8 arm64 v8
ppc601 CPU_TYPE_POWERPC CPU_SUBTYPE_POWERPC_601 PowerPC 601
ppc603 CPU_TYPE_POWERPC CPU_SUBTYPE_POWERPC_603 PowerPC 603
ppc604 CPU_TYPE_POWERPC CPU_SUBTYPE_POWERPC_604 PowerPC 604
ppc604e CPU_TYPE_POWERPC CPU_SUBTYPE_POWERPC_604e PowerPC 604e
ppc750 CPU_TYPE_POWERPC CPU_SUBTYPE_POWERPC_750 PowerPC 750
ppc7400 CPU_TYPE_POWERPC CPU_SUBTYPE_POWERPC_7400 PowerPC 7400
ppc7450 CPU_TYPE_POWERPC CPU_SUBTYPE_POWERPC_7450 PowerPC 7450
ppc970 CPU_TYPE_POWERPC CPU_SUBTYPE_POWERPC_970 PowerPC 970
m68030 CPU_TYPE_MC680x0 CPU_SUBTYPE_MC68030_ONLY Motorola 68030
m68040 CPU_TYPE_MC680x0 CPU_SUBTYPE_MC68040 Motorola 68040
hppa7100LC CPU_TYPE_HPPA CPU_SUBTYPE_HPPA_7100LC HP-PA 7100LC
The first set of entries are used for the architecture family. The second set of entries are used for a specific architecture, when more than one specific architecture is supported in a family of architectures.
NXGetAllArchInfos() returns a pointer to an array of all known NXArchInfo structures. The last NXArchInfo is marked by a NULL name.
NXGetLocalArchInfo() returns the NXArchInfo for the local host, or NULL if none is known.
NXGetArchInfoFromName() and NXGetArchInfoFromCpuType() return the NXArchInfo from the architecture's name or CPU type/CPU subtype combination. A CPU subtype of CPU_SUBTYPE_MULTIPLE can be used to request the most general NXArchInfo known for the given CPU type. NULL is returned if no matching NXArchInfo can be found.
NXFindBestFatArch() is passed a CPU type and CPU subtype and a set of fat_arch structs. It selects the best one that matches (if any), and returns a pointer to that fat_arch struct (or NULL). The fat_arch structs must be in the host byte order and correct such that fat_archs really points to enough memory for nfat_archs structs. It is possible that this routine could fail if new CPU types or CPU subtypes are added and an old version of this routine is used. But if there is an exact match between the CPU type and CPU subtype and one of the fat_arch structs, this routine will always succeed.
NXCombineCpuSubtypes() returns the resulting CPU subtype when combining two different CPU subtypes for the specified CPU type. If the two CPU subtypes can't be combined (the specific subtypes are mutually exclusive), -1 is returned, indicating it is an error to combine them. This can also fail and return -1 if new CPU types or CPU subtypes are added and an old version of this routine is used. But if the CPU subtypes are the same, they can always be combined and this routine will return the CPU subtype passed in.