java-topology/defects/gdb-scan/CLEAN.md

56 lines
3.2 KiB
Markdown

# GDB (GNU Debugger) — 5-MOAD Scan
**Source:** https://github.com/bminor/binutils-gdb (depth=1 snapshot 2026-03-31)
**Scan date:** 2026-03-31
## MOAD-0001 (CWE-407) — CLEAN
Our scan examined our primary hot paths:
- `gdb/breakpoint.c``build_bpstat_chain()` iterates `all_breakpoints()` with nested
`all_bp_locations_at_addr()` using binary search (`std::equal_range`). `update_global_location_list()`
sorts `bp_locations` then uses a sorted-scan duplicate-detection algorithm. No O(N^2) inner loops.
- `gdb/symtab.c` — Symbol cache uses a hash-bucketed `symbol_cache_slot` array. Block lookup
(`block_lookup_symbol`) delegates to a dictionary (hashtable). No linear membership inside outer loop.
- `gdb/dwarf2/read.c` — DWARF CU processing uses `gdb::unordered_set` for visited sets throughout.
`visited_not_found` / `visited_found` are explicit hash sets.
- `gdb/dwarf2/abbrev.h` — Abbrev table stored as `std::unordered_set` with custom hash.
- `gdb/dwarf2/cooked-index-shard.c``find()` uses `std::equal_range` (binary search) on sorted vector.
- `gdb/inline-frame.c``inline_states` is a small vector (one entry per active thread).
`find_inline_frame_state()` is O(T) where T = thread count, called once per frame unwind.
Not a scaling defect in practice.
- `gdb/solib-svr4.c``glibc_tls_slots` uses `std::find` to locate empty slot on SO load
(fill) and locate slot by address on SO unload (erase). This is O(S) per SO load event
where S = number of TLS-bearing SOs, giving O(S^2) across startup. With S typically < 100
for real programs, this amounts to < 5,000 comparisons total. Severity: NEGLIGIBLE.
- `gdb/cp-namespace.c` `found_symbols` is a `std::map` (ordered by name). Not a vector.
- `gdb/ada-lang.c` Exception dedup uses `std::sort` + `std::unique` (O(N log N)).
**Verdict: CLEAN.** Our codebase uses hash tables, binary search, and sorted arrays consistently
throughout all hot paths. No actionable O(N^2) defects found.
## MOAD-0002 (Intertangle) — CLEAN
GDB uses `current_program_space`, `current_inferior()`, and thread globals extensively.
This is a known architectural design (single active inferior at a time) with a well-defined
execution model, not an accidental coupling. Each command operates on an explicit context.
No unintended cross-phase state bleed found.
## MOAD-0003 (Leaked Context) — CLEAN
`gdb/complaints.c` uses `thread_local complaint_interceptor*` this is a controlled,
intentional use to redirect diagnostic output during symbol reading. It is scoped to the
main UI thread only (`gdb_assert (is_main_thread())` enforces this). Not a request-scoped
identity leak.
## MOAD-0004 (CWE-312 Logged Credentials) — CLEAN
GDB's RSP (remote serial protocol) in `gdb/remote.c` does not implement authentication.
No auth tokens, passwords, or credentials pass through the GDB remote protocol layer.
`remote_debug` output logs protocol packets but none contain credentials.
## MOAD-0005 (Thundering Herd) — CLEAN / NOT APPLICABLE
GDB is architecturally single-threaded for all analysis operations. The UI thread is the
only thread that accesses symbol tables, breakpoints, and inferior state. No concurrent
cache access patterns possible. MOAD-0005 does not apply.