It's sad that some of ideas at the forefront of the early LISP machines and Smalltalk systems didn't make it into the mainstream culture. They had fantastic system level debugging support that you sorely miss when it's not available anymore. Unfortunately operating systems need to be built from the ground up with this thinking to fully benefit from the idea, user-mode debuggers have unfornate limits needing to sit on all that code, but I look forward to giving RAD Debugger a try soon nonetheless.
I hope you are eventually be going over topics like DWARF.
Eli Bendersky has a good couple of articles on debuggers too.
I work in embedded software so with remote debugging, we dont have the luxury of PTrace and rely on RTOS/architecture support. But this just makes me appreciate the fundamentals even more.
The intricate details of DWARF aren't in scope for this series, but I plan on defining the information that debug info stores, how it is encoded, and relating it to how it's concretely stored in the RAD Debug Info format (RDI), which we currently produce by converting PDBs (and soon will produce by converting DWARF info), so it's all going to be the same information.
How the DWARF spec decides to actually encode that information (which is unfortunately done extremely poorly) is secondary to the point of this series, but given the building blocks in this series, readers will at least know what to look for, and how to begin unpacking something like the DWARF spec. Although, hopefully, there is no need sometime soon.
Sounds intriguing, since I dont know a thing about PDBs (and just now heard that you guys have your own format). I rely mostly on elf/dwarf formats with remote debugging on a Linux host.
But DWARF is crazy town, I havent had the need to go fully through its design spec. They try to be language, architecture and OS independent while also claiming to be compact.
Yeeeeeaaaah, DWARF is kind of a nightmare :) It tries to simultaneously be completely generic, and extremely compact, and so it is a massive explosion of complexity. I very strongly suspect that it will lose dramatically in compression compared to, well, actual tuned compression algorithms on a much more sparse/regular format, and so really all you get in the end is a much more complicated format than necessary.
It will never fully go away because it defines so many parts, including things which you can't rely on PDBs for in Windows, like unwind information, but it'd be great if modern / simpler formats can be a better alternative in the future, for especially the most basic usage of debug information (symbolizing, source line mapping, analyzing type info, etc.), and most of what debuggers use debug info for (save unwind information, which can't be stripped like the rest of debug info).
Looking forward to this.
It's sad that some of ideas at the forefront of the early LISP machines and Smalltalk systems didn't make it into the mainstream culture. They had fantastic system level debugging support that you sorely miss when it's not available anymore. Unfortunately operating systems need to be built from the ground up with this thinking to fully benefit from the idea, user-mode debuggers have unfornate limits needing to sit on all that code, but I look forward to giving RAD Debugger a try soon nonetheless.
I hope you are eventually be going over topics like DWARF.
Eli Bendersky has a good couple of articles on debuggers too.
I work in embedded software so with remote debugging, we dont have the luxury of PTrace and rely on RTOS/architecture support. But this just makes me appreciate the fundamentals even more.
The intricate details of DWARF aren't in scope for this series, but I plan on defining the information that debug info stores, how it is encoded, and relating it to how it's concretely stored in the RAD Debug Info format (RDI), which we currently produce by converting PDBs (and soon will produce by converting DWARF info), so it's all going to be the same information.
How the DWARF spec decides to actually encode that information (which is unfortunately done extremely poorly) is secondary to the point of this series, but given the building blocks in this series, readers will at least know what to look for, and how to begin unpacking something like the DWARF spec. Although, hopefully, there is no need sometime soon.
Sounds intriguing, since I dont know a thing about PDBs (and just now heard that you guys have your own format). I rely mostly on elf/dwarf formats with remote debugging on a Linux host.
But DWARF is crazy town, I havent had the need to go fully through its design spec. They try to be language, architecture and OS independent while also claiming to be compact.
Im stoked to see how things work in RDB!
Yeeeeeaaaah, DWARF is kind of a nightmare :) It tries to simultaneously be completely generic, and extremely compact, and so it is a massive explosion of complexity. I very strongly suspect that it will lose dramatically in compression compared to, well, actual tuned compression algorithms on a much more sparse/regular format, and so really all you get in the end is a much more complicated format than necessary.
It will never fully go away because it defines so many parts, including things which you can't rely on PDBs for in Windows, like unwind information, but it'd be great if modern / simpler formats can be a better alternative in the future, for especially the most basic usage of debug information (symbolizing, source line mapping, analyzing type info, etc.), and most of what debuggers use debug info for (save unwind information, which can't be stripped like the rest of debug info).