Geoff Chappell - Software Analyst
This option asks to dump the Section Contribution Map, if available, else an extract from the COFF Symbol Table.
No arguments are anticipated. The option is /map only.
This option applies to executables in PE format and to debug files.
The Section Contribution Map can come only from a PDB file that matches the input file. It lays out the executable image as a succession of contributions from the modules (object files, etc) that the executable was linked from. Each contribution has an address and size, a record of the contributing module, and section characteristics (the same as in a section header).
DUMPBIN has no direct knowledge of the Section Contribution Map as data in a PDB. The work of finding a matching PDB and of enumerating the section contributions falls to MSPDB70.DLL, which DUMPBIN calls through an undocumented interface.
The Section Contribution Map is more to DUMPBIN than just something to dump. DUMPBIN uses it to improve its disassemblies (enabled by the /disasm option). With section characteristics known on a finer scale than for whole sections, DUMPBIN can identify data that has been merged into a code section and can recognise code fragments that use an alternate instruction set.
If no Section Contribution Map is available, DUMPBIN looks instead to the COFF Symbol Table in the input file. From this, if present, DUMPBIN extracts something that it calls a Symbol Map. This too is a description of the executable image in terms of blocks, each with an address and a size.
DUMPBIN makes its own determination of these blocks. Each runs from one external symbol up to but not including the next in the same section, else to the end of the section.
For both maps, the usefulness of the dumps is reduced significantly by their not accounting for the Optimisation Map (OMAP). In terms of the OMAP , the addresses in both the Section Contribution Map and the Symbol Map, whether expressed as RVAs or as offsets in sections, are source addresses. They are generally not the addresses in the optimised executable.
DUMPBIN is well aware that symbolic information is recorded in terms of OMAP source addresses. Its code to look up the symbol for an address in the executable first feeds the address through the “to source” OMAP. Unfortunately, when DUMPBIN seeks symbols for addresses in the Section Contribution Map or the Symbol Map, it still puts them through the “to source” OMAP, apparently not realising that they are already source addresses. Thus, the symbols that DUMPBIN shows for both the Section Contribution Map and the Symbol Map will generally be wrong, if the executable has an OMAP.
Something similar affects the Symbol Map. A block that begins with the last external symbol in a section runs to the end of that same section, but DUMPBIN uses the source address for the symbol but the actual address for the section. The computed size can be wildly implausible. For example, take EXPLORER.DBG for the free build of NT 4.0 (374,160 bytes, dated 14th October 1996) and run dumpbin /map explorer.dbg and see that the last line of the map tells of a block whose size is 4294963332 bytes.
A side-effect of the /map option is that the announcement of each input file goes to standard error, rather than to standard output or to whatever file is named for output via a /out option.
The /map option is apparently undocumented. If so, it is surely no oversight. In the option’s long history (being at least as old as version 3.00.5270, from Visual C++ 4.0), it has benefited from a significant enough upgrade of functionality, namely to support dumping the Section Contribution Map, that someone must have wondered about the change’s implications for the documentation.
Someone at Microsoft, some time, thought enough of the /map option to establish it in the master makefile that Microsoft uses for its own builds and publishes with its kits for writing NT device drivers. At least as far back as the NT 4.0 DDK, if the NTDUMPAMAP macro is defined, then a link -dump -map command is run after linking. That said, the output is piped to the sort command with a direction to sort (in reverse order) at column 62, which seems to have no particular relevance to the current layout of either the Section Contribution Map or Symbol Map. There are, of course, no comments.