3 ms·

I wonder why there's no protocol that simply tells the debugger that to pretty-print type X, it should call function Y in the debugged executable itself (using

I wonder why there's no protocol that simply tells the debugger that to pretty-print type X, it should call function Y in the debugged executable itself (using normal C ABI and some agreed-on calling convention). Then, for example, rustc could just generate simple glue functions that delegate to `Debug::fmt` in order to get formatting that the programmer is already familiar with or indeed has implemented themselves. (Some precautionary measures would of course be required to avoid infinite recursion and similar. But the same issues already exist in debuggers that allow pretty-printers to eg. run arbitrary python code. To avoid a pathological or buggy formatter breaking either the debugged program or the debugger itself, it might be best to execute the formatter in a separate child process.)

progbits 3y ago
Of course those would have to be side-effect free, or somehow "sandboxed". It seems like debug printers should be pure functions but you never know what sort of weird stuff people do.
- eklitzke 3y ago
  Even just formatting something as a string will likely require memory allocation for all but the most trivial cases, and memory allocation is not side effect free.
- yencabulator 3y ago
  Take the already-frozen process, make a clone with CoW memory, switch the clone to a sandbox that forbids most syscalls, run the pretty-printer function(s) in the clone process, abort if pretty-printing takes too long (hung on lock, infinite loop due to corrupt data structure, etc)? Lots of devils in the details, but that sounds possible.
  - mark_undoio 3y ago
    You're quite right, it's very possible. The product I work on does pretty much exactly this - we need it because our debugger time travels and we can't allow history to be altered! I wrote some words here: https://medium.com/time-travel-debugging/calling-functions-in-the-past-4bb03bdc124d https://medium.com/time-travel-debugging/calling-functions-i... But it's basically exactly what you propose. We didn't sandbox the syscalls but you could do that too.
ratmice 3y ago
The impetus for python, rather than making a call into the inferior/debugged process is largely to support pretty printing data structures within core files & crash dumps. While it is certainly possible, it is not a small amount of work to generate pretty printers to run in the debugger likely involving an entire toolchain to compile the `Debug` traits to. The easiest way is probably compiling Debug traits to wasm, with the existing python pretty printers calling into that would be my best guess at a good starting point.
- tomjakubowski 3y ago
  That's a really neat use case for wasm. And, if there were debugger support for wasm pretty-printers, it would be easy to support in language toolchains which already compile to wasm.

progbits 3y ago

Of course those would have to be side-effect free, or somehow "sandboxed". It seems like debug printers should be pure functions but you never know what sort of weird stuff people do.

eklitzke 3y ago
Even just formatting something as a string will likely require memory allocation for all but the most trivial cases, and memory allocation is not side effect free.
yencabulator 3y ago
Take the already-frozen process, make a clone with CoW memory, switch the clone to a sandbox that forbids most syscalls, run the pretty-printer function(s) in the clone process, abort if pretty-printing takes too long (hung on lock, infinite loop due to corrupt data structure, etc)? Lots of devils in the details, but that sounds possible.
- mark_undoio 3y ago
  You're quite right, it's very possible. The product I work on does pretty much exactly this - we need it because our debugger time travels and we can't allow history to be altered! I wrote some words here: https://medium.com/time-travel-debugging/calling-functions-in-the-past-4bb03bdc124d https://medium.com/time-travel-debugging/calling-functions-i... But it's basically exactly what you propose. We didn't sandbox the syscalls but you could do that too.

ratmice 3y ago

The impetus for python, rather than making a call into the inferior/debugged process is largely to support pretty printing data structures within core files & crash dumps. While it is certainly possible, it is not a small amount of work to generate pretty printers to run in the debugger likely involving an entire toolchain to compile the `Debug` traits to. The easiest way is probably compiling Debug traits to wasm, with the existing python pretty printers calling into that would be my best guess at a good starting point.

tomjakubowski 3y ago
That's a really neat use case for wasm. And, if there were debugger support for wasm pretty-printers, it would be easy to support in language toolchains which already compile to wasm.