Finally I have managed to make some listing feature for fasm, you can see it in the attachment - maybe it's far from being perfect, but it's best what I could do without rewriting the most parts of the compiler. And that's the reason why I'm still not sure whether I should put this feature into the official releases. What do you think?

When I think of listing this is how I imagine it's layout:


would be listed as:

I'd rather se the code *after* the macros are processed, thus seeing push and call instead of invoke. And I'd prefer not seeing the equates, rather their value as they're used (thus "mov eax, EquateForOne" would be lsited as "mov eax, 1" if the equate has the value 1, the definition of the equate doesn't need to be seen , but it doesn't need to be hiden either).
The address/offset row should just be present for code lines, not for comments or empty lines or lines that aren't getting any code (such as section lines, "format" directive), labels have the address/offset row present.

One question, when listing a PE file, the MZ isnt shown, it's skipped (the PE header starts at format PE ), is this intentionall?

At last, any comments on my comments?

As I said, it's best what I could do - if I was able to simply do the things you're writing about, I would do it.
Anyway, it could be done, but with wasting the terrible amount of time and memory - there would be some second program catching from fasm the information about what line it currently processes and at what offset (and what "org") it currently generates code. But it would have to store all that information somewhere and use it when it's known that it was the last assembly pass, and otherwise drop it and start collecting again. I can provide enough information how to do it if anyone has some spare time and want to make such listing application (it'd be also useful for source-level debugging, as not only file offsets, but also "org"-addresses would be collected).

Also, preprocessed lines would look rather ugly in listing, as the source is converted into fasm's internal format (with spacings and comments dropped, and all words converted to that specific preprocessor's code) before preprocessing, so these lines don't exist in text form (I've made a small routine that converts them back to text, it is used by FASMW error handler, but that conversion is ugly).

Oh, that's how it's actually working. But the "section" or "format" lines do generate a code - alignment bytes, headers, etc. - that's why they have some bytes listed to the left.

Sonuds like a lot of time would be needed, too bad this semester just has started -- I whish I had more/enougth time, but I've got (too) many things to do, several unfinished pojects, and school (<- biggest issue). (and not to forget, I've gotten my self a real life too -- something I haven't had for a few years, I've missed it)
But if it remains undone next summer (the winter holiday isn't impossible, but not likley) and if I got the time, then I might be able to help (sorry, can't promise anything) -- unless I find it to be over my skills (I'm begining to realize I have limits to my abillities :/ )

Due to the specifics of fasm internals, a good listing feature was nearly impossible to add - as the assembler itself operates not on the source lines, but on the specific pre-code. And this pre-code can be seen as a kind of script, which generates the output program; for example labels in the source become actually an "operations" in pre-code, their op-codes tell assembler to store actual address in appropriate place, which can be then referred by other pre-code operations, like the operations which tell assembler to put the opcode of some x86 instruction into output. Also some features like "repeat" are just an operations in pre-code, so they don't really generate any repeated source, this is only a piece of pre-code that is processed given amount of times to generate repeated output.

That all made it very hard to provide any useful listing and for a long time I was refusing to even try doing it, as I thought it was impossible. But, as you can see, I've finally done something - but I'm not proud of it. It is not at the same level of quality as the rest of fasm, and it can't be - some of the reason I've written above, there are more of them. What makes fasm powerful in other fields, makes it a weak when it comes to listing.

So I've decided that I won't include this poor listing feature in the official releases, but I will make it available as a small add-on, which can be simply added to the fasm's source in order to recompile it with that additional feature.

Anyway, is listing really needed? I was always using some good disassemblers instead, I can recommend IDA for example (there is a free version). Or BIEW if you need something multiplatform.

thank Privalov!!!

Hi,

As I have lobbied for in the Debug thread, having that information would be enough for an external tool to produce a listing.

I am starting to play with the 1.47 listing capability (I use Win32 console or Linux) and will create a small script to extract that information into a debug form. However, the reality is that going from a listing to create debug info is more difficult than using debug info to create a listing.

I think it is very useful to include this listing feature in the official release, and another feature different to listing is expanding the macros when they are used. vid also request for this.

I don't know whether this is difficult to implement.

I tried and come to a realization, that 1.52 and 1.48(/w listing) are incompatible:(
it would be cool if one could implement it in 1.52+
thanks

P.S. if such an old topic is answered then that means it is important

Just to get a listing to find out where the symbols are mapped into a DLL or EXE file would be a huge help in debugging. It's easy enough to get a dissambler or debug tool to work to trap exceptions. (I actually use the one that comes with MS Visual C++.) Unfortunately it is difficult to figure out where in the source a given exception occurs without some kind of symbol mapping.

Well, for now I am using, Fresh's function "goto address" - [ctrl-G]. In the future Fresh will have full futured source level debuger. (It works now, but it miss some important features and still is not very useful.)

http://fresh.flatassembler.net

Regards.