GNAT Dynamic Analysis Suite 27 Release Notes¶

We present here a few highlights of the new features in GNAT DAS 27. You can access the complete list in the GNAT DAS 27 feature file.

GNATcoverage instrumentation ¶

Support for non-Latin-1 in Ada sources ¶

“gnatcov instrument” may fail to parse Ada source files that have non-ASCII codepoints if the files are not encoded in Latin-1 (the default encoding in GNAT, and thus in gnatcov). It is now possible to specify the encoding of Ada source files with the –ada-default-charset switch passed to “gnatcov instrument” to get gnatcov to parse these source files correctly. Note that gnatcov is also able to detect the presence of -gnatW8 compiler switches in project files to select UTF-8 as the default encoding.

Extend integrated instrumentation support ¶

Add integrated instrumentation support to Windows and cross configurations.

Avoid instrumenting static decisions in C and C++¶

GNATcoverage now avoids performing MC/DC instrumentation of boolean decisions in static contexts, which formerly made the code invalid.

Incremental instrumentation ¶

GNATcoverage instrumentation now operates incrementally, thus it will not re-instrument sources with no code change between two instrumentations run, if the set of switches to the instrumentation command does not change.

GNATcoverage analysis and reports ¶

Automatic source relocation at reporting time ¶

When using gnatcov coverage, if a source file isn’t found at its absolute path, GNATcoverage will automatically try to search for it in the sources of the given project file, if given. This resolution method relies on matching the base name of the file, so it will fail if the project contains several source files with the same base name. Additionally, this feature is entirely disabled whenever the –source-rebase or –source-search options are given to GNATcoverage.

Gnatcov logging of coverage origins ¶

Gnatcov is now able to provide the origins of coverage. An origin of coverage of a Source Coverage Obligation (SCO) is a trace file or checkpoint that contributed to the computation of the “covered” or “partially covered” state of the SCO for a given coverage level. The logging of coverage origins can be enabled through the use of the switch “–origins” when computing coverage with “gnatcov coverage”. The origins of coverage are included in XML coverage reports.

Gnatcov trace reuse after source annotation changes ¶

It is now possible to pass to gnatcov coverage trace files produced with source files when these source files were amended to add/remove empty lines, comment-only lines, or annotations (pragma Annotate in Ada) after traces production. Note that in the case of instrumented sources, it is still necessary to reinstrument the source files before passing the trace files to gnatcov coverage.

GNATcoverage annotations and exemptions ¶

Add VSCode support for external annotations ¶

VSCode now displays external annotations in a tree-like view, below to the “Outline” panel on the left. External annotations are also visible by default in the editor, assuming the user specified an external annotation file in the project file. They can be toggled on and off. Finally, the user can create external annotations from the editor, at the cursor location, or by selecting a code region.

Extraction of in-source annotations ¶

GNATcoverage now has a “gnatcov extract-annotations” command to turn in-source annotations to external annotations. This commands also accepts a “-i” switch to remove in place the in-source annotations.

Fine-grained exemptions for code coverage ¶

In addition to the existing exemption regions supported in GNATcoverage, it is now possible to define exemptions that affect precise source-coverage obligations: a decision outcome, a condition, or provide evaluation vectors for a decision.

GNATcoverage usability ¶

“gnatcov setup”: new –compiler-prefix switch ¶

“gnatcov setup” now accepts the –compiler-prefix switch, as a convenient alternative for –prefix=DIR, where DIR is the installation prefix of the relevant compiler. This compiler is resolved according to the current target and RTS (–target/–RTS/–config/… switches).

Enhanced GNATcoverage limitations interface ¶

GNATcoverage used to emit several warnings because of tool limitations. It now features a distinct message category reserved for tool limitations. While these messages are not preceded by the “warning:” prefix, these messages will still trigger failure status code if –warnings-as-errors is passed to the gnatcov invocation. Limitation messages can be ignored by passing the newly introduced –suppress-limitations switch, in which case the messages will not be emitted. The corresponding “undetermined coverage” messages will still be present in the coverage report for the affected constructs. These warnings were not always actionable (for plain unsupported constructs), and ignoring these messages never led to a loss of information, as the limitations are also reported in the coverage reports in the form of “undetermined coverage” messages associated with the corresponding constructs.

Support for aggregate library projects in gnatcov ¶

GNATcoverage now accepts loading aggregate library projects: they were rejected when passed through -P to any gnatcov command.

GNATtest input generation ¶

Test input generation through constructor functions ¶

GNATtest can now generate test inputs using a "constructor" function. Once a constructor has been identified for a given type, either by an explicit user annotation or by searching for a suitable candidate, GNATtest will generate test inputs for the parameters of the constructor and will use its return value as input of the subprogram under test. This enables automatic test input generation for types that are not natively supported by gnattest, such as access types, or class-wide types, and also lets users provide a parametrized test input generation function more suited to the actual behavior of the subprogram under test.

Support discriminated tagged types in Gnattest ¶

Gnattest is now able to generate test values for discriminated tagged types with ‘–gen-test-vectors’. One limitation exists: the discriminants of the tagged type must not be used to constrain an array.

GNATtest stubbing ¶

Stubbing of imported subprograms ¶

GNATtest now stubs subprograms with an Import aspect or pragma. When needed, gnattest will duplicate the concerned spec file to remove the Import pragma or aspect and others related aspects. This feature is disabled by passing the flag –no-external-stub to gnattest.

GNATtest –recursive-stub switch now implies –stub ¶

GNATtest –recursive-stub switch used to need to be passed alongside –stub for recursive stubbing to occur. Now –recursive-stub automatically implies –stub and can be used on its own.

New option to select which unit to stub ¶

A new GNATtest switch –include-for-stubbing has been added which allows the user to select which unit to stub. This switch has an opposite effect to –exclude-from-stubbing.

GNATtest setup and project integration ¶

Extend the user project config in gnattest harness ¶

The gnattest_common.gpr file holding configuration for the harness and stub projects now extends the user project configuration. Note that this is the case for newly created harness only, as gnattest_common.gpr is not regenerated by a rerun.

Refactor GNATtest to pass more information to AUnit ¶

AUnit used to accept a single string that would contain information such as Sloc, unit name, test status (passed/failed),… To better support XML reporting, this string was transformed into a record with a field for each piece of information needed. GNATtest generator was updated to account for this new format.

Introduce a gnattest setup command ¶

The gnattest setup commands builds and installs AUnit, and TGen (the library used by gnattest for test generation capabilities and integration with gnatfuzz). It picks the adequate AUnit profile, according to the target and the runtime passed by the user.

GNATtest uses custom suffixes for generated sources ¶

The user gpr project file may define custom suffixes for Ada spec and body files. GNATtest now fetches this information from the project file and uses these suffixes for all files it will generate.

AUnit ¶

Support JUnit XML report format ¶

Add possibility to output test reports from AUnit in the JUnit XML format.

Add a Generic_Assert variant ¶

Add a Generic_Assert variant to AUnit, comparing an actual and an expected value, and displaying them when they differ.

GNATfuzz language and platform support ¶

Support for tagged types ¶

GNATfuzz can now fuzz subprograms whose parameters are of tagged types. See the GNATfuzz User’s Guide for the remaining limitations.

GNATfuzz support for Windows is out of beta ¶

GNATfuzz support on Windows is no longer a beta feature. The fuzz-everything and Hot-Spot workflows now also run on Windows, and overall reliability on this platform has been improved.

GNATfuzz support for the C language ¶

GNATfuzz can now fuzz C functions directly, with no need to write Ada bindings first. The atomic GNATfuzz commands support C, and the –asan switch detects memory errors. See the GNATfuzz User’s Guide for details.

GNATfuzz workflows ¶

New import-tgen-vectors utility command (beta)¶

The new “gnatfuzz import-tgen-vectors” command adds existing test vectors, for example those produced by GNATtest, to the starting corpus of a fuzzing campaign. This feature is in beta.

GNATfuzz Hot-Spot workflow (beta)¶

GNATfuzz has a new Hot-Spot workflow command that automates Static to Dynamic Analysis Security Testing verification. It takes a SARIF file of GNAT SAS static analysis warnings and uses fuzzing to determine which warnings can actually be triggered at run time. For each subprogram carrying warnings, the workflow generates a fuzzing harness (searching the call graph for a fuzzable caller when the subprogram cannot be fuzzed directly), runs a time-bounded campaign, and cross-references discovered crashes against the original warnings with a confidence rating. Results are written progressively to an augmented SARIF file containing reproducer commands, decoded crash inputs, and stack traces, alongside a combined GNATcoverage report. See gnatfuzz hot-spot –help for usage.

Add build stage ¶

A new stage called “build” has been introduced. Previously, the gnatfuzz generated harness was built during the fuzzing stage. As of now, the harness must be built using the “build” sub-command, allowing the reuse of the same harness between fuzzing campaigns. See the GNATfuzz User’s Guide for more details.

Introduce a minimize-corpus stage ¶

A dedicated, optional “minimize-corpus” stage has been introduced. Corpus minimization, which was previously integrated into the fuzzing stage, now requires explicit execution via the minimize-corpus command. This change enables manual management of minimized corpora and allows them to be reused across multiple fuzzing campaigns. For further details, please refer to the GNATfuzz User’s Guide.