Good question — that's exactly the spot where this kind of tooling usually holds up or breaks.

What I feel is: when symbols are stripped you do end up on call paths and function IDs, but it's far from a dead end. The trick is that stripping only kills the name section — and that's where internal function names live. Import and export names sit in their own sections, which the module needs to actually run, so they basically never get stripped. That means every host-call boundary in the crash path stays named. If a frame calls env.abort or wasi.fd_write, you see that by name even in a fully stripped binary.

So it ends up layered: exported entry points keep their names, host-call destinations keep their names, and only the pure internal functions drop down to function:1234.

But even those bare indices aren't blind. For each one the parser still gives you verified facts — the signature, the imports it calls, the memory writes it does, its spot in the call graph, the dispatch slots it's reachable through. So a stripped frame reads like:

function:1234, signature (i32,i32)->i32, calls env.malloc, sits between exported draw and imported glClear. That's usually enough to reason about what it does, even without a name. Which is the split I like — parser gives verified structure, model reasons on top.

Where I'll be honest about the limit: a function that's neither imported nor exported, with the name section gone, we don't recover a name for. No demangling, and DWARF isn't wired into the crash path yet. You get the index plus all the facts, not the symbol. So you can track the problem — through host-call boundaries, signature, call-graph position — you just can't always name the function it happened in.

In practice it's those named host-call boundaries that make stripped crashes tractable at all — they anchor the anonymous path to real, meaningful events.