NETWORK_REPORT: machine-generated coverage -- 26 unmapped entries found and mapped

Replaces the 30-address spot check with a mechanical pass: every report address
is classified against the MMTM prologue table, so interior labels are shown to
be interior rather than asserted. 225 addresses, 82 mapped, 143 unmapped, of
which 102 fall inside a mapped function and 41 sit in 26 unmapped entries.

Maps those 26: arpresolve (if_ether.c:261) for 0x3F60FB60, ifa_ifwithnet
(if.c:189) for 0x3F623180, tcp_respond (tcp_subr.c:112) for 0x3F6BD9F0,
leerror (if_le.c:972) for 0x3F9DAFF0, the leintr TINT half for 0x3F9D8A50,
leinit/lereset for 0x3F9D27D0, the tcp timer pair for 0x3F604C30, and marks the
rest firmware-specific with the reason.

Also corrects the RX entry: the function starts at 0x3F602DB0, not 0x3F602E00.
This commit is contained in:
arti committed 2026-10-30 11:25:54 +02:00
1 parent c02d475678
commit 8ff16b5b73
1 file changed
+65
+65
View File
@@ -4082,3 +4082,68 @@ which reports 225 addresses in the report and 66 inside the mapping sections.
The difference is dominated by internal labels; every one of those belongs to an
entry point that *is* in a row. The entry points themselves are enumerated above
and in sections 53–58.
## 60. Machine-generated coverage: every entry point, not a spot check
Section 59.3's 30-address check was a spot check and 59.1's "internal labels"
claim was an assertion. This section replaces both with a mechanical
classification of **every** address the report mentions.
### 60.1 Method
```python
unmapped = all_report_addresses - addresses_in_sections_53_59
entries = sites whose first instruction is MMTM (0x098f)
covered = unmapped addresses whose enclosing entry is in a mapping row
orphans = the rest -> their enclosing entry needs a row
```
Result:
```
report addresses 225
in a mapping row 82
unmapped 143
of which covered by a mapped
enclosing function 102
in an unmapped entry 41 -> 26 distinct entry points
```
So the honest answer to "are all found addresses mapped?" was **no** — 26
function entries were missing. They are listed and mapped below.
### 60.2 The 26 entries
| ROM | status |
|---|---|
| `0x3F60FB60` | **ARP resolve** — contains the `arpresolve: no free entry` log site `0x3F610660` → `arpresolve()` `if_ether.c:261` |
| `0x3F623180` | **interface lookup by network** → `ifa_ifwithnet()` `sys/net/if.c:189` |
| `0x3F60EE00` | deferred ARP callback (registered at `0x3F614340`) — firmware-specific deferred work |
| `0x3F6BD9F0` | **`tcp_respond()` `sys/netinet/tcp_subr.c:112`** — builds the ACK from the SYN_RECEIVED handler |
| `0x3F9DAFF0` | **`leerror()` `sys/pmax/dev/if_le.c:972`** — called with `(5)` from the ISR on `ERR` |
| `0x3F9D8A50` | the TINT half of **`leintr()` `if_le.c:501`** (TX completion) |
| `0x3F9D27D0` | the driver's **`leinit()`/`lereset()`** path (contains the CSR/init-block writes) |
| `0x3F602DB0` | the receive function — **entry of the deferred-RX glue** (see 60.3) |
| `0x3F604C30` | contains `0x3F606010`/`0x3F606210` → the **`tcp_fasttimo()`/`tcp_slowtimo()`** pair (`tcp_timer.c:51`/`:76`) |
| `0x3F5FFD90`, `0x3F60C100`, `0x3F6166D0`, `0x3F623940`, `0x3F6448E0`, `0x3F64FE90`, `0x3F653610`, `0x3F65A0C0`, `0x3F660000`, `0x3F662410`, `0x3F675C40`, `0x3F9E14C0`, `0x3FA7C050`, `0x3FE21120` | **firmware-specific** — helpers inside the protocol/OS layers with no 4.4BSD counterpart found (each was checked for a prologue and for call sites; the codec dispatcher `0x3F660000` and the protocol-id dispatcher's default `0x3F65A0C0` are covered by 57.1–57.3) |
| `0x3F634600` | **firmware-specific** — the default IP-protocol handler that dumps the packet (BSD's equivalent is the silent `bad:` drop at `ip_input.c:368`, which has no body to map to) |
| `0x3FA932D0`, `0x3FA935D0` | **firmware OS interrupt stubs** (`0x3FA935D0` calls the diagnostics handler `0x3FDD8E80`) |
### 60.3 Correction: the RX function entry is `0x3F602DB0`
Sections 30.1 and 56.2 call `0x3F602E00` the receive entry. The prologue scan
shows the function starts at **`0x3F602DB0`** (`mmtm sp,a9,a11,a13`); `0x3F602E00`
is its third instruction. The mapping row should therefore be
`0x3F602DB0` (deferred-RX glue), with `0x3F602E00` as an interior label.
### 60.4 Coverage statement (replaces 56.3/57.5/58.5/59.3)
> Every function **entry point** the report mentions now has a mapping row:
> a quoted 4.4BSD counterpart where one exists, otherwise an explicit
> firmware-specific entry naming why. Interior labels and call sites are
> covered by their enclosing entry, and that is checked mechanically by the
> script in 60.1 rather than by inspection.
The remaining honest caveat: for the fourteen entries marked firmware-specific
in 60.2 I did not find a counterpart; that is a statement about my search, not a
proof that none exists.