List Parser (Embedded Development Module)
The list (.lst) parser is a compiler-specific component. The example targets use a GCC-specific parser located in the following directory:
 | labview\vi.lib\LabVIEW Targets\Embedded\Debug\Map\GCC |
You must implement your own list parser if your compiler cannot generate the list file in a compatible stabs format. If your compiler cannot generate the list file to map lines of compiled source code into relative symbol addresses, you cannot support breakpoints in the pure On Chip debugging mode. You can still build embedded applications in the On Chip (Release) debugging mode. The On Chip (Release) mode implements the OCDI_Checkpoint macro, so the running embedded application must evaluate simple checkpoint expressions every time the application approaches a possible LabVIEW breakpoint. The OCDI_Checkpoint macro is left blank for the pure On Chip debugging mode, which eliminates the need for the list parser, but slightly changes the timing of the embedded application.
 | Note The OCDI_Checkpoint macro is defined in LVDefs_plat.h. |
The list parser serves two primary purposes in populating the debug database and generating the LVM file. First, the list parser helps to resolve the lines of C code to series of relative offsets based on one or two variables. This map does not contain entries for lines for which the C compiler does not generate assembly code. Second, it populates data type alignment information that is specific to how the compiler handles the alignment of the LabVIEW data type structures.
The list parser determines which nodes and signals to locate by querying the debug database, which the C parser populates. The following example shows the LVM file for simple_math.vi after the signals and nodes have been resolved to a series of hexadecimal offsets. The memory locations are still only known relative to yet unresolved symbols. Absolute memory address information is not available at this phrase.
[simple_math.vi]
Node(1, 2, 3)@64=simple_math_Run+0x58
Node(2, 3, 3)@68=simple_math_Run+0x6C
SID_2360=simple_math_heap+0x0
SID_2212=simple_math_heap+0x8
SID_3104=simple_math_heap+0x10
SID_1988=simple_math_heap+0x18
SID_1332=simple_math_heap+0x20
The list parser also populates the debug database with information about the compiler byte packing. These descriptions are based on compiler-specific information, and are necessary so that the debug daemon knows which bytes correspond to the actual binary data value of the control or signal. If you are sure that the compiler alignment options are fixed and you are not providing that level of control to users, this information can be generated as a static string. The bold portion in the following example defines the Boolean data type.
[Offset_Table]
BigEndian=1
BooleanData=4
BooleanData.bInput=16, 8
BooleanData.bStatic=0, 8
BooleanData.bVal=8, 8
BooleanData.padding=1=24, 8
NumericData=12
NumericData.bInput=48,8
LVBoolean.h defines this data type in the following directory:
| labview\CCodeGen\include\frontpanel |
The members of the following C data structure mirrors those listed in the LVM file.
The syntax for the portion of the LVM file is as follows:
DataType=L
DataType.dataMember=j, k
where
j represents the offset from the beginning of the data structure in bits k represents the length of the data member in bits L represents the length of the entire data type in bytesRepeat the process for each data type.
In addition, the LVM file needs information from the LabVIEW project to completely decouple the LabVIEW development environment and the debugging interface.
BigEndian=x
ReleaseDebugMode=x
where x represents 1 or 0 based on the information from the LabVIEW project.