3 ms·

I'm not so sure of this. Most code in a debugger doesn't have much to do with the source language. Line mapping and figuring out values for variables happens vi

I'm not so sure of this. Most code in a debugger doesn't have much to do with the source language. Line mapping and figuring out values for variables happens via symbol information, eg. DWARF, and compilers for multiple languages can produce that in the same format.

coldtea 2y ago
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.

coldtea 2y ago

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.