I am working on a frontend for GDB:


It's vary far from a complete product, but if you want to help me out with testing please get a hold of me on IRC or Discord, I only want a few people to start with, probably add more as it gets closer to being finished

This is looking really neat! Have you gotten any testers? It looks like 4coder is a requirement for this to work, is that right? I'd be happy to provide 4coder to one or two testers to try this out, if they don't have a copy and need it.

Thanks for the offer! Right now it can run with or without 4coder, but without 4coder, there isn't any interface to the source code.

I have actually been struggling to figure out the best way to proceed. These are my scatterbrained thoughts:

• So I was thinking of providing multiple editor interface modules, and I feel like I have a good handle on how to do an Emacs and a 4coder interface. With that and also I had someone graciously offer to test who is on emacs I was thinking I could, for the time being, directly provide/support modules for those editors. However the more I thought about it, I could spend a lot of time working on those while the debugger at its core is still missing basic features.
  
• I was also thinking that I could just make an API that handles the editor interfacing, and then have the user compile and link in their implementations, much like the 4coder super customization layer. I feel like this might be the best route to support editors like Glyphin and Vim, both of which might benefit from someone who is more familiar with those editors to write the interfacing implementation.... However, I think it's way to early to get into designing what the API should be for that.
  
• Im now thinking that it would be best to take a step backwards from editor integration altogether. I skipped over any source browsing functionality in the debugger because I wanted first-class support for editor interaction as one of the primary features of the debugger, however that seems more and more premature, so I'm thinking it would be best to just go ahead and implement a basic read-only source code browser in the debugger, and that would simplify some things while I just focus on debugger core features
  
• Of-course I could stick with the original plan and just support 4coder...
  

Anyway I'd be interested in any feedback, suggestions, comments, concerns or insults :)

Nice, Croepha, good to see your work posted up here. I hope to catch you streaming again some time, it's great to see you tackling this. I know from speaking to people around the HMN that there is a lot of interest in a good GDB front-end. Looking forward to seeing how this shapes up.

The GDB frontend is very promising, based on what I could see it already makes me switch to it. This is because when I started using Linux as my primary workspace, I missed a good debugger frontend, due to being used to the Visual Studio's debugger. Although one could say there are many frontend alternatives for GDB already available, it is easier to get used to something that is being developed and is Handmade at its heart.

This would be my personal wishlist for the future:

• Ability to load binary using CLI.
• Watch window (https://msdn.microsoft.com/en-us/library/aa290869(v=vs.71).aspx)
• Memory window (https://msdn.microsoft.com/en-us/library/s3aw423e.aspx)
• View and step through the disassembled code.
• Conditional breakpoints
• CPU Registers window

That would be all what comes to my mind at the moment.

Happy to be on board with this!

Looks good! Probably a few weeks late but:
I would say either support only one editor at first or make a standalone frontend, because of supporting dependencies if you want to make major changes to your software. But that's just me.

I've decided to make it standalone for the moment, but I think I might add some basic 4coder functionality soon (for mostly selfish reasons)

Croepha
I've decided to make it standalone for the moment,

Good job. Like Casey says, do one thing and do it really well.