There are lots of helpful tips, so leave this dialog on for a while until you get to know the Visual Linker.
There's a tutorial to help you learn the Visual Linker. Select 'Tutorial' from the 'Help' menu to run the tutorial.
Many operations are available from the right mouse button. Take a moment to right-click on some items and look at the different context menus.
You may customize the Visual Linker in many ways using Edit->Options.
It's often useful turn on verbose "INFO" messages using Edit->Options in order to get hints and explanations.
A RECIPE (for an application build) is made up of INGREDIENTS (input file list, hardware description) and DIRECTIONS (strategy on how to combine the ingredients).
Recipes and strategies use relative file paths. They may be shared between users, as long as referenced directory subtree shapes are the same.
Recipes and strategies may be shared between UNIX and DOS. Paths and names are automatically converted by the Visual Linker on input.
To display a description of icons and color assignments, right-click any item and select 'Legend' from the context menu.
You can sort the list view in different ways by clicking on the column headers. Additional clicks toggle between ascending and descending sorts.
A memory MAP contains a description of memory for a particular target system. In the memory descriptions provided with the Visual Linker, the MAP is named after the target board (e.g., EVM320LC549) or the processor core (e.g., C549).
A memory SPACE defines a processor's addressing capability within a memory map at a given time and for a given type. All targets have "run_view" and "load_view" spaces. Some targets have an additional layer containing spaces such as "program_memory" and "data_memory".
A RUN VIEW space is a view of a memory space at execution time. A LOAD VIEW of that space is the view of the same space at power-up time. These two views are different when code is placed in different locations for execution and power-up.
A memory REGION is a portion of a memory space that is populated with actual devices. The regions in the memory maps provided with the Visual Linker have names like "DARAM", "SARAM", "VECTORS", and "REGS".
You may add/delete/alter REGIONS from within the Visual Linker and your changes will be saved/restored with your recipe as a private .mem file.
When constructing a new memory description, it is best to start with the appropriate 'generic' description supplied with the Visual Linker.
The Visual Linker will model REGIONS shared between different SPACES (OVLY=1 for c54x, for example).  See Help->Contents->Using the Memory Description Files.
Artificially chopping memory into many regions is a way to enforce "hard" boundaries, but can result in fragmentation and maintenance problems. It's usually better to use min/max address constraints on nested output sections to accomplish the same thing.  See Help->Contents->Tips for Effective Allocation->Avoiding Memory Conflicts Without Fragmenting Memory.
The Not Yet Placed branches in the tree view show items that must be placed into memory regions before a legal executable can be generated.
The Not Yet Placed branch in a run_view memory space is automatically populated by finding all items reachable from a set of required roots. To specify that an item is a root, right-click it and select 'Required'. Items not already reachable can be found in the Input Files subtree.
An item can be placed into a memory region by simply dragging the icon for the item to the icon representing the region.
Multiple items may be selected in the list view using all the standard conventions (Shift+left-click, Ctrl+left-click, Ctrl+a ... etc.).
With multiple-selection placement, the Visual Linker may be configured to record either general rules (e.g., "all the code") or a list of the individual items involved.  Rules are more resilient to change, but require careful maintenance.  Lists require more frequent but simpler maintenance.
You should perform placement using multiple-selection as much as possible. This helps the Visual Linker construct a much more resilient link strategy. It's the difference between "all the code" vs. "a/.text then b/.text then c/.text". The former will survive more changes over time.
A scale picture of any item is available by right-clicking on the item and selecting 'Display This Memory'. As you place items in memory, change the picture to focus on that part of memory. There are entirely different pictures for each of the spaces (program_memory vs. data_memory ... etc).
The Memory view (picture) may be used interchangeably with the tree and list views for all operations including drag and drop.
Selecting an item in the Memory view causes it to be selected in the tree view as well. And vice versa.
The little slash marks in the Memory view picture indicate a discontinuity in the scale. A very clever algorithm has determined that there's nothing interesting to display at this point.
You can adjust the appearance of the Memory view. Right-click on it and select 'Display Controls'.
Adjustment of the Memory view can also be done with accelerator keys. These accelerators all use the number pad keys in conjunction with the Ctrl key.
If you position the mouse over an item in the Memory view, a tool tip appears containing the name of the item, its boundaries and the comment that is currently attached to the item.  To change/add a comment: right-click the item, select 'Properties' and then choose the 'Comment' tab.
A pretty pie chart showing available memory is available by right-clicking on a memory region or output section, selecting 'Properties' and then selecting the 'Usage' tab.
To quickly find an item, go to the tree view and right-click on the subtree that you want to search. Select 'Find' and supply the name and/or type of the item.
The Not Yet Placed branch in a load_view memory space is automatically populated by finding all initialized items (code and constants, but NOT variables) in the corresponding run_view space.
You should empty the Not Yet Placed branch from the run_view space before dealing with the corresponding load_view space.
An INPUT SECTION is a grouping of bits in an input object file. Object files are generated by compilers, assemblers, and linkers. Input sections have a data kind describing what the bits represent (code, variables, constants ... etc).
You can find the list of items reachable from an input section (or symbol) by right-clicking the section (symbol) and selecting 'References'. You may drag from the displayed list of results.
When you use a single drag-and-drop to move all items of a particular type from the References display, the Visual Linker records the action as a single resilient rule ("all code sections reachable from X") instead of moves of each the individual sections involved.
An OUTPUT SECTION is a grouping of input sections, symbols and other output sections.
Output Sections may be nested to arbitrary levels.
Children of COLLECTION-allocation output sections are placed in memory in an order determined by the Visual Linker.
Children of STRUCTURE-allocation output sections are placed in memory in an order specified by the user.
All children of UNION-allocation output sections are placed in memory at offset 0 from the start of the output section. This is useful for constructing overlays.
To sort the children of a structure-allocation output section, right-click the section, select 'Properties' and then the 'Children' tab. Select an item by clicking on it and then click on 'Move Up' or 'Move Down' to move that item to a different position in the list. 
For some targets the ".bss" output section is automatically constructed by the Visual Linker. It holds all reachable input sections with base name ".bss". These sections may only be moved to other .bss output sections. The .bss output section holds global variables.
The ".cinit" output section is automatically constructed by the Visual Linker. It holds all reachable input sections with base name ".cinit". These sections may not be moved from it. The .cinit output section holds start-up initialization constants.
The ".stack" output section is automatically constructed by the Visual Linker. It holds all reachable input sections with base name ".stack". These sections may not be moved from it. The .stack output section is an empty section used to reserve space for the main program stack.
To change the size of the main program stack, right-click the .stack output section, select 'Properties' and then select the 'Size' tab.
To ask that the stack be given all remaining locations in the region to which it is assigned, right-click the .stack output section, select 'Properties' and then select the 'Size' tab. Set the Maximum Size to a big number and check the Maximize option.
As items are moved and altered, the actions are recorded and become the link strategy.
Items are placed in memory using drag and drop. Operations (other than placement) are performed using the right mouse button.
Placing an item into a run view space causes it to be automatically placed in the same location in the corresponding load view space (if it is initialized and currently has no assignment in the load view space). And vice versa.
If a memory region fills up, you may specify where the overflow from any given output section is to be sent. Right-click on the output section, select 'Properties' and then select the 'Overflow' tab.
The Visual Linker supports "Undo" and "Redo" operations under the "Edit" menu. Both work to arbitrary levels. 
You can view, debug, and edit the strategy from the "Strategy" window, which can be opened using Edit->Debug Strategy.
Strategy debug capabilities available from the "Strategy" window include Restart, Set/Clear Breakpoint, Run, and Single-Step.
Strategy instructions may be deleted, inserted, and re-ordered from the "Strategy" window.
When deleting large numbers of strategy instructions, it is faster to first click 'Restart'. After finishing the deletions, click 'Run' to re-run the resultant strategy.
To insert a forgotten or missed operation, open the Strategy window and click the Restart button. Single-step to the desired insertion point and then perform the operation using the usual drag-and-drop actions.
The unallocated portions of memory are called HOLES.
Memory holes may be automatically filled with some identifying pattern by right-clicking on an output section, a region or a space. Select 'Properties' and then select the 'Fill' tab.
Fill patterns have scope. The fill pattern from the nearest enclosing item is always used. If that item has no fill specified, the search continues with the next-outermost enclosing item.
To insert a hole of some specified size into a particular structure-allocation output section, use an empty output section with a minimum size specification.
The "Information" window displays messages describing results and side effects of the operations performed.
The Visual Linker prevents most user errors from happening by dynamically determining which operations are erroneous at any given time and making these inaccessible to the user. Errors that cannot be prevented are displayed in the "Information" window.
You can control alignment of an output section by right-clicking on the section, selecting 'Properties' and then selecting the 'Run Alignment' tab.
You can insure that an output section does not cross certain memory boundaries by right-clicking on the section and then selecting the 'Spanning' tab.
You may force allocation of an output section to an absolute address. Right-click the section, select 'Properties' and then select the 'Run Alignment' tab.
The alignment and spanning specifications of an input section may not be altered. To achieve this effect, make the input section the only child of an output section and specify alignment and spanning restrictions in the parent.
An absolute address alignment of an output section may be expressed either as a constant or as a C expression. The expression is re-evaluated whenever any of its operands change.
Expressions used for absolute address specifications may include a variety of built-in functions that return properties of the Visual Linker items, such as address and size. The "Expression Editor" window contains a wizard for constructing builtin function calls.
Global output symbols may be defined as children of the "Link-Time Absolute Syms", regions, output sections and other output symbols. Right click the parent item and select 'New Symbol'.
The default "value" of a symbol with a region, output section or symbol parent is the run-space address corresponding to the offset of the symbol into its parent.
The offset or value of an output symbol may be expressed either as a constant or as a C expression. The expression is re-evaluated whenever any of its operands change.
Expressions used for symbol offset (value) specifications may include a variety of built-in functions that return properties of the Visual Linker items, such as address and size. The "Expression Editor" window contains a wizard for constructing builtin function calls.
The RECIPE (root item in the tree view) is the right place to keep your title and change log comments.  To change/add a comment to any item: right-click the item, select 'Properties' and then choose the 'Comment' tab.
When using vlnk with a .cmd file, the new option '-dead' will eliminate from the linked image all code and data not reachable from either the main entry point (specified with -e) or the interrupt vectors (specified with -vector).
The Visual Linker is capable of eliminating dead code at the granularity of a section.  However, normally TI compilers place all routines from a file into a single section, making it impossible to eliminate any one routine in the file.  To allow the Visual Linker to find more dead code, place functions one per file or use #pragma CODE_SECTION(fn_name, ".text:fn_name") to get each routine into its own section.
