This adds three tests in total:  - Whether afl-showmap produces the same coverage for the same input in stdin mode.  - whether afl-showmap produces the same coverage for the same input when using -i and @@;  - whether afl-showmap produces different coverage for different inputs when using -i and @@ (see issue#2602).

Add afl-showmap tests

…nsposed-args build failure

…atibility

…e mutator and target execfix(gramatron): switch JSON backend to cJSON and add standalone test runner- Replace json-c usage with cJSON to avoid build and maintenance issues- Refactor RNG handling into a standalone module- Add run-test.sh to validate Gramatron with an instrumented target- Update build script to include new sources and test flowThis prepares Gramatron for easier maintenance and testing.

fix: Update gramatron build script to use CMake and fix GCC 14+ compatibility

added json-parser.h

The splicing code was copying from the beginning of new_buf (offset 0)instead of from split_at. This meant the spliced result contained:- Bytes 0 to split_at-1 from in_buf (correct)- Bytes 0 to len-split_at-1 from new_buf (incorrect)The correct behavior for splicing is to take:- Head (0 to split_at-1) from the current input- Tail (split_at to len-1) from the target inputFixed in both fuzz_one_original() and mopt_common_fuzzing().

Null entries can appear in the middle of llvm.global_ctors whenoptimization passes remove constructor functions. Using 'break'caused constructors after null entries to be missed.Changed to 'continue' to match LLVM's CtorUtils.cpp behavior.

The sign bit detection for negative constants was using decimal literalsinstead of hexadecimal, causing the checks to always fail:  (val & 80000000)           // Wrong: decimal 80000000 = 0x4C4B400  (val & 0x80000000)         // Correct: checks bit 31  (val & 8000000000000000)   // Wrong: decimal, not the sign bit  (val & 0x8000000000000000) // Correct: checks bit 63This bug prevented proper secondary token generation (val-1) for signedcomparisons with negative constants, reducing dictionary effectivenessfor fuzzing signed integer comparisons.

The range checks for extracting integer constants excluded boundaryvalues due to using strict inequality (> and <) instead of inclusivecomparisons (>= and <=):Before:  if (val > 0x10000 && val < 0xffffffff) len = 4;  if (val > 0x100000001 ...) len = 8;After:  if (val >= 0x10000 && val <= 0xffffffff) len = 4;  if (val > 0xffffffff ...) len = 8;This caused useful boundary constants like 0x10000 (65536) and0xffffffff (UINT32_MAX) to be missed, as well as creating a gapwhere 0x100000000 and 0x100000001 were not extracted.

Previously only operand 1 was checked for constants, but LLVM may placeconstants in either operand depending on the comparison direction andoptimization level. For example:  if (x > 0x1234)  // constant likely in operand 1  if (0x1234 > x)  // constant may be in operand 0While LLVM's InstCombine typically canonicalizes constants to operand 1,this isn't guaranteed at -O0 or with certain IR patterns. Now we checkoperand 1 first, then fall back to operand 0 if no constant is found.

…return valueThe code was checking TmpStr.empty() to determine if getConstantStringInfo()found a constant string, but the StringRef may not be cleared on failure.When the same TmpStr variable was reused for both strcmp arguments, anon-constant argument could incorrectly appear to contain the previousargument's string value.Example bug scenario:  strcmp("CONST", variable)  // CONST in arg0Before: Both args showed "CONST"(true) due to stale TmpStrAfter:  arg0="CONST"(true), arg1=""(false) - correctly extracts CONSTFix: Check the return value of getConstantStringInfo() which returns trueonly when a constant string is actually found.Ref: LLVM ValueTracking.h - getConstantStringInfo() returns bool indicatingwhether a constant string was found.

… text

When AFL_LLVM_CTX_K is enabled, the context restoration in return blockswas incorrectly using IRB (which inserts at block start) instead ofPost_IRB (which inserts before the return instruction).This caused function calls within return blocks to see the wrong context:the caller's context instead of the current function's context.Bug locations fixed:- Line 596: Non-instrumented return blocks (more_than_one != 1 path)- Line 792: Instrumented return blocksThe fix ensures context is restored AFTER any calls in the block,right before the return instruction, so called functions see thecorrect K-CTX context.

This test verifies that cmplog instrumentation correctly identifiesand skips back-edge comparisons in loop constructs. Currently FAILSdue to bug where continue statement only breaks inner loop.Tests for, while, do-while, nested, and countdown loops.

Fix splicing to copy from correct offset in target file

Fix bug causing most inputs being marked as non-text even if they are

Fix bug causing integers being truncated in ASCII mutator

dict2file fixes

Fix K-CTX context restoration in return blocks

llvm-common: skip null entries in global_ctors instead of breaking

The original code used `continue` inside a for-loop iterating oversuccessor blocks:    for (BasicBlock *B : BR->successors())      if (IsBackEdge(BR->getParent(), B, DT)) continue;This only skips the inner for-loop iteration; consequently, it alwaysadds cmplog instrumentation, even for loop conditions. The fix uses aboolean flag to properly track when a back-edge is found and skip thecomparison entirely.Additionally, extend IsBackEdge() to follow chains of blocks that haveonly one successor (containing just PHI nodes and an unconditionalbranch). These empty blocks are inserted by sanitizer coverageinstrumentation and could eventually lead to a back-edge that wouldotherwise be missed.

cmplog back-edge detection bug

Replace manual block-walking back-edge detection with LLVM'sLoopInfo analysis for more robust loop condition skipping.

cmplog: use LoopInfo for loop condition detection