Just wanted to start up a discussion here: a while back Tomasz posted (http://board.flatassembler.net/topic.php?p=91061#91061) a request for someone to write a program to convert .fas-files to DWARF format debug info on Linux. Now, I just quickly read through the DWARF specs (http://dwarfstd.org/Dwarf3Std.php), 267 pages of not-so-light reading, and am left wondering if it's even worth it to write something like that. (Seeing as how in DWARF everything is abstracted, because it has to be cross-platform and cross-language, so you have to use abstractions for eg register names instead of good old eax, etc.)

Let me explain what I mean: in HLLs, one statement consists of many assembly instructions, so you would use this debug info to "translate" between HLL and assembly. However, as you all know , in assembly there's pretty much a one-to-one translation between source lines and instructions in your binary/executable. And whether you're looking at a "xor eax,eax" in the source window or the disassembly window, doesn't make much of a difference

So I'd like to hear some opinions from people about whether or not "source-level" debugging really adds something over "instruction-level" debugging when it comes to assembly debugging. Especially users on other platforms (since Tomasz mentions in his post that there is such a conversion-tool for Windows) who have the ability to debug at the "source-level": what advantages does this give you, does it make debugging easier/faster, etc. Please explain to me what it is I'm missing out on with my instruction-level debugging

Source code can have comments and notes that a plain disassembly won't show. Even something simple like just knowing the names of the functions being called can be a big help.

Usually, I can open the source listing in a side-by-side fashion with the debugger (various) if needed. It is certainly possible to use multi-level abstractions (or even complex data structures) in assembly at the source level which make run-time (instruction level) reading more difficult.

I think it is not *so much* useful for all-asm apps (but people like MazeGen think it is, at least couple of years ago when we argued about it).

However, I think this becomes more important for convinient debugging of mixed C/FASM app, to have debug symbols for all parts of code, not just the C part.

Well, like bitRAKE said: nowadays you'd just put two windows/terminals side-by-side, one with the source, the other one with the instructions in the debugger, so for comments/notes I don't think it matters much.

For mixed C/asm I guess there could be some advantages, if it really works at a symbolic level, ie you have an "int foo" in a C function, and after you call your asm routine you'd still see the name "foo" for [ebp+8] and after a "mov eax, [ebp+8]" you'd see that it was "foo" in eax. But I don't know if symbolic info can be exchanged from C to asm, or back. Maybe someone with experience debugging mixed C/asm can tell us more about this?

BTW, I also noticed in the DWARF specs that a lot of languages are mentioned, but assembly is not one of them, so it would appear as if the DWARF people themselves think that it's only useful for HLLs (maybe mixed w/asm?).

The assembly side variable will have the name that was assigned with the extrn directive. This may or may not match the name of the variable as used in the C code but it is likely to be similar enough to make it clear what it refers to.

Wrong way to look at it. Keeping two windows in sync is a lot harder than simply having it together in one window. I think this is merely a reflection of the common modern usage of computer compilers. Just because a spec doesn't list a language hardly means it can used to justify not writing useful tools.

Well, I prefer to have my source in my favorite editor, where I get syntax highlighting, can look up or jump to tags/definitions etc. Besides, gdb has an interface where you can control it _from_ an editor, so you wouldn't have to adjust your windows manually.



I didn't mean to imply that, only to say that apparently they share the opinion that's also been vioced here, that symbolic debugging is more useful for HLLs.

I don't know if one can say "more useful", perhaps "more used" would be more appropriate. I think the usefulness would be quite similar, but the tools have been lacking and the use of assembly in general is less so the tools have been correspondingly less.

Yes, that has been my experience as well. Perhaps the tool-makers assume that asm programmers can make do with less advanced tools because they're alreasy used to doing a lot of work "by hand"?. Anyway, for me personally, I could think of some other (improvements to) tools that I would like to have, before symbolic debugging. But then again, maybe that's just me...

Yes, symbolic debugging as well as source level debugging are very usefull for ASM programming.

Mainly when you write huge fully ASM applications or in other words how applications should be written (contrary to popular belief)

Not having symbolic debugging support is unacceptable for a modern assembler.

It is good to see that lately FASM did some movements towards this direction.

bogdanontanu, can you give a (small) example where symbolic info helps with debugging? I would like to see for myself the advantages you get from it, especially since you're the first one to say it's important for all-asm apps, not just mixed HLL/asm.

buzzkill: It should be taken as a truism that source level debugging is useful without even having to ask. How could it possibly be harmful or of no consequence? Of course it is useful.

revolution: I never said it's harmful or of no consequence. I'm just saying that I personally have not yet encountered a situation where I felt I was "missing something" when debugging assembly at the instruction level. I'm asking for an example, so that I can learn how symbolic info would make my asm debugging faster/easier/whatever.

for example when you have very complicate structures, like "mov eax, [ebx + STRUC.MEMBER1.Size]", numeric offset here can easily conceal error.

thanks vid, that's the kind of information I'm looking for.