Debugger for C

[mark4]

I have been working in software for at lest 40 years now. I am currently writing a simulator / debugger for the Dallas DS5001 processor to use at work because it has absolutely NO debug capabilities built in. I have been reverse engineering the Keil extensions to the OMF51 file format by Inntel (not their code).

I can already debug at the assembler level, I already know how to associate opcodes with source file line numbers… just a few other details to figure out and I will have a full source level debugger I can use…

I can say that after 40 years of debugging code on a daily basis that the single most horrendously IMPOSSIBLE to use debugger I have ever experienced is GDB. It is even worse than the ICE for the NEC75x which only displayed opcodes AFTER you stepped them lol.

It does not matter what front end interface is put on it, They are all just lipstick on a horrendously ugly PIG.

OTOH, if there were a built in GDB interface in sublime text *NOT a plugin) that showed the disassembly or C sources in one dedicated area of a tab, the registers in another dedicated area of the tab, a configurable dump in hex bytes / words / dwords in another area of the tab and a PROPER display of the top N items on the stack whether they were part of a dumb STACK FRAME or not…

That would be awesome!?

[KarloSiric]

Interesting, I don’t know much about what you just said quite frankly, not that experienced, but nontheless, do you know which debugger that is not GDB is go to choice for debugging in C, since I have trouble setting up the debugger I debug using printfs

[mark4]

Depends on your system. For linux you have GDB, GDB, GDB, GDB or GDB. And the only front ends you have for this are horrendously unweildy, unmanageable and imho utterly unusable interfaces.

I am actually in the process of writing a debugger for the 8051 micro controller and have been reverse engieering the Keil custom AOMF file format. I pretty much understand 100% of this format now except the way it describes structures and Ill get that part figured out soon enough. My debugger is actually a simulator for the Dallas DS5001 controller and will have source level debug or symbolically disassembled asm level (that part already works).

Not since the good old days of dos has there been a single decent debugging environment other than printf’s. For example, debugging assembler is pretty much a lost cause with GDB. It can do it but it moronically assumes that you are debugging the output of a C compiler and assumes there is a “stack frame” and in some instances it will just get downright uppity with you if you ask it to jump to an address it does not think contains code.

EVen with gdb -tui (the curses interface) it wont display source or disassembly in this window, a selected memory range in that window, registers in this window over here and a display of the top N items on the stack. If it does not recognize a stack frame it wont display any of it. When not using the curses interface it simply PUKES OUT the data you want to see every step, scrolling it all off view as it goes. This makes debugging HORRIFACLLY PAINFUL because NOTHING stays situated in one place other than the sources you are stepping through. everything else just SCROLLS off view constantly.

A good debuger will have a memory window and if anything changes in that memroy window it will give you are VISUAL INDICATION of that change.

Gdb has dozens of front ends, the vast majority of them are abandoned efforts to give GDB a usable interface and every single one of them utterly failed to even come close to doing so before they were abandoned.

If Sublime HQ can produce a clean interface for GDB that puts everything you need to be watching every gime you single step in a dedicated STATIC LOCATION on the display that would be freeeeeeeeking awesome. I dont think it will ever be made however and if anyone writes a plugin to do this it will probably be just as bad as every other interface the unwashed masses every produced for GDB.
< / rant > : )

[KarloSiric]

Wow I find it interesting to read this, obviously I had no idea how many of these things work but now that I read what you said it does make a bit more sense to me. Before I used Sublime I started with VS Code, and that’s a whole story on it’s own but I didn’t really like vs code.

Still it is not fair to compare Sublime with VS Code as they don’t technically fall under the same category of editors. I prefer Sublime 1000x over vs code don’t get me wrong, but the one thing I actually miss from vs code is the debugger itself.

I think their debugger is really solid and good, it displays in a side window step by step of what is actually going on, how variables change the value, and also the step by step highlight, so what step is the next one and so on, I mean you get the picture without my horrendous explanation anyways .

I think implementing something like that would really be useful for Sublime users, don’t know if it will ever be implemented and until it does I will get used to debugging with printf’s I guess. Someone also told me once, that debugging with printf’s is actually very useful and can be better than having an actual debugger, but I guess that is all up for debate

[Release-Candidate]

First, als already said, there is no GDB for MacOS ARM64 anyway, so you are using LLDB (LLVMs debugger). I haven’t used it for more than a decade (more like at least 15 years), but the best overall debugger is still Totalview I guess, especially, since Memoryscape - the memory debugger, which had been an extra program back than - is included now.

I think their debugger is really solid and good, it displays in a side window step by step of what is actually going on, how variables change the value, and also the step by step highlight, so what step is the next one and so on, I mean you get the picture without my horrendous explanation anyways

Well, you are using the same debugger executable (codelldb when using LLDB) with the same configuration in Sublime Text as with VS Code, the interface is only slightly different - about as much as the LSP interface in Sublime Text vs. VS Code (I actually did use the same debuggers in VS Code and Sublime Text). So, if you get LLDB to work in VS Code, the same configuration with little variation in syntax works with Sublime Text and any other editor which supports the Debug Adapter Protocol (DAP).

And as I’ve already said: if you would post your project configuration, I could help you and make it work.

Depends on your system. For linux you have GDB, GDB, GDB, GDB or GDB.

It would really be a good idea if you would stop confusing beginners with information which is misleading at best.
First, the OP is using MacOS on ARM64, there is no working GDB on that architecture at all.
Second, for Linux there are GDB (GCC’s debugger) and LLDB (LLVM’s/clang’s debugger), the Intel debugger (if you happen to use an AMD64 or x86 CPU), Totalview and the Arm Forge Debugger (TFKA DDT) and others I didn’t mention.
Third: the debugger frontend used by the third party (not by Sublime HQ) Debugger package, which uses the Debug Adapter Protocol (DAP) to get a graphical frontend for the many supported debuggers. This DAP is used by VS Code - like LSP - and an interface used by other editors/IDEs to present a single graphical frontend to many different debuggers (for languages like C, C++, Rust, Fortran, Go, Python …).

[Release-Candidate]

An image of how the debugger view looks like using LLDB on MacOS:

[Release-Candidate]

Someone also told me once, that debugging with printf’s is actually very useful and can be better than having an actual debugger, but I guess that is all up for debate

And sorry to add another post, but in reality you must use both. As using a debugger is often the easiest way to debug during development but not always possible and as soon as the program is “out there” you’re getting log files/traces at best.

[KarloSiric]

I thank you for all the helpful information you have provided me here I will sure give it another try at setting this up and see how it goes, I really do need a debugger because of later projects I might try doing in C and it will be really useful to have it around.

[KarloSiric]

As far as my project configuration goes, I deleted the debugger and I decided to install the debugger fresh from scratch because I want to setup this up properly so here are the images reagrding the setup of the project:

Also this is the image I get when I try to run the debugger with the settings from the first image I posted here:

. Now I sort of understand the error I am getting but I am not sure what needs to be done in order to fix it.

Now the first image is simply the setup when I go to Debugger: Add Configuration, I select LLDB and then Launch setting, and the second image is simply Debugger: Edit Configurations.

Now I am not sure what to setup and what not here as I have never been setting a debugger like this so I will wait for your feedback to proceed with, thanks once again.

[Release-Candidate]

The <program> part is meant for you to fill in the actual path of the generated executable to debug.
And the command line arguments the executable needs go into the args array.

You need one of these Launch stanzas for each executable you want to debug, like

"debugger_configurations": [
		{
			"type": "lldb",
			"request": "launch",
			"name": "Debug EXECUTABLE1",
			"program": "${folder}/EXECUTABLE1",
			"args": [],
			"cwd": "${folder}",
			"stopOnEntry": false
		},
		{
			"type": "lldb",
			"request": "launch",
			"name": "Debug OTHER/DIR/EXECUTABLE2",
			"program": "${folder}/OTHER/DIR/EXECUTABLE2",
			"args": [],
			"cwd": "${folder}/OTHER/DIR/",
			"stopOnEntry": false
		},
	],

[KarloSiric]

Okay I see now, well that also means each new file I make I have to compile it into an executable and then put the new configuration into the debugger with the name of that specific file in order for the debugger to work. Is there like any other way for this to work other than this or do I have to manually do this each and every time?

[Release-Candidate]

That’s the kind of problems you’ve got as a beginner, later the number of source files per executable is greater than 1. Take it as a kind of training to get better at writing project files ;).

Of course, nothing is stopping you from writing a script that adds the correct build system and debugger stanza for each new file you want to debug.

[KarloSiric]

I will keep that in mind, thank you for sharing all of this and thanks for your help as well!

[KarloSiric]

Hey, can you please looking at my program file tree at the side give an example of what should go where for this, because I am confused thouroughly with how this executables are supposed to go and what not.

It would be easier for me to understand if you give and example as to how this should be done on my case so that I know for future references because quite frankly I have never done this and I am stuck again.

[Release-Candidate]

Sure, will do. Hmm, you’ve got quite some files

If I see that correctly, Problem1 is the executable of source file Problem1.c and so on …, and all sources and executables are in the sub-directory C_Euler_Project.

If so, the correct debugger_configurations stanza is this:

	"debugger_configurations": [
		{
			"type": "lldb",
			"request": "launch",
			"name": "Debug Program1",
			"program": "${folder}/C_Euler_Project/Program1",
			"args": [],
			"cwd": "${folder}",
			"stopOnEntry": false
		},
		{
			"type": "lldb",
			"request": "launch",
			"name": "Debug Program2",
			"program": "${folder}/C_Euler_Project/Program2",
			"args": [],
			"cwd": "${folder}",
			"stopOnEntry": false
		},
		{
			"type": "lldb",
			"request": "launch",
			"name": "Debug Program3",
			"program": "${folder}/C_Euler_Project/Program3",
			"args": [],
			"cwd": "${folder}",
			"stopOnEntry": false
		},
		...
	],

You could also add build_systems stanza to build the executables, like so:

	"build_systems": [
		{
			"name": "Debug Build Program1",
			"cmd": [
				"clang",
				"-Wall",
				"-pedantic",
				"-g",
				"-std=c17",
				"-o",
				"./C_Euler_Project/Program1",
				"./C_Euler_Project/Program1.c"
			],
			"working_dir": "${folder}",
		},
		{
			"name": "Debug Build Program2",
			"cmd": [
				"clang",
				"-Wall",
				"-pedantic",
				"-g",
				"-std=c17",
				"-o",
				"./C_Euler_Project/Program2",
				"./C_Euler_Project/Program2.c"
			],
			"working_dir": "${folder}",
		},
		...
	]

The elements of the array cmd is the command line for clang to compile each source file with debug information enabled -g and the C standard set to C17 (-std=c17) and pedantic warnings enabled.

[KarloSiric]

Yeah quite some files because I am doing this C programming for this Project Euler which is slowly starting to be demanding so I need the debugger for that reason. Also the stuff you have provided, I have copy pasted it and still I get the same error as before with not being able to locate the project and so fort.

[Release-Candidate]

Then we need to look at the exact path in the project configuration (which is cut off in the screenshot) and the actual path of the project configuration in Project_Euler_C.

Posting the actual error message should solve that problem, I guess

[KarloSiric]

Okay yeah, I forgot to post the error, but the error makes no sense to me at all because the path seems to be set correctly, anyways here are the screenshots:

Here you can see that the path is set correctly in the debugger configuration.
Here is the screenshot of the path of the project:

And finally here is what the error says:

As far as I can tell everything seems to be in order with the path, guess I am blind

[Release-Candidate]

guess I am blind

We both are - I needed quite some time even now knowing that the path must be wrong

Your sources and executables are called “ProblemN”, but I used “ProgramN”. So changing all file names to the real ones should solve that.

[KarloSiric]

I really am blind . Thank really appreciate your help on this, I will give it a try later but it should work now, I will let you know if there is still something left.