2 ms·

Does that neutral way of debugging work as well as having first-class explicit support for the language, or it's more of a lowest common denominator (kind of li

Does that neutral way of debugging work as well as having first-class explicit support for the language, or it's more of a lowest common denominator (kind of like what e.g. language support over LSP can offer and how conveniently, compared to what a native Lisp or Smalltalk environment's language support can offer)?

asveikau 2y ago
One debugger feature I thought of while writing the comment was the ?? command in windbg. That takes an expression and evaluates it. Gdb also does this which I've used with the "print" command to print a C expression, including pointer casts and such. That would obviously require language support. But then again you don't need to code everything in the same language either. You could write a rust parser in another language. Or a modular interface to dispatch knowledge of a programming language (does Microsoft's "language server" concept work this way?)
Veserv 2y ago
The latter. The neutral way of debugging is really debugging the raw machine code of a process. This requires OS integration for your low level manipulation primitives. To add language support, you then need to figure out how to define the semantics of your manipulations in terms of the low-level primitives. If you have a rich runtime, you can add language-level debugging facilities that can operate at a higher level. However, this requires you to implement portions of a debugger in your runtime. Now you have to maintain a language, runtime, and debugger. It also means that if new debugger techniques are invented, such as time travel debugging, you do not get them for free since you embedded a debugger of your own design. So, like many similar things, it is a trade-off of specialization versus maintenance. The perennial question of use a library, or do it yourself.

2 ms·

Does that neutral way of debugging work as well as having first-class explicit support for the language, or it's more of a lowest common denominator (kind of li

by coldtea 2y ago

asveikau 2y ago
One debugger feature I thought of while writing the comment was the ?? command in windbg. That takes an expression and evaluates it. Gdb also does this which I've used with the "print" command to print a C expression, including pointer casts and such. That would obviously require language support. But then again you don't need to code everything in the same language either. You could write a rust parser in another language. Or a modular interface to dispatch knowledge of a programming language (does Microsoft's "language server" concept work this way?)
Veserv 2y ago
The latter. The neutral way of debugging is really debugging the raw machine code of a process. This requires OS integration for your low level manipulation primitives. To add language support, you then need to figure out how to define the semantics of your manipulations in terms of the low-level primitives. If you have a rich runtime, you can add language-level debugging facilities that can operate at a higher level. However, this requires you to implement portions of a debugger in your runtime. Now you have to maintain a language, runtime, and debugger. It also means that if new debugger techniques are invented, such as time travel debugging, you do not get them for free since you embedded a debugger of your own design. So, like many similar things, it is a trade-off of specialization versus maintenance. The perennial question of use a library, or do it yourself.