> what sort of debugging is this called

I've always simply called it "debugging", as opposed to "printf debugging" or "not debugging"

> Or do they?

They do. At least for compiled languages - the few interpreted ones that I have tried usually didn't (or I just didn't find out how). How have you been debugging thus far?

serialShinobi wrote on 2024-02-23, 18:42:

I am wondering what sort of debugging is this called. Are all C/C++ debuggers for the PC like this old 1994 Codeview? Do they all depend on an executable? How does it know what your *.c source code file was?

It’s recorded in the debug info attached to the executable.

If I remember correctly, these type of debuggers were known as Symbolic Debuggers. When you build your EXE you can ask the compiler to embed symbolic information in the EXE (there are a few different formats, Borland used their own for Turbo Debugger) which would increase the size (and reduce the execution speed) of the EXE but it would allow for easier debugging in a tool like CodeView. Once you're confident that you've solved your bugs, you compile without debugging info and you get a slimmer and faster EXE that you can ship.

elszgensa wrote on 2024-02-23, 19:09:

> what sort of debugging is this called […]
Show full quote

> what sort of debugging is this called

I've always simply called it "debugging", as opposed to "printf debugging" or "not debugging"

> Or do they?

How have you been debugging thus far?

The only memory I have was using printf. I have never debugged a program as far as I know. I have done troubleshooting with Linux CLI. Now that I think of it, I once tried (failed) to compile source for a game emulator in Linux. I had to back track through libraries to discover SDL functions that were discontinued from SDL2. It was also for a dot net machine and mono in Linux was not a solution (but I *thought* they were compatible).

What surprises me is all the times I heard of debugging and how one can step through lines of code. Apparently you can't just step through lines of code.

There needs to be some way to have compiled code first then one can step through source code.

Didn't catch on that I was being misinformed.

> There needs to be some way to have compiled code first then one can step through source code.

Well yes, a CPU can only execute machine code after all, not plain text.

What's going on under the hood is that the compiler/linker writes out a mapping saying "address x in the elf/exe file corresponds to line y (or var z, or whatever) in file widget.c". Then at runtime, the debugger looks where the program counter is pointing to at that moment in time, looks up where in the source code text file that is and jumps to that line. It does not care at all about the contents of that file as long as it has enough lines for it to jump to (you can replace it with bible.txt if you want... or edit the code after compiling but before debugging, throwing things out of sync. Makes the hunt for errors extra fun.)

pan069 wrote on 2024-02-23, 20:50:

If I remember correctly, these type of debuggers were known as Symbolic Debuggers...you compile without debugging info and you get a slimmer and faster EXE that you can ship.

That's very interesting how history is playing out. All this time I really knew very little about debugging. So it's all new to me. Knowing this about debugging is the kind of thing you only find by trying yourself and asking others questions. It has been an important experience for me.

elszgensa wrote on 2024-02-23, 22:58:

> There needs to be some way to have compiled code first then one can step through source code.

Well yes, a CPU can only execute machine code after all, not plain text.

Yes. That's why I am surprised people think you can just step through source code instructions. I never thought so. I just got confused and ignored attempts to communicate. I wish I had realized sooner about matters relating to the role of binary code when developing software.

What's going on under the hood is that the compiler/linker writes out a mapping saying "address x in the elf/exe file corresponds to line y (or var z, or whatever) in file widget.c". Then at runtime, the debugger looks where the program counter is pointing to...

Yes. I hope to learn more about debuggers, debugging, and software development for microprocessor based computers.

Thanks for clarifying how symbolic debuggers work.

[in addition to MSVC 1.52 1994 and my 486DX]

I happen to be working with an ATmega328p. AVR studio makes a "debug" build of the project and it's source code. The result is elf and elf converted to ihex (Intel hex). But the explanation in the docs was that you can only run the debug version on a simulator and vice versa you need a release version to run on the hardware device. I was probably being purposely confused by the docs - I bet you can run the debug version on the hardware device - they just don't want you to do so because it would create the appearance of poor performance of their code - a chief issue in the embedded community.