ABC Tool Project
From DDCIDeos
Overview
The SCAT tool has been renamed to ABC Tool and ported from Perl to Python.
Roadmap
References
- Assembly Branch Coverage for Deos (ABC) Tool Qualification Data, Operational Requirements (2023)
- DDC-I Additional Considerations (2025) (see Section 3 ASSEMBLY BRANCH COVERAGE)
- DDC-I IP Response (2002) (responses to specific issues raised by certification authorities)
NOTE: Branches have been moved. Instead of mainline (Perl) and python-port branches, they are now mainline (Python) and legacy-perl (retaining the older Perl implemenation).
- ABC Tool (Python port is now mainline branch)
- ABC Tool (legacy Perl moved from mainline to legacy-perl branch)
Historical
Design
Objectives
- Instrument start and end of basic blocks to verify all instructions were executed in the block during testing
- Instrument decision points (conditionally executed instructions, branches, etc.) to verify both paths were taken during testing
- Instrument the start of dead code sections to verify they were not executed during testing
- Provide a means to stop/start instrumentation, and insert instrumentation at indicated locations in the code.
- Manage nested stop/start instrumentation command pairs (push/pop)
- Implement the required features as architecture-agnostically as possible; customized to ARM, AARCH64, PowerPC, and X86_64 as required.
Simplifying: returning to first principles
- Instrument all conditional instructions (branch or operation) to report which path is taken at those points.
Once the above is assured, any additional instrumentation points which are needed must have a requirement to be implemented and tested.
- Detection of unreachable code
- Detection of start/end of basic code blocks
- Instrumentation on/off/insert/push/pop
To Be Addressed
- High-Level Design Decisions document needed (philosophy, intent,...)
- Design decisions:
- coverage of basic block entries
- coverage of whether conditional statement conditions (instruction, branch) are true or false
- coverage of basic block exits? (for report indication that code executed to that point before change of flow?)
- Operational Requirements doc:
- Should 3.2 Branch Coverage be 3.2 Conditional Branch Coverage?
- Should 3.25 Pos-independent relocation be section 3.3 (not under [cond] Branch Coverage)?
- (double checking, but thought I saw INSTRUMENTATION IGNORE in the tool code which is not in req doc..?)
- INSTRUMENTATION INSERT: should this override INSTRUMENTATION OFF or be ignored in that state?
- Allowance for updating hit indexing in the database after initial write (without interfering with files not being updated/re-instrumented)
- In the ABC Tool UG, sec 2.1 ends with "the GNU linker needs the "-Map" argument". Are we using that in v7.x?
- Add comments in code to explain functional behavior (especially where it might be unclear or takes additional info)
Requirements
| Requirement | Description | Verification Plan | Notes |
|---|---|---|---|
| Requirement tag | Summary of requirement | Verification plan | |
| ABC_REQ_Entry_050 | Report procedure entry executed | 4.5 | |
| ABC_REQ_Entry_060 | Report procedure entry never executed | 4.5 | |
| ABC_REQ_Entry_070 | Report label code segment entered | 4.5 | |
| ABC_REQ_Entry_080 | Report label code segment never entered | 4.5 | |
| ABC_REQ_Branch_100 | Report jump taken | 4.1, 4.2.1.1 thru .3, 4.2.2.1 thru .2, 4.2.3.1 thru .2 | |
| ABC_REQ_Branch_110 | Report jump never taken | 4.1, 4.2.1.1 thru .3, 4.2.2.1 thru .2, 4.2.3.1 thru .2 | |
| ABC_REQ_Branch_120 | Report jump both taken and not taken | 4.1, 4.2.1.1 thru .3, 4.2.2.1 thru .2, 4.2.3.1 thru .2 | |
| ABC_REQ_Branch_130 | Report jump condition never evaluated | 4.1, 4.2.1.1 thru .3, 4.2.2.1 thru .2, 4.2.3.1 thru .2 | |
| ABC_REQ_Branch_140 | Cope with PPC/ARM/MIPS PIC setup idiom | 4.2.2.4 | |
| ABC_REQ_Branch_150 | Cope with X86 PIC setup idiom | 4.2.1.5 | |
| ABC_REQ_Directive_160 | Handle INSTRUMENTATION ON/OFF | 4.4 | |
| ABC_REQ_Directive_170 | Handle INSTRUMENTATION INSERT | 4.4 | |
| ABC_REQ_Directive_175? | Handle INSTRUMENTATION PUSH/POP | ||
| ABC_REQ_Operation_180? | Report conditional operation executed | ||
| ABC_REQ_Operation_185? | Report conditional operation not executed | ||
| ABC_REQ_Operation_190? | Report conditional operation executed and not executed | ||
| ABC_REQ_Operation_195? | Report conditional operation never evaluated | ||
| ABC_REQ_Count_200 | Count points executed in module | 4.5 | |
| ABC_REQ_Count_210 | Count points in module | 4.5 | |
| ABC_REQ_Count_220 | Count points deemed unreachable in module | 4.5 | |
| ABC_REQ_Count_300 | Highlight jumps never taken | 4.1, 4.2.1.1 thru .3, 4.2.2.1, 4.2.3.1 thru .2 | |
| ABC_REQ_Count_310 | Highlight jumps never fell thru | 4.1, 4.2.1.1 thru .3, 4.2.2.1, 4.2.3.1 thru .2 | |
| ABC_REQ_Count_320 | Flag jumped and fell thru | 4.1, 4.2.1.1 thru .3, 4.2.2.1, 4.2.3.1 thru .2 | |
| ABC_REQ_Count_330 | Highlight jumps never executed | 4.1, 4.2.1.1 thru .3, 4.2.2.1, 4.2.3.1 thru .2 | |
| ABC_REQ_Uninst_400 | Warn file present not instrumented | 4.3 | |
| ABC_REQ_Uninst_410 | Warn file instrumented not present | 4.3 | |
| ABC_REQ_Uninst_420 | Warn file instrumented, other version present | 4.3 |
Missing requirements (need to check if they are referenced in the User Guide):
- Conditional instructions
- INSTRUMENTATION PUSH/POP
- Instrumentation of unconditional branches (to indicate end of instruction basic blocks executed for reports?)
- Behavior in 6.x (Perl): replaced ".syntax divided" with ".syntax unified" in ARM processing to allow instrumented insertions to compile. Where is this documented with justification?
TO DO
- Make sure lexer is working correctly
- Make sure parser is working correctly
- Fix issues with missing and extra instrumentation
- Remaining issues with pc-relative addressing
Get INSTRUMENTATION INSERT support working
- Fix issues with missing and extra instrumentation
- Port test suite from older version of the tool and get it integrated in the build
- Update as needed to match the ported/new version of the tool (CAN and HTM files)
- Process full test suite as part of the build (not currently in the make system)
- Make sure report generation is working correctly
- Fix issues with the index file and hitmap write/read management
- Port the documentation from the older version of the tool and get it integrated in the build
- Create documentation files (UG, reqs, ...) as part of the build (not currently in the make system)
- Update as needed to match the ported/new version of the tool
- Clean up the python lint warnings
- Make names and ordering/layout (functions, enumerations, etc) consistent across ARM, AARCH64, PPC, and X86_64 specific files
Team Suggestions and Feedback
- Chris: Building with -Q, do not print Instrumentor Statistics (to reduce build time slowed by unnecessary prints)
- Lisa/Kenney: report coverage tool used to end with 'reportCoverage DONE' that OpenArbor automated test relied on to indicate the test is done. This is not working yet in abc-tool 7.x. It would be better to have it report PASSED/FAILED rather than done when re-implemented.
- Lisa/MarkS: errors compiling instrumented arinc653 partition and math library code -- coprocessor out of range error, probably a branch to label far call fail due to added instrumentation code in long functions interfering with compiler calculated safe distance for text access.
- Adina: make sure report justification annotations are preserved. Add support to keep (or re-place) justifications after clean build if the index did not change or if the change can be used to remap justifications?
Status
Working on:
- Making sure all mnemonics (opcodes) from technical documentation for each architecture is captured in the lark grammar file for the architecture.
- Separate them into unconditional and conditional sets, setting up for the rules to handle all conditional statement forms.
- I am using a text file with all mnemonics for each architecture. Within each architecture, mnemonics can be designated as conditional by placing a * at the start of the line.
- Getting hitmap working: in memory, clearing and collecting, confirming report generation works.
- It appears the Clear Hitmap and Gather Hitmap in OpenArbor do NOT use the abc clear-hitmap or abc collect-bitmap, but some other code which does not support the 4 byte signature now in place.
- After a bit of work, ftp clear and collect hitmap memory via abc tooling is working.
- Report generation looks good for hello-world after some work. Still need to check multiple instrumented files and justification handling in the reports (that's up next)
- Instrumentation of procedure entries specifically (was generically part of label block entries, but separate explicit requirement) is now implemented.
| Task | Requirement | Implemented | Instrumentation Tested | Report Working | Notes |
|---|---|---|---|---|---|
| entry point detection | ABC_REQ_Entry_050 ABC_REQ_Entry_060 ABC_REQ_Entry_070 ABC_REQ_Entry_080 |
Done-ish | In Work | Pending | Ironing out skipping debug labels |
| conditional branches | ABC_REQ_Branch_100 ABC_REQ_Branch_110 ABC_REQ_Branch_120 ABC_REQ_Branch_130 |
Yes | In Work | Pending | Working so far for initial testing |
| position-independent relocation | ABC_REQ_Branch_140 ABC_REQ_Branch_150 |
Yes | In Work | Pending | Investigating if working correctly |
| conditional instructions | Yes | In Work | Pending | Working so far for initial testing | |
| INSTRUMENTATION OFF/ON | ABC_REQ_Directive_160 | Done-ish | In Work | Pending | initial testing looks good |
| INSTRUMENTATION INSERT | ABC_REQ_Directive_170 | In Work | In Work | Pending | detection and instrumentation working |
| unreachable (dead) code | ABC_REQ_Count_220 | In Work | In Work | Pending | Detection working, not clear the code is marking or instrumenting dead code, need to check reporting also working correctly |
| unconditional branches | In Work | In Work | Pending | Working, matches 6.x tool instrumentation to verify end of block execution | |
| (ARM) pop pc branching | In Work | In Work | Pending | Working after changes, matches 6.x tool instrumentation to verify end of block execution when returning by pc manipulation | |
| INSTRUMENTATION PUSH/POP | In Work | In Work | Pending | Behavior not checked/confirmed yet in 7.x tool | |
| (ARM) mov/ldr/arithmetic pc-relative addressing | In Work | In Work | Pending | Does not appear to work yet, investigating | |
| (ARM) load multiple registers pc-relative addressing | In Work | In Work | Pending | Does not appear to work yet, investigating | |
| iterative updates of CAN instrumented files | In Work | In Work | Pending | Updates to CAN files to match current instrumentation where cosmetic or carefully confirmed as correct in the new version | |
| (ARM) bl 1b -- subroutine call to nearest preceding label "1:" | In Work | In Work | Pending | This is proving challenging to fix in the grammar. Currently causes a parse error |
Below: Succeeded indicates that
- instrumentation of the test was completed and a (html) diff was generated for arm and ppc
- an instrumentation of the test was created (as well as an html diff pre/post instrumentation assembly),the instrumented version compiled to object code successfully and objdump-ed without errors for aarch64 and x86_64.
Succeeded does not indicate all instrumentation is working or is exactly as the Perl tool version produced.
Correctness of instrumentation as being the same as the CAN files content will be checked once CAN files matching the current approach (layout, labeling, etc) are ready.
Succeeded:
output-tests/inst_abcexpr1-arm-diff.html
output-tests/can-compare/inst_abcexpr1-arm-diff-can.html
output-tests/inst_abcexpr2-arm-diff.html
output-tests/can-compare/inst_abcexpr2-arm-diff-can.html
output-tests/inst_abcexpr3-arm-diff.html
output-tests/can-compare/inst_abcexpr3-arm-diff-can.html
output-tests/inst_abcexpr4-arm-diff.html
output-tests/can-compare/inst_abcexpr4-arm-diff-can.html
output-tests/inst_abcexpr5-arm-diff.html
output-tests/can-compare/inst_abcexpr5-arm-diff-can.html
output-tests/inst_abcexpr6-arm-diff.html
output-tests/can-compare/inst_abcexpr6-arm-diff-can.html
output-tests/inst_abcexpr7-arm-diff.html
output-tests/can-compare/inst_abcexpr7-arm-diff-can.html
output-tests/inst_abcpic-arm-diff.html
output-tests/can-compare/inst_abcpic-arm-diff-can.html
output-tests/inst_abctest-arm-diff.html
output-tests/can-compare/inst_abctest-arm-diff-can.html
output-tests/inst_asm_br_opcode-arm-diff.html
output-tests/can-compare/inst_asm_br_opcode-arm-diff-can.html
output-tests/inst_asm_conditional-arm-diff.html
output-tests/can-compare/inst_asm_conditional-arm-diff-can.html
output-tests/inst_asm_driver-arm-diff.html
output-tests/can-compare/inst_asm_driver-arm-diff-can.html
output-tests/inst_asm_fp_conditional-arm-diff.html
output-tests/can-compare/inst_asm_fp_conditional-arm-diff-can.html
output-tests/inst_asm_ub_opcodes-arm-diff.html
output-tests/can-compare/inst_asm_ub_opcodes-arm-diff-can.html
output-tests/inst_instonly_asm_pc_unsupported-arm-diff.html
output-tests/can-compare/inst_instonly_asm_pc_unsupported-arm-diff-can.html
output-tests/inst_instrButUninstrPres-arm-diff.html
output-tests/can-compare/inst_instrButUninstrPres-arm-diff-can.html
output-tests/inst_instrNotPres-arm-diff.html
output-tests/can-compare/inst_instrNotPres-arm-diff-can.html
output-tests/inst_testInstrumDirectivesActive-arm-diff.html
output-tests/can-compare/inst_testInstrumDirectivesActive-arm-diff-can.html
output-tests/inst_testInstrumDirectivesInactive-arm-diff.html
output-tests/can-compare/inst_testInstrumDirectivesInactive-arm-diff-can.html
output-tests/inst_abcexpr1-ppc-diff.html
output-tests/can-compare/inst_abcexpr1-ppc-diff-can.html
output-tests/inst_abcexpr2-ppc-diff.html
output-tests/can-compare/inst_abcexpr2-ppc-diff-can.html
output-tests/inst_abcexpr3-ppc-diff.html
output-tests/can-compare/inst_abcexpr3-ppc-diff-can.html
output-tests/inst_abcexpr4-ppc-diff.html
output-tests/can-compare/inst_abcexpr4-ppc-diff-can.html
output-tests/inst_abcexpr5-ppc-diff.html
output-tests/can-compare/inst_abcexpr5-ppc-diff-can.html
output-tests/inst_abcexpr6-ppc-diff.html
output-tests/can-compare/inst_abcexpr6-ppc-diff-can.html
output-tests/inst_abcexpr7-ppc-diff.html
output-tests/can-compare/inst_abcexpr7-ppc-diff-can.html
output-tests/inst_abcpic-ppc-diff.html
output-tests/can-compare/inst_abcpic-ppc-diff-can.html
output-tests/inst_abctest-ppc-diff.html
output-tests/can-compare/inst_abctest-ppc-diff-can.html
output-tests/inst_asm_driver-ppc-diff.html
output-tests/can-compare/inst_asm_driver-ppc-diff-can.html
output-tests/inst_instrButUninstrPres-ppc-diff.html
output-tests/can-compare/inst_instrButUninstrPres-ppc-diff-can.html
output-tests/inst_instrNotPres-ppc-diff.html
output-tests/can-compare/inst_instrNotPres-ppc-diff-can.html
output-tests/inst_testInstrumDirectivesActive-ppc-diff.html
output-tests/can-compare/inst_testInstrumDirectivesActive-ppc-diff-can.html
output-tests/inst_testInstrumDirectivesInactive-ppc-diff.html
output-tests/can-compare/inst_testInstrumDirectivesInactive-ppc-diff-can.html
output-tests/inst_abcexpr1-aarch64.dis
output-tests/inst_abcexpr2-aarch64.dis
output-tests/inst_abcexpr3-aarch64.dis
output-tests/inst_abcexpr4-aarch64.dis
output-tests/inst_abcexpr5-aarch64.dis
output-tests/inst_abcexpr6-aarch64.dis
output-tests/inst_abcexpr7-aarch64.dis
output-tests/inst_abcpic-aarch64.dis
output-tests/inst_abctest-aarch64.dis
output-tests/inst_clearmap-aarch64.dis
output-tests/inst_testInstrumDirectivesActive-aarch64.dis
output-tests/inst_testInstrumDirectivesInactive-aarch64.dis
output-tests/inst_exerciseIntN-mc-x86_64.dis
output-tests/inst_exerciseIntN-x86_64.dis
output-tests/inst_stimulateGccX86Pic1-mc-x86_64.dis
output-tests/inst_stimulateGccX86Pic2-mc-x86_64.dis
output-tests/inst_x86SpecificTests-x86_64.dis
output-tests/inst_abcexpr1-x86_64.dis
output-tests/inst_abcexpr2-x86_64.dis
output-tests/inst_abcexpr3-x86_64.dis
output-tests/inst_abcexpr4-x86_64.dis
output-tests/inst_abcexpr5-x86_64.dis
output-tests/inst_abcexpr6-x86_64.dis
output-tests/inst_abcexpr7-x86_64.dis
output-tests/inst_abcpic-x86_64.dis
output-tests/inst_abctest-x86_64.dis
output-tests/inst_clearmap-x86_64.dis
output-tests/inst_testInstrumDirectivesActive-x86_64.dis
output-tests/inst_testInstrumDirectivesInactive-x86_64.dis
Failed:
output-tests/inst_instonly_arm_conditionals-arm.s_ -- parse or instrumentation failure
can-compare: output-tests/inst_instonly_arm_conditionals-arm.s_ -- parse or instrumentation failure
output-tests/inst_asm_ctr_opcode-ppc.s_ -- parse or instrumentation failure
can-compare: output-tests/inst_asm_ctr_opcode-ppc.s_ -- parse or instrumentation failure
output-tests/inst_asm_lr_opcode-ppc.s_ -- parse or instrumentation failure
can-compare: output-tests/inst_asm_lr_opcode-ppc.s_ -- parse or instrumentation failure
output-tests/inst_asm_std_opcode-ppc.s_ -- parse or instrumentation failure
can-compare: output-tests/inst_asm_std_opcode-ppc.s_ -- parse or instrumentation failure
output-tests/inst_asm_std_opcode_pm-ppc.s_ -- parse or instrumentation failure
can-compare: output-tests/inst_asm_std_opcode_pm-ppc.s_ -- parse or instrumentation failure
output-tests/instrButUninstrPres-aarch64.s_ -- missing file, possible compile error
output-tests/instrNotPres-aarch64.s_ -- missing file, possible compile error
output-tests/uninstrPres-aarch64.s_ -- missing file, possible compile error
output-tests/stimulateGccX86Pic1-x86_64.s_ -- missing file, possible compile error
output-tests/stimulateGccX86Pic2-x86_64.s_ -- missing file, possible compile error
output-tests/instrButUninstrPres-x86_64.s_ -- missing file, possible compile error
output-tests/instrNotPres-x86_64.s_ -- missing file, possible compile error
output-tests/uninstrPres-x86_64.s_ -- missing file, possible compile error
In source code comments TODO List
Last captured Tuesday, July 29, 2025
Code
$ grep -rns TODO: code
code/abc.py:18:# This one should be already in my path but for some reason it is not, TODO: inquire Aaron later
code/abc.py:21:# This one is not here either? TODO: Fix this
code/report/templates/summary.html:25: {# TODO: Throw this table away in favor of something that is not wack #}
code/report/report.py:18:# print(f'transform agnositic.py logger name is {logger.name}') # TODO: PZ: debug printing
code/report/report.py:162: TODO: A lot of this boils down to me bending the knee to legacy abcJavascriptUtils
code/report/report.py:170: # TODO: This code made the assumption that there was only one hitpoint per assembly
code/report/report.py:362: # TODO: Correct for the eventuality you might stumble across debug line
code/instrument/GNUPowerPC.py:2:# TODO: PZ Find a better way to avoid lint errors for the generated itpl members (from file names).
code/instrument/GNUPowerPC.py:39: # if indent: # TODO: PZ: in configure_indentation really needed?
code/instrument/GNUPowerPC.py:77: # TODO: PZ repeat something like uninstrumented above for unreachable code annotation?
code/instrument/__init__.py:22: # print(f'indentation set :{indentation}: {[ascii(c) for c in indentation]}') # TODO: PZ: debug printing
code/instrument/__init__.py:28: # TODO: PZ: Remove expandtabs here and leave in report generator?: line = asm_lines[line_num].expandtabs()
code/instrument/__init__.py:33: # TODO: PZ: cleanup from: indentation = ilen(takewhile(lambda c: c.isspace(), line))
code/instrument/GNUARM.py:2:# TODO: PZ Find a better way to avoid lint errors for the generated itpl members (from file names).
code/instrument/GNUARM.py:36: # if indent: # TODO: PZ: in configure_indentation really needed?
code/instrument/GNUARM.py:75: # TODO: PZ repeat something like uninstrumented above for unreachable code annotation?
code/instrument/GNUAArch64.py:2:# TODO: PZ Find a better way to avoid lint errors for the generated itpl members (from file names).
code/instrument/GNUAArch64.py:37: # if indent: # TODO: PZ: in configure_indentation really needed?
code/instrument/GNUx8664.py:2:# TODO: PZ Find a better way to avoid lint errors for the generated itpl members (from file names).
code/instrument/GNUx8664.py:37: # if indent: # TODO: PZ: in configure_indentation really needed?
code/transform/virtual.py:85: # TODO: PZ If this works, clarify if it should work inside INSTRUMENTATION OFF or not
code/transform/virtual.py:95: # TODO: PZ figure out why abc__insert does not convert to an AsmPoint so this screen can be removed
code/transform/virtual.py:146: # TODO: Lexer bug somehow does not separate these operands
code/transform/virtual.py:257: # TODO: PZ remove debug prints once this is working
code/transform/GNUARM.py:87: # TODO: It seems like "parallel" and "reverse" here are the wrong terms. Perhaps complement? Inverse?
code/transform/agnostic.py:24: return tree # TODO: PZ: was: if len(tree.children) > 0 else Discard
code/transform/agnostic.py:107: # TODO: PZ Find a way to ignore debug labels in the filter here rather than below?
code/transform/agnostic.py:127: # TODO: PZ The labels handling below is used to ignore debug labels and fall through to
code/transform/agnostic.py:140: # print(lbl) # TODO: PZ: debug printing
code/transform/agnostic.py:160: # TODO: PZ clean up this debug printing when it is no longer needed
code/transform/agnostic.py:166: # TODO: PZ: confirm the addition of label_consumed works and is needed after preventing exess empty pruning
code/transform/agnostic.py:169: # print('entrypoint') # TODO: PZ: debug printing
code/transform/agnostic.py:198: # TODO: PZ combine the segments below. Should handle one or more similarly.
code/transform/agnostic.py:209: # TODO: PZ This section fixed the intermittent unconditional branch instrumentation issue,
code/transform/agnostic.py:218: # TODO: PZ check for unreachable/dead code. What is done with these? Looking for report/instrumentation handlers
code/transform/agnostic.py:247: # TODO: PZ Is the AST image value added? It becomes unwieldy for larger programs. Remove this later.
code/itpl/aarch64/zero_state_branch_tpt_ntpt.itpl:1:#// TODO: this can be substantially optimized similarly to bit_branch_tpt_ntpt.itpl
code/itpl/aarch64/conditional_branch_taken_not_taken.itpl:1:#// TODO: this can be substantially optimized similarly to bit_branch_tpt_ntpt.itpl
code/itpl/aarch64/conditional_executed_not_executed.itpl:1:#// TODO: this can be substantially optimized similarly to bit_branch_tpt_ntpt.itpl
code/itpl/arm/tpt_ntpt.itpl:10:#// TODO: The syntax for following code doesn't look correct. If this was intended to be an IT
code/itpl/__init__.py:36: # TODO: PZ: Clean up outdated commented out lines
code/parsers/__init__.py:9:# print(f'parsers __init__.py logger name is {__name__}') # TODO: PZ: debug printing
code/parsers/__init__.py:55: # TODO: PZ: Figure out best/safest cache approach across architectures to prevent cross-pollenization
code/parsers/grammars/GNUARM.lark:55:// | load_register // TODO: PZ cleanup, moved to recognized_instruction, not conditional
code/parsers/grammars/GNUARM.lark:113:// TODO: PZ Should pc_arithmetic be changed to the following?
code/parsers/grammars/GNUARM.lark:145:// TODO: PZ: Ideally, the grammar should detect if pc is in the list or not and allow separate rules,
code/parsers/grammars/GNUARM.lark:155:// TODO: PZ: Ideally, the grammar should detect local labels for "bl" which are numbers with a suffix of b(for most
code/parsers/grammars/GNUARM.lark:212:// TODO: Hacky, this needs to be its own parse tree pass to correct after parsing
code/parsers/grammars/GNUARM.lark:213:// TODO: PZ try removing "pc"i from here and move to pc_arithmetic rule above
code/parsers/grammars/GNUARM.lark:219:// TODO: PZ
code/parsers/grammars/gas.lark:292:// TODO: The above is very permissive, perhaps this?
code/parsers/grammars/gas.lark:304:// TODO: Floating point constants have some variance across different architectures,
code/parsers/grammars/GNUAArch64.lark:76:// TODO: PZ cond_invocation rule should be implemented in the aarch64 grammar
code/parsers/grammars/GNUAArch64.lark:113:// TODO: Identify PIC, PC-relative things
code/parsers/grammars/GNUAArch64.lark:119:// TODO: The /br$/i rather than "br"i is because "br" does not preclude there being other
code/parsers/grammars/GNUAArch64.lark:140:// TODO: PZ Why are the conditionals included here AND CC_SUFFIX?
code/parsers/grammars/GNUAArch64.lark:141:// TODO: PZ Remove?: COND_CONSISTENT_BRANCH_MNEMONIC.3 : /bc(?=(ne|eq|cc|cs|pl|mi|vc|vs|ls|hi|lt|ge|le|gt|nv|al))/i CC_SUFFIX
code/parsers/grammars/GNUAArch64.lark:169: | ".req"i // TODO: investigate register aliasing with name
code/parsers/grammars/GNUAArch64.lark:258: // TODO: PZ Remove as moved: | "bcc"i
code/parsers/grammars/GNUAArch64.lark:259: // TODO: PZ Remove as moved: | "bcs"i
code/parsers/grammars/GNUAArch64.lark:330: // TODO: PZ Remove as redundant to exception token: | "brk"i
code/parsers/grammars/GNUAArch64.lark:654:// | "hvc"i // TODO: PZ Moved to exception token:
code/parsers/grammars/GNUAArch64.lark:1201:// | "smc"i // TODO: PZ Moved to exception token
code/parsers/grammars/GNUAArch64.lark:1460:// | "svc"i // TODO: PZ Moved to exception token
code/parsers/grammars/GNUx8664.lark:38:// TODO: PZ: missing | cond_invocation
code/parsers/grammars/GNUx8664.lark:73:// TODO: PZ: cond_invocation rule should be implemented in the x86_64 grammar
code/parsers/grammars/GNUx8664.lark:93:// TODO: PZ This should use LOOP_MNEMONIC instead of an identically defined CONDLOOP_MNEMONIC
code/parsers/grammars/GNUx8664.lark:94:// TODO: PZ Remove: loop_on_cond : CONDLOOP_MNEMONIC CC_SUFFIX x64_operand STMT_DELIM
code/parsers/grammars/GNUx8664.lark:130:// TODO: PZ There is no need for CONDLOOP_MNEMONIC when LOOP_MNEMONIC can be used in both rules above
code/parsers/grammars/GNUx8664.lark:131:// TODO: PZ Remove: CONDLOOP_MNEMONIC.2 : "loop"i
code/parsers/grammars/abc.lark:8:// TODO: continuity definition seems incomplete below and incorrect in FOR_DEVELOPERS.md,
code/parsers/grammars/abc.lark:14:// TODO: PZ Cleanup above -- "optional" has been changed to "conditional" and moved to the continuity
code/parsers/grammars/abc.lark:17:// TODO: Should settle on branch vs jump and not always say both. I suggest branch.
code/parsers/grammars/abc.lark:52:// TODO: old and new ABC seem to instrument unconditional branches, but it is not clear why.
code/parsers/grammars/abc.lark:68: // subroutine or system calls. TODO: should have a note about common use in
code/cmd/instrument/main.py:50: if asm_points: # TODO: PZ: args.quiet should turn off the print statements...
code/cmd/instrument/main.py:51: # print(f"Logger Levels: {logging.DEBUG}, {logging.INFO}, {logging.CRITICAL}") # TODO: PZ: debug printing
code/cmd/instrument/main.py:52: # print(f"Logger Level = {logger.level}") # TODO: PZ: debug printing
code/makefile.mk:28:# TODO: move PYLINT_FILE to build-utils?
code/makefile.mk:30:# TODO: This supports relative sub-directories. I found that having the .list files in
