flat assembler
Message board for the users of flat assembler.

Index > Main > source-level debugging for assembly : is it useful?

Author
Thread Post new topic Reply to topic
buzzkill



Joined: 15 Mar 2009
Posts: 111
Location: the nether lands
buzzkill
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 Smile , 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 Smile

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 Smile
Post 04 Apr 2009, 23:46
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17271
Location: In your JS exploiting you and your system
revolution
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.
Post 05 Apr 2009, 04:48
View user's profile Send private message Visit poster's website Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 2913
Location: [RSP+8*5]
bitRAKE
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.
Post 05 Apr 2009, 05:03
View user's profile Send private message Visit poster's website Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
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.
Post 05 Apr 2009, 10:04
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
buzzkill



Joined: 15 Mar 2009
Posts: 111
Location: the nether lands
buzzkill
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?).
Post 05 Apr 2009, 19:16
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17271
Location: In your JS exploiting you and your system
revolution
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.
Post 05 Apr 2009, 19:24
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17271
Location: In your JS exploiting you and your system
revolution
buzzkill wrote:
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.
Wrong way to look at it. Keeping two windows in sync is a lot harder than simply having it together in one window.
buzzkill wrote:

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?).
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.
Post 05 Apr 2009, 19:28
View user's profile Send private message Visit poster's website Reply with quote
buzzkill



Joined: 15 Mar 2009
Posts: 111
Location: the nether lands
buzzkill
revolution wrote:
Wrong way to look at it. Keeping two windows in sync is a lot harder than simply having it together in one window.


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.

revolution wrote:
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.


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.
Post 05 Apr 2009, 19:55
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17271
Location: In your JS exploiting you and your system
revolution
buzzkill wrote:
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.
Post 05 Apr 2009, 19:58
View user's profile Send private message Visit poster's website Reply with quote
buzzkill



Joined: 15 Mar 2009
Posts: 111
Location: the nether lands
buzzkill
revolution wrote:
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...
Post 05 Apr 2009, 20:11
View user's profile Send private message Reply with quote
bogdanontanu



Joined: 07 Jan 2004
Posts: 403
Location: Sol. Earth. Europe. Romania. Bucuresti
bogdanontanu
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 Wink (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.
Post 06 Apr 2009, 11:10
View user's profile Send private message Visit poster's website Reply with quote
buzzkill



Joined: 15 Mar 2009
Posts: 111
Location: the nether lands
buzzkill
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.
Post 06 Apr 2009, 12:06
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17271
Location: In your JS exploiting you and your system
revolution
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.
Post 06 Apr 2009, 13:05
View user's profile Send private message Visit poster's website Reply with quote
buzzkill



Joined: 15 Mar 2009
Posts: 111
Location: the nether lands
buzzkill
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.
Post 06 Apr 2009, 13:39
View user's profile Send private message Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
for example when you have very complicate structures, like "mov eax, [ebx + STRUC.MEMBER1.Size]", numeric offset here can easily conceal error.
Post 06 Apr 2009, 14:24
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
buzzkill



Joined: 15 Mar 2009
Posts: 111
Location: the nether lands
buzzkill
thanks vid, that's the kind of information I'm looking for.
Post 06 Apr 2009, 14:36
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar.

Powered by rwasa.