The .pdata arm of the gap-only rules: measured at 47 false positives, and inert on dumps

[r0ny123]

Follow-up to #324, and the third of the three rules named in the sweep there. Filed with its measurement rather than as a to-do, because the number is small enough that it should decide whether this is worth doing at all.

Implemented and measured in #329, stacked on #327.

The shape

Three rules refuse a candidate on evidence the image declares, and all three are reached only from the gap scan — they test self.gap_pointer. #327 widens the .eh_frame one to a candidate from any source. The other two are:

• USE_LSDA_LANDING_PADS — nothing left to reach. Of 302 false positives still standing on four AArch64 static cells after feat(common): refuse a candidate the image declares interior, not only a gap one #327, none is a declared landing pad. A pad is interior by construction and the gap scan is what finds it, so the gap pointer is where its evidence is exhausted. Nothing to do here.
• USE_PE_X64_PDATA_INTERIOR_GAPS — this one, below.

What widening the .pdata rule is worth

Measured over the full corpus, feat/fde-interior-analysis-gate (#327) → #329, so the figures isolate this arm:

corpus	n	TP	ΔFP
Built C/C++ MinGW PE x64	120	unchanged	−47
Built Rust, windows-gnu-x64	2	unchanged	−2

Everything else is bit-identical — 140 x86-64 ELF cells, 72 AArch64 ELF, 23 Go, 11 ARM64 Mach-O, the ELF and 32-bit Rust cells, and all 57 malpedia dumps. Only PE x64 cells move in any corpus, and no corpus loses a true positive.

Correction to the first version of this issue. I opened it quoting 14 of 1,038 from a 20-cell sample and scaled that to roughly 80 across the 120 cells. Both numbers were wrong as a statement about the corpus: the sample was a real measurement of 20 cells, the extrapolation was not a measurement of anything. The corpus figure is 47. The table below is what the sample actually showed, kept because the per-class split is only measured there.

20 MinGW x64 PE cells, with #327 applied	count
remaining false positives	1,038
interior to a declared RUNTIME_FUNCTION extent	59
— primary record, owner not recovered	40
— primary record, owner recovered and its extent surrounds the address	14
— primary record, owner recovered but its extent does not surround	5
— fragment record	0

The 45 that are interior but not refused are declined by the two conditions that keep the rule from costing recall: an owner the analysis never recovered says nothing about what covers the address, and an extent that does not surround it is the shape that cost three true positives on AArch64 in #327.

The part worth knowing before deciding

On memory dumps the rule is inert, and not because of any guard. None of the 57 malpedia dumps declares an exception directory at all — _pdata_ranges is empty, so the rule never gets as far as its first condition. That is the corpus this project cares most about, and this evidence source does not reach it.

Between those two facts the case is thin: 47 false positives on one PE corpus, nothing on dumps. It is real, it is free of recall risk under the existing guards, and it is a small change on top of #327 — but it is not the 683 false positives the .eh_frame arm was worth, and it moves PE, which is exactly the control that makes #327 easy to read.

Where it stands

#329 is open, green, and stacked on #327. Closing this and dropping #329 is a reasonable call on these numbers; the measurement is the argument either way.