Role of the List Parser in OCDI Debugging (Microprocessor SDK)
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 still can 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, the list parser 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 resolving the signals and nodes to a series of hexadecimal offsets, which are shown in bold. The memory locations are still only known relative to yet unresolved symbols. Absolute memory address information is not available at this phase.
[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, generate this information 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
L represents the length of the entire data type in bytes j represents the offset from the beginning of the data structure in bits k represents the length of the data member in bitsIn addition, the LVM file needs information from the LabVIEW project to completely decouple the LabVIEW development environment from the debugging interface.