Hello guys!
It has been a while since I posted something here, the reason is that a series of unfortunate events occurred in my life which prevented me from programming at all. Only last October I returned back to my normal life, and first thing that I did was firing up emacs and checking out state of the debugger. First impulse was to burn everything to the ground and start over, but lucky me that a more rational thought followed it. Starting over will not change anything, and it is better to work on the existing code. After looking around I decided that it is time to get rid of the DIA library (Microsoft's COM disaster to read PDB). At the start I was not even sure that I will be able to write a replacement for that, however as time went by I found that there is nothing hard about it. I limited parser to a certain subset of symbols, which helped a lot because PDB has a lot of legacy stuff in it. Removing the DIA also forced me to write a stack unwinder. It is always a good thing to remove a black box out of a project. In this case it means that we are no longer tied to the windows and it will be much easier to port debugger to the Linux later.
Next on the list was to improve UI rendering. Before I had a loop that would redraws screen all the time, like you would see in a game and in context of a game this is totally fine, but it is not when you have mostly an idle UI. New system will only re-render regions that have changed, which will help to save a lot of CPU work. And while I was changing UI code a decision was made to improve the font rendering too. Debugger was using FreeType to render glyphs and I already knew that it is possible to tweak it to output LCD glyphs for sub-pixel text rendering, and the trick here was to make it work with OpenGL. First, I tried to look around the internet for some pointers, but after an hour of searching I gave up and did it myself. I will write an article about sub-pixel text rendering with FreeType and OpenGL soon, because in my opinion a lot of people will benefit from this knowledge, and I hope 4coder will implement it so I can finally ditch emacs :)
This concludes list of all major changes that were done, and I hope that you can help me improve debugger by trying it out yourself. Please leave your feedback in comments or just email me at [email protected]. I also put a little demo video together on youtube and you can download debugger here.
CDbg Build 0.0.0.5
Comments
That sounds awesome, I can't wait for the next blog post. By the way, this project's status is still "on hiatus", you probably should change that.
This looks super cool. Can I ask what you're using for the UI - is it all custom? I've considered several times writing my own UI system over OpenGL, but I always get stuck trying to do decent font rendering. I'd be really interested to hear more about your system.
Yes, UI is all custom. I also got stuck doing the font render, and it took me a while to make it output good looking glyphs. I will write about this in the next blog post.
First of all, fantastic work!
Its generally pretty intuitive to use, it feels much more responsive than VS, and respects my screen real-estate. I like that a lot!
I had a little play around and had a couple of issues.
When booting cdbg each time, it always prompts me to "Search for an app in the store?". After hitting "no", the app then starts up correctly. I presume this a windows 10 issue.
Attempting to step-into a function would instead always just step-over? Putting a breakpoint in the function does correctly breakpoint in the function.
Similarly, when the program is not executing, attempting to step into the first line causes the program to just execute without breaking in.
When opening an executable, the file dialog spells "executalbe" incorrectly. ;)
It would be really nice to have a gui for the commands. Remembering things is hard.
Its generally pretty intuitive to use, it feels much more responsive than VS, and respects my screen real-estate. I like that a lot!
I had a little play around and had a couple of issues.
When booting cdbg each time, it always prompts me to "Search for an app in the store?". After hitting "no", the app then starts up correctly. I presume this a windows 10 issue.
Attempting to step-into a function would instead always just step-over? Putting a breakpoint in the function does correctly breakpoint in the function.
Similarly, when the program is not executing, attempting to step into the first line causes the program to just execute without breaking in.
When opening an executable, the file dialog spells "executalbe" incorrectly. ;)
It would be really nice to have a gui for the commands. Remembering things is hard.
Let me know if you prefer we remove the On Hiatus status on your behalf.
EDIT: Nick contacted me. Project is active again.
EDIT: Nick contacted me. Project is active again.
Thanks a lot for the feedback. I was wondering if you can send me assembly where debugger has problem stepping into a procedure. This sounds like instruction decoder fails to resolve address that will be called and just skips that instruction, or it could be a bug in the PDB parser that fails to find a procedure and makes tracer to skip it. Also, can you tell me name of the entry that is in your program? Debugger scans for names like "main", "WinMain", and looks like it does not find one and proceeds to execute. It is not the most elegant solution to handle break at the entry, but it works :) Much better would be to lookup entry name in a PDB, but I don't know if compiler writes that information.
No problem! I emailed you a repro executable, not sure if you received it?
The entry point is a bit of a weird pattern to support both msvc subsystems (console & windows). It appears as follows.
The entry point is a bit of a weird pattern to support both msvc subsystems (console & windows). It appears as follows.
1 2 3 4 5 6 7 8 | extern int __cdecl main(int argc, char* argv[]);
int _stdcall WinMain(HINSTANCE, HINSTANCE, char*, int) { return main(__argc, __argv); }
// ...
int main(int argc, char* argv[]) {
// ...
}
|