CLI Option Parsing

This page documents the command-line option parsing infrastructure in nvlink v13.0.88: the parser framework, option entry struct layout, registration sequence, post-extraction validation, mutual-exclusion enforcement, and global variable mappings. For the complete alphabetically-sorted quick-reference table of all flags, see CLI Flags Reference.

Parser Infrastructure

Option parsing is a self-contained subsystem at addresses 0x42C510--0x42F640. The parser is a generic, reusable framework (shared with cicc and ptxas) that handles option registration, argv scanning, value extraction, help formatting, and validation. nvlink creates one parser instance at the start of nvlink_parse_options (0x427AE0) and destroys it implicitly when the function returns.

Core Functions

Parser Object Layout (56 bytes)

The parser object (sub_42DFE0 return value) is allocated from the "nvlink option parser" memory arena. Order matches the constructor's writes in sub_42DFE0:

The linked list at +32/+40 is the iteration order used by option_print_help (sub_42F560 reads *(parser+32) and feeds it to sub_464700, which walks a singly-linked list of 16-byte wrappers). The two hash tables at +0/+8 are populated by sub_42F130 (option_register) for O(1) lookup by long or short name during argv parsing.

Option Entry Layout (120 bytes)

Each option registered by option_register occupies 120 bytes:

Type Codes

Flag Bits

The flags field at offset 24 controls parser behavior:

Registration and Extraction Flow

The nvlink_parse_options function (0x427AE0, 30272 bytes, 1299 lines) follows a strict sequence:

1. parser = option_parser_create(0)                    // 0x42DFE0
2. For each of 68 options:
     option_register(parser, long, short, type,        // 0x42F130
                     mult, flags, keywords, reserved,
                     default, default_kw, placeholder, help)
3. option_parse_argv(parser, argc, argv)               // 0x42E5A0
4. Handle immediate-exit options:
     if option_was_specified("trap-into-debugger"):     // 0x42E580
         install_trap_handler()                         // 0x42FA60
     if option_was_specified("help"):
         print_help_and_exit()                          // 0x42F560 + 0x44A420
     if option_was_specified("version"):
         print_version_and_exit()                       // 0x44A420
5. For each option:
     option_get_value(parser, name, &global_var, size)  // 0x42E390
6. Post-extraction validation:
     - Architecture range checks (sm > 19)
     - Mercury mode detection (sm > 99)
     - LTO consistency checks
     - Mutual-exclusion enforcement
     - CUDA API version parsing
7. tkinfo = option_generate_tkinfo(parser, ...)         // 0x42F640

Option Catalog

For the complete alphabetically-sorted flag table (all 68 entries with types, defaults, and one-line descriptions), see CLI Flags Reference.

The remainder of this page documents the implementation-level details: how each option is registered, what global variable it maps to, validation logic, and inter-option dependencies. Options are grouped by functional category below.

Output Options

Global variable mappings:

The gen-host-linker-script option accepts keywords lcs-aug and lcs-abs (default: lcs-abs). The value lcs-aug sets dword_2A77DC0 = 1 (standalone SECTIONS fragment, 130 bytes, written to file or stdout), while lcs-abs sets it to 2 (full augmented script: ld --verbose pipeline + append SECTIONS + ld -T validation). The mapping is computed by a byte-by-byte compare against the literal "lcs-aug" at sub_427AE0 lines 1012-1027 (see Mode Dispatch).

Debug Options

Global variable mappings:

When --suppress-debug-info is specified with --debug, the effect is to clear byte_2A5F310 (debug flag) to 0, effectively disabling debug output. If specified without --debug, a warning is emitted: "-suppress-debug-info" conflicts with "no -g".

Architecture Options

Global variable mappings:

The arch option is registered with an allowed-keywords callback (sub_486EC0(1)) that validates the architecture name against the supported SM table. The machine option defaults to "64" and only accepts value 64; specifying 32 on SM > 72 produces a fatal error.

The cpu-arch option accepts keywords: unknown, X86, X86_64, ARMv7, AARCH64, PPC64LE (default: unknown).

Architecture validation logic (post-extraction):

sm = parse_sm_number(arch_string)         // sub_44E3E0
if sm <= 19:
    fatal_error("unsupported arch")
byte_2A5F224 = (sm > 72)                  // "new-style" ELF flag
if sm > 72 && machine == 32:
    fatal_error("sm > 72 requires 64-bit")
    byte_2A5F224 = 0
if sm > 99:                               // Mercury (Blackwell+)
    byte_2A5F222 = 1                      // mercury mode
    byte_2A5F225 = 1                      // SASS output mode
    byte_2A5B510 = 0
elif sm > 89:                             // sm_90+ needs SASS mode
    if sm <= 89:
        fatal_error("SASS mode requires sm >= 90")

The validation cascade partitions the active SM tiers into three regimes: PTX-only output for sm_75 / sm_80 / sm_86 / sm_87 / sm_88 / sm_89 (the sm > 72 branch enables the new-style ELF flag without forcing SASS mode); SASS-required for sm_90 (elif sm > 89); and Mercury+SASS for sm_100 / sm_103 / sm_110 / sm_120 / sm_121 (the sm > 99 branch). sm_70 and sm_72 reach the validator but are rejected downstream by the profile lookup because they have been removed from the active database (see Architecture Profiles, "Deprecated Architecture Numbers").

Library Options

Global variable mappings:

Both library and library-path have multiplicity 2 (multi-value), so repeated -l / -L flags accumulate into linked lists. host-linker-options is accepted and stored but ignored by the device linker.

Linking Behavior Options

Global variable mappings:

The null-pointer reservation logic computes byte_2A5F2CD = reserve-null-pointer AND NOT dont-reserve-null-pointer. The dont-reserve-null-pointer flag always wins if both are specified.

The disable-smem-reservation and enable-extended-smem options accept true/false as values (boolean with multiplicity 1), with default "false".

no-opt and optimize-data-layout are mutually exclusive; specifying both produces a fatal error.

Dead Code Elimination Options

Global variable mappings:

use-host-info and ignore-host-info are mutually exclusive. If neither is specified, use-host-info defaults to true (byte_2A5F213 = 1, byte_2A5F214 = 1). If --relocatable-link is specified, ignore-host-info is forced on. If --kernels-used or --variables-used is specified, use-host-info is forced off with a warning.

LTO Options

Global variable mappings:

When --dlto is specified, byte_2A5F288 (the LTO master flag) is set to 1. The LTO options have extensive mutual-exclusion and dependency validation:

• --nvvmpath is required with -lto; omitting it produces: "-nvvmpath should be specified with -lto"
• --force-partial-lto and --force-whole-lto are mutually exclusive
• --emit-ptx requires -lto
• --Ofast-compile requires -lto
• --force-partial-lto without -dlto is an error
• --force-whole-lto without -dlto is an error
• --relocatable-link forces partial LTO mode

Both split-compile and split-compile-extended default to 1 (single-threaded). When --emit-ptx is specified with multi-threaded split-compile, the threads are forced to 1 with a warning.

LTO Forwarding Options

Global variable mappings:

The Ofast-compile option accepts: "0", "min", "mid", "max" (default: "0"). Any other value produces a fatal error referencing "--Ofast-compile". The values control optimization aggressiveness during LTO compilation:

• "max": Focus only on the fastest compilation speed, disabling many optimizations
• "mid": Balance compile time and runtime, disabling expensive optimizations
• "min": More minimal impact on both compile time and runtime, minimizing some expensive optimizations
• "0": Disables fast-compile (the option is disabled by default)

Warning and Diagnostic Options

Global variable mappings:

After extraction, warning-as-error and disable-warnings/disable-infos are applied immediately:

sub_468420(byte_2A5F2C3);   // configure warning-as-error in diagnostics subsystem
sub_468430(byte_2A5F2C4);   // configure disable-warnings
sub_468430(byte_2A5F2C5);   // configure disable-infos

Verbose and Debug Output Options

Global variable mappings:

dump-callgraph and dump-callgraph-no-demangle are mutually exclusive.

When --debug is specified and --verbose-tkinfo was not explicitly given, byte_2A5F223 is forced to 1 (tkinfo is always verbose in debug builds).

CUDA API and Compatibility Options

Global variable mappings:

The cuda-api-version value is parsed with sscanf("%u.%u"). The major version must equal the toolkit version (dword_2A5B50C); the minor version is clamped to the minimum of the specified value and the built-in default (dword_2A5B508).

Security Options

Global variable mappings:

Both options have their "was specified" flags stored separately (byte_2A5F1FF for device-stack-protector, byte_2A5F1FC for device-stack-protector-frame-size-threshold), retrieved via option_was_specified.

Internal / Undocumented Options

Global variable mappings:

fdcmpt is a forward-compatibility flag. It is validated post-extraction: if fdcmpt is set but uumn is not set, a warning is emitted ("-fdcmpt"). If both are set but SM <= 69, a fatal error is produced. The flag controls data-model compatibility across architectures (exact semantics not fully determined from decompilation).

uumn is a companion to fdcmpt and has no help text.

The time option enables CSV timing output (used by NVIDIA's build infrastructure for performance tracking). When the file argument is "-", timing data goes to stdout.

Meta Options

Global variable mappings:

--help output format:

Usage  : nvlink [options] <objects>

followed by formatted help for all non-hidden options.

--version output format:

nvlink: NVIDIA (R) Cuda linker
Copyright (c) 2005-2025 NVIDIA Corporation
Built on Wed_Aug_20_01:58:59_PM_PDT_2025
Cuda compilation tools, release 13.0, V13.0.88
Build cuda_13.0.r13.0/compiler.36424714_0

--options-file (type 0 = file-list) is handled by the parser itself during option_parse_argv: response files are expanded in-place before option matching.

--trap-into-debugger installs signal handlers (via sub_42FA60) that trap into a debugger on assertion failure, then continues normal option parsing.

Post-Extraction Validation

After extracting all option values into global variables, nvlink_parse_options performs extensive cross-validation. The mutual-exclusion conflicts all use sub_467460 (the error/warning/fatal dispatcher) with format string unk_2A5B650 for fatal conflicts:

Compilation Mode Determination

The extracted options determine the overall compilation mode stored in dword_2A5B528:

Global Variable Map

Complete mapping from option name to BSS global variable address, sorted by address:

Option Globals Cross-Reference Matrix

Cross-reference of every BSS global in the option-state region 0x2A5F1FC--0x2A5F330, mined from nvlink_xrefs.json. The Setter column names the function that issues the write (the CLI extractor sub_427AE0, the derivation site, or a runtime updater); the Top Consumers column lists the functions that read the global most often, in descending call-count order. Function tags use the short-name conventions already established elsewhere in the wiki: main = 0x409800, nvlink_parse_options = sub_427AE0, the LTO compile-driver = sub_426CD0, the per-module link iterator = sub_426570, the inner load loop = sub_426AE0, the SASS-mode dispatcher = sub_4275C0, the merge consistency tracker = sub_42AF40, the tkinfo emitter = sub_429BA0, the kernel/variable-keep applier = sub_42A680, the arch profile resolver = sub_42A2D0, the relocator entry point = sub_42A190.

The W/R columns report exact write- and read-site counts from the cross-reference index (call-flow xrefs from sub_427AE0 that are not data references, such as the option_get_value parameter pass, are counted under "Other" in the underlying dataset and excluded here).

* W=0* means the CLI extractor writes the global through option_get_value's out-pointer argument (sub_42E390), which the xref index records as a call-flow edge rather than a data-write to the global. The corresponding entry in the "Other" category of nvlink_xrefs.json covers these stores. Counts shown here are the data-write xrefs proper.

QUIRK (multi-source globals). byte_2A5F212 (ignore-host-info) has the highest write-fan-in of any option global: it is written from sub_427AE0 (initial CLI extraction), then forced to 1 by the relocatable-link branch in the same function (lines 351-352), again by main when --kernels-used/--variables-used is set, and by sub_426AE0 from per-module .nv_info data (line 121). Five distinct write sites for what looks like a plain boolean option.

QUIRK (CLI flag mutated at runtime). byte_2A5F225 (SASS output mode) is written three times: once by the CLI as a true derived flag (sm > 99 -> 1, sm > 89 -> 1 via the unset branch), once by the post-extraction recheck, and a third time by sub_426570 -- the per-module link iterator can promote a non-SASS run to SASS mode mid-link based on module attributes. Same pattern with byte_2A5F222 (mercury mode) and byte_2A5F220/byte_2A5F221 (companion module-scoped state).

QUIRK (CLI flag never read by any consumer). byte_2A5F227 (uumn, undocumented forward-compat helper) has zero reads outside sub_427AE0 itself. The flag exists solely so that sub_427AE0 can pair it with fdcmpt (byte_2A5F228) for the SM <= 69 fatal-error check; once option parsing finishes, no downstream pass observes it. Several other globals (byte_2A5F2C3/byte_2A5F2C4/byte_2A5F2C5) are likewise read only by the parser, because the diagnostic state is forwarded into sub_468420/sub_468430 and the booleans themselves are dead afterward.

Derived Globals

Twelve globals in the 0x2A5F1FC--0x2A5F330 window are computed by sub_427AE0 after extracting raw option values, plus the runtime-promotion globals owned by sub_426570. Their decision trees are listed below in source order. All line numbers refer to decompiled/sub_427AE0_0x427ae0.c unless otherwise noted.

byte_2A5F1FC -- device-stack-protector-frame-size-threshold was specified

byte_2A5F1FC = option_was_specified(parser, "device-stack-protector-frame-size-threshold")

Pure presence query (sub_42E580, line 271). Read by sub_429BA0 to decide whether to emit the threshold into tkinfo.

byte_2A5F1FF -- device-stack-protector was specified

byte_2A5F1FF = option_was_specified(parser, "device-stack-protector")

Same pattern as the frame-size flag (line 270). Read by sub_429BA0 for the tkinfo entry.

qword_2A5F200 -- tkinfo data pointer

qword_2A5F200 = (int64)option_generate_tkinfo(parser, ...)            // line 497

Set by the parser's serializer (sub_42F640) at the tail end of sub_427AE0. Consumed by main when the linker emits the .nv_info section.

byte_2A5F213 and byte_2A5F214 -- use-host-info / host-info active

Three-way decision tree at lines 349-364, after extracting byte_2A5F212 (ignore-host-info) and byte_2A5F213 (use-host-info):

if (use_host_info && ignore_host_info):
    fatal_error("-use-host-info", "-ignore-host-info")

if (relocatable_link):                            # line 351
    ignore_host_info = 1                          # force ignore on -r

if (kernels_used || variables_used):              # line 353
    if (use_host_info):
        warning("ignore -use-host-info because -kernels-used or -variables-used")
    byte_2A5F213 = 0                              # clear use-host-info
    byte_2A5F214 = 1                              # host_info_active = 1
elif (!ignore_host_info):                         # line 360 (default branch)
    byte_2A5F213 = 1                              # default use-host-info on
    byte_2A5F214 = 1                              # host_info_active = 1
# else: both stay 0 (ignore-host-info wins, host_info_active stays 0)

byte_2A5F214 is the true "host info is active for this link" signal consumed by sub_426CD0 (LTO compile-driver) and main; byte_2A5F213 retains the literal CLI intent for diagnostics.

byte_2A5F222, byte_2A5F224, byte_2A5F225 -- SM-derived output mode triple

Computed at lines 296-326 after sub_44E3E0(arch_string) returns the parsed SM number into dword_2A5F314:

sm = dword_2A5F314                                # line 296
byte_2A5F224 = (sm > 0x48)                        # new-style ELF: sm > 72 (line 302)

if (sm > 0x48 && machine == 32):                  # line 303
    fatal_error("32-bit not allowed for sm > 72")
    byte_2A5F224 = 0

if (sm > 0x63):                                   # line 309: sm > 99 (Mercury)
    byte_2A5F222 = 1                              # mercury mode
    byte_2A5F225 = 1                              # SASS output
    byte_2A5B510 = 0
elif (byte_2A5F222):                              # line 316: mercury pre-flag set
    byte_2A5F225 = 1                              # SASS output
elif (!byte_2A5F225):                             # line 320: neither mercury nor SASS
    byte_2A5B510 = 1                              # use PTX path
    goto LABEL_28
# Reaches here only if byte_2A5F225 was already 1 OR mercury triggered
byte_2A5B510 = 0
if (sm <= 0x59):                                  # line 326: SASS requires sm > 89
    fatal_error("SASS mode requires sm >= 90")

Note that byte_2A5F222 can be set before this code path executes -- sub_426570 flips it during per-module loading when it discovers Mercury-class metadata in an input. That is why the elif (byte_2A5F222) branch exists.

byte_2A5F2C0 and byte_2A5F2C1 -- arch capability / output-is-archive

byte_2A5F2C1 = sub_44E490(arch_string)            # line 293: output-is-archive flag
byte_2A5F2C0 = sub_44E4F0(arch_string)            # line 295: arch capability flag
byte_2A5B52C = sub_44E4D0(arch_string)            # line 294: arch-supported flag

All three are pure functions of the parsed --arch string. byte_2A5F2C1 selects passthrough/archive mode in dword_2A5B528 (line 367); byte_2A5F2C0 controls a capability gate consulted by main and sub_42AF40.

byte_2A5F2CD -- reserve-null-pointer effective flag

v15 = 0
if (src):                                         # line 335: reserve-null-pointer was passed
    v15 = (v26 == 0)                              # v26 is dont-reserve-null-pointer
byte_2A5F2CD = v15                                # line 337

The "dont-" form wins outright if specified; reserve-null is only effective when reserve-null is passed and dont-reserve-null is not.

byte_2A5F286 -- partial-LTO active

Set inside the LTO validation cascade at line 427 (LABEL_68):

if (link_time_opt):                               # line 371: byte_2A5F288 == 1
    if (!nvvmpath): fatal("-nvvmpath should be specified with -lto")
    if (relocatable_link):                        # line 375
        force_partial_lto = 1                     # promote -r to partial LTO
    elif (!force_partial_lto):                    # line 379
        if (!emit_ptx):
            goto LABEL_104                        # check Ofast-compile, then mode = LTO

    if (force_whole_lto):                         # line 418
        fatal("-force-partial-lto", "-force-whole-lto")
        ...
    elif (!emit_ptx):
        # LABEL_68
        byte_2A5F286 = 1                          # partial-LTO active
        goto LABEL_104

byte_2A5F286 is only set to 1 in this single branch. It also has separate writers in main (LTO alias propagation) and sub_42A680 (kernel/variable-keep applier forces partial-LTO when keep lists are present).

dword_2A5F314 -- parsed SM number

sm = sub_44E3E0(qword_2A5F318, 0, ...)            # line 290: parse "sm_75" -> 75
if (sm <= 0x13):                                  # line 291: sm <= 19 (deprecated)
    fatal_error("unsupported arch", arch_string)
dword_2A5F314 = sm                                # line 296

The single most heavily-consumed derived global (31 read sites) -- it drives almost every architecture-conditional code path in the linker, from profile lookup to relocation type selection to ELF flag construction.

byte_2A5F220, byte_2A5F221, byte_2A5F229 -- runtime-set companion flags

These three live in the option-globals region but are written by sub_426570 (the per-module link iterator), not by the CLI parser. Their decision trees fire while ingesting each input object:

# sub_426570 (per-module iteration), lines 93-240
if (!byte_2A5F221 || !sub_43E610(...) || sub_4709E0(...)):
    ...
elif (!byte_2A5F229):
    byte_2A5F229 = 1                              # first matched module marker
...
if (<module exposes target-mode metadata>):
    byte_2A5F220 = 1                              # at least one module forced target mode
...
byte_2A5F221 = 1                                  # marks the first module that flipped state

byte_2A5F221 and byte_2A5F229 form a two-stage gate that prevents the iterator from applying a module-derived override more than once. Documented here because they share BSS space and registration semantics with the true CLI globals, even though they are derived from input objects rather than argv.

byte_2A5F244, byte_2A5F24C, dword_2A5F240..dword_2A5F274 -- merge-consistency tracker

Owned by sub_42AF40 (the merge-consistency tracker called for each input module). Each dword_2A5F26C/268/264/260/270 field implements the same state machine used to detect cross-module flag disagreement:

# Per scalar option that must match across all input modules:
#   state 0: unset
#   state 1: every module read so far had value V (recorded in companion field)
#   state 2: at least one module deviated
#   state 3: cross-module conflict detected
state = current
if (module_has_value):
    if (state == 0):    state, recorded_value = 2, v
    elif (state == 1):
        if (v == recorded_value):  state = 3
        elif (v != recorded_value): state = 4
    ...
else:
    if (state == 2):    state = 3
    elif (state == 0):  state = 1

The merge tracker reads back into sub_426CD0 (which feeds it as --has-global-host-info / per-module switches to the embedded ptxas). These globals are CLI-shaped only because they share registration prototype with byte_2A5F244/byte_2A5F24C, but their values come exclusively from runtime aggregation, not argv.

Internally-Synthesized Sub-Tool Flags (Not nvlink CLI Surface)

nvlink_strings.json contains a number of flag-shaped string literals that are not registered with option_register and are therefore not part of nvlink's CLI surface. They fall into two groups:

1. Flags nvlink emits when invoking the embedded ptxas backend. Constructed in sub_426CD0 (LTO compile-driver) and consumed inside the embedded ptxas core at sub_110*/sub_111*. Representative strings:
   • -link-lto, -inline-info, -has-global-host-info, --device-c, --force-device-c (emitted by sub_426CD0 based on parsed nvlink globals such as byte_2A5F244, byte_2A5F286, byte_2A5F285)
   • -generate-line-info, --compile-only, --extensible-whole-program, --fast-compile, --device-debug, --blocks-are-clusters, --assume-extern-functions-do-not-sync, --compile-as-tools-patch, --legacy-bar-warp-wide-behavior, --first-reserved-rreg, --no-membermask-overlap, --print-potentially-overlapping-membermasks, --opportunistic-finalization-lvl, --binary-kind, --okey, --assyscall, -forcetext, -dump-perf-stats, -dump-perf-metrics-file, --ptx-length, -ptxlen (all referenced only from ptxas-internal functions in the 0x1104000-0x1113000 range)
2. Format/diagnostic fragments that look like flags -- e.g. -arch=compute_%d, -cuda-api-version=%s, -split-compile=%d, -Ofast-compile=, -fma=, -ftz=, -prec-div=, -prec-sqrt=. These are sprintf templates the linker uses to construct ptxas/cicc command lines from parsed option values.

Users wanting to control any of the group-1 flags must pass them through --Xptxas (forwarded to the embedded ptxas) or --Xnvvm (forwarded to cicc), not directly to nvlink. The ptxas wiki documents the full ptxas option surface; see LTO Option Forwarding for how forwarding is wired.

Response File Expansion

The option_parse_argv function (0x42E5A0) handles response files (also called options files) through the --options-file / -optf mechanism and the @file prefix. When the parser encounters an argument beginning with @, it reads the referenced file and expands its contents as additional command-line arguments in-place. This is recursive: a response file can reference other response files.

The --options-file option (type 0 = file-list, multiplicity 2) achieves the same effect through the parser's file-list processing infrastructure.

Interaction with Main

The nvlink_parse_options function is called exactly once from main (0x409800):

// In main():
arena = arena_create_named("nvlink option parser");     // sub_432020
// ... also creates "nvlink memory space" arena ...
nvlink_parse_options(argc, argv);                        // sub_427AE0
// All global variables are now populated.
// main() reads them directly for all subsequent pipeline decisions.

After nvlink_parse_options returns, the parser object itself is no longer referenced. All option values have been extracted into the global variables listed above, and the rest of the linker pipeline accesses those globals directly.

Cross-References

• CLI Flags Reference -- complete alphabetically-sorted quick-reference table of all 68 flags with types, defaults, and visibility
• Pipeline Overview -- how parsed flags drive mode dispatch and the 14-phase pipeline
• Entry Point & Main -- main() calling context for nvlink_parse_options
• Mode Dispatch -- how dword_2A77DC0 (set during option parsing) selects the code path
• ptxas Option Forwarding -- how --Xptxas options are forwarded to the embedded ptxas compiler
• LTO Option Forwarding -- how --Xptxas, --Xnvvm, --maxrregcount, and --Ofast-compile are forwarded to cicc/ptxas during LTO
• Dead Code Elimination -- how --kernels-used, --variables-used, --use-host-info, and --ignore-host-info drive DCE
• Debug Options -- detailed semantics of --debug, --suppress-debug-info, --edbg
• Environment Variables -- environment variables that supplement CLI options (e.g., LIBRARY_PATH)
• Architecture Profiles -- how --arch maps to the per-architecture vtable used throughout the pipeline
• Compatibility -- cross-architecture matching rules gated by the parsed SM number
• cicc wiki: CLI Flags -- cicc compiler CLI flags. The parser framework (option entry struct, hash table lookup, argv scanning) is shared infrastructure between nvlink, cicc, and ptxas
• ptxas wiki: CLI Options -- ptxas CLI options, using the same shared parser framework

Confidence Assessment