Hello.
I think it is a good idea to add creating debug information and debugger to FASM.

See here for how to use symbolic debugging with an external debugger.

Thank you! I didn't know it.
But as for me, FASM debugger, reading .FAS files directly (without converting to other formats) would be very useful. It also could be included in the standard IDE.

It is much more fun to debug without the symbols!

You should check Fresh IDE
It have some very useful debugging features build-in. (including still-not-finished debugger)

Yes, it has, but it crashes too often... And I could not find breakpoints in it.

When I was writing fasmw, I initially planned to have integrated source-level debugger there (the F8 key is reserved for that purpose), but I never got to that point - and later situation became more complex as 64 bits arrived and as I decided to have ports of IDE to multiple OSes (well, that is an unfinished task, too - I have still not decided which technology use to port fasm's IDE to Linux). When I realized that I will never write a portable debugger to be integrated into fasm's IDE, I focused on providing the 'fas' output, so that other people could write external debuggers (or plug-ins for existing debuggers) which could allow source-level debugging with fasm.

fasmw can be made to execute some external debugger upon hitting F8 key, but I need to know of at least one good debugger that could be recommended for such integration. If any of you is looking for some serious project to start, I'd suggest making some good 32-bit/64-bit debugger with .fas support - maybe based on fdbg? I would give it a subdomain on .flatssembler.net if it was promising.

That sounds to be a good idea.
I would like to have an x86 debugger in FASM.
Would this work with WINXP and/or WIN7 ?

A post-compile debugger in discution? yeah!!!

First good thing, before to have a debugger, would really to have ctrl+F8 generating .fas AND .lst too. with opening of the generated listing in a new tab. that would be still really nice.
i think that this part, apparentlly not so usefull or powerfull, can induce pretty good ideas , and is open to many improvements, and is still a good technique just in case of crash at a particular adress, we just have to read back in listing and get the source of error. but generating a listing is really a cure with the current method and takes too much time. i frequentlly should write the adress on paper before to finally get the listing.

and why not, with F8, just open the listing AND run the output file too, via a custom command line in fasm configuration file.

nothing after, forbid to evolve the F8 button to a real debugger,
and recover the ctrl+F8 to only .fas generation.

why not a feature to link .fas opening to a hexadecimal editor via command line in configuration file too?



that would still be a lot of work.

edfed, the listing file is pretty useless for big projects, because it becomes really huge.
Fresh IDE have almost working listing feature, but I never managed/wanted to refine it, namely because it is useless.
The contemporary IDE needs advanced code browsing and debugging features.

hem, for now, we just don't have easy listing as a simple solution for little projects with fasmw.exe. even if useless for big projects, i believe that 90% of the codes compiled on fasmw all around the world are relativelly little codes, like less than 20klines listing equivalent. and easy listing is better than nothing.

of course, project with more than 400klines would be very slow.

but even fasmw listing is like 43klines (1.69.34 gives a 42605 lines, with two blank lines at the end.), and it's not so long finally and would be perfectlly exploitable in real debuging situations.
.

Well, I myself can't process listing of 10klines. No, I probably can, but I refuse to do it! There are many, easier and faster ways to fix the bug or to see what particular lines of code generate.
I simply can't imagine what problem the listing file will solve easier than the alternative ways/tools. (well maybe except macro writing/debugging - but again, a tool that can show what the particular macro line generates will be much more useful).

All whats needed for nice debugging is a real-time addresses of all functions.
And that is needed when debugger loaded the module.
Like 'View Names' feature in OllyDbg.
So, I can simply break on entry to ANY procedure and start from there.
This would be nice!

Maybe but have projects with short listings.
Could be a good idea to have a command for switch listing on and off during source code. This could be very helpful, the listing of the part you working on.



would be nice commands when they can be used repeatedly in source.
And listing off could be default when compilation starts.

Sometimes you see things in listings which you damn not see in your written source code. That is the mystic of programming. Just another view can open your eyes.

You could write a custom listing generator that would recognize some special commands in source to cut some pieces out, that should be relatively easy. I encourage any projects of better .fas-processing tools, the ones provided in fasm's package are just simple examples, which can be used as a starting points for development of some advanced ones.

BTW, what I really need is cross reference. But IMHO, it is impossible to be created from the .fas file content.

Explain cross reference.

@mindcooler:
It is the information on who calls which functions, I believe.

Like:
Label at address xxxxxxx is referenced from addresses: xxx, xxx, xxx...
Label at address xxxxxxx is referenced from addresses:

That ^^^ last one is a label, which never gets referenced -- good to know.

fasm currently only keeps the information that label was referenced (the same flag that you test with "used" operator), it does not collect the list of referencing lines. But if it was collecting such info, the .fas format could easily be extended to accommodate it.

Sounds more like the job for a static analyzer. Labels are the easiest symbols to get into a debugger.