Maybe I wasn't clear --- I think we agree on this point. Debugging parsing is different from (and in some ways, harder than) regular compiler parsing because users want to use familiar syntax that is different from regular program code. I can write print/x $pc+4 --- no C compiler interprets "$pc" to mean the program counter.

While it's true that it's a UI issue, this classification doesn't make the problem any easier.

> you could pretty easily extend DWARF to tell me how to call functions in C++

What extensions would you add? We already have stack-layout information, and the debugger implicitly knows the platform ABI.

> C++, debuggers are a tool of last resort

I've seen this phenomenon too, and it's upsetting: debuggers can be much more efficient. I've put a lot of work into making end-to-end debugging seamless, but I still see developers using traditional in-code tracing.

I want to try making Mozilla's rr available in an equally easy-consumed package and see whether the ability to reverse debugging begins to sway people.

> Second, you make the strange assumption an agent can't read or work with core files, and needs a live process?

I think we mean different things by "agent". I was talking about a remote stub that lives in the process to be debugged. If you instead move that logic to an pluggable component that the debugger merely hosts and that it uses as a general abstraction of how to debug targets of various sorts, debugging core files is feasible. (But in that case, how is it different conceptually from struct target_ops, which we already have?)