Any way to control listing

[PaoloR]

I have jsut started using NASM and wrote some macros.  So far everything looks good and binary works as expected.

Just one question about the listing.  In the list file I get the hex generated by NASM and a a LOT of macro tracing statement.  Is it possible to exclude the macro tracing statements and show only the code generated by the macros if any?

Also, when NASM shows code generated with local labels, it show the variable name used and not the actual label in the jmp statement.  At the same time no label or local variable name is shown for the statement that is a target of the jmp.  Any way to have the lsting show the actual label generated for both teh jmp statement and its target?

Overall, I fell I am already going at 95%.  That is a lot to say for this assembler.

Thanks and take care

 

[Frank Kotler]

Hi PaoloR,

You can use the ".nolist" qualifier when defining your macro (immediately following the number of parameters, with no spaces). You can also disable listing for sections of your code (macro or not) with "[list -]" (and turn it back on with "[list +]"). You probably want "%include 'windows.inc'" surrounded by these. Will some combination of those give you the control you want?

To be honest, I find listing files to be almost completely useless. They tell me what I already knew - namely what I just wrote. I find a disassembly much more informative. But other people find listing files very valuable, so perhaps it's just me. Maybe somebody who actually uses the things will have a better answer for you.

I don't think I understand the question about labels. Are you looking for the numerical address? (disassembly! - told ya listing files were useless ) Can you give us an example of what you'd like to "write" and what you'd like to "see"?

Best,
Frank

[/list][/list]

[PaoloR]

Hi Frank:

Thanks for the .nolist option.  I tested and it works.  It is also in the manual: my apologies for asking something I should have read about.

About macros and labels.  My background is in mainframes MVS (now called z/OS) assembler.  What I was  inquiring, is basically what I am used to, certainly not a necessity.  Here is am example:

Code: [Select]


%macro   EXAMPLE 0
         .
         .
         je      %%skip
         .
         .
         .
%%skip:  sub     eax,eax

%endmacro


This is what I would have expected in the listing after expansion:

Code: [Select]


        jnz     ..@2345.skip
        .
        .
..@2345.skip:   sub     eax,eax


This type of listing is very helpful in debugging new macros.  I tend to write a lot of macros (any code fragment used twice or more goes in a macro) and this type of listing would save me a lot of time.

Tanks and take care...... Paolo

[cm]

To be honest, I find listing files to be almost completely useless. They tell me what I already knew - namely what I just wrote. I find a disassembly much more informative. But other people find listing files very valuable, so perhaps it's just me. Maybe somebody who actually uses the things will have a better answer for you.

Listing files are sometimes useful in debugging macros - simply to assert that the correct output is generated, and if that isn't the case, then to find the line of a macro that created the wrong output (or that failed to output anything). They're useful for learning some other stuff as well, such as, what instruction form NASM generated, how long it is, etc. These are all useful even if you ain't debugging NASM. In large programs, it is usually easier to locate the instruction or macro output in the listing file than it would be to disassemble/debug the entire executable or object file. In case of instructions, you can still enter the bytes in the listing into a debugger faster than searching for the instruction. (Of course, relocations are not applied in the listing so sometimes you have to debug a program to get it right.)

Unfortunately listing is somewhat limited, in that the source code it shows is only partly preprocessed. An option to make it show the fully preprocessed source, including single- and multi-line macro expansions as well as the full name of macro-local, context-local and local labels, and omitting comments and code in conditional branches that are disabled, would be more useful for some things. Even though you can surely achieve some of this with regexes, as I was advised on a similar feature request, things like macro and label expansion and processing of preprocessor conditionals you can't achieve with them.

And just in case you think running the preprocessor on a file first, then assembling it to achieve a listing similar to what I described is an option: It isn't. The preprocessing-only mode does not currently support any preprocessor directives (mostly expressions in conditional directives and %assign) which reference $ or $$ so it is unable to process even the most basic TSRs I write. (Possible support for that could be achieved by not omitting the affected %assigns and conditional constructs - this would then require the output to be preprocessed while assembling though.)

[Frank Kotler]

Ah, I see what you're looking for, Paolo (I think). No, Nasm won't really do that. The ".nolist" option is spectacularly unhelpful! As Christian points out, a disassembly can make it hard to find what you're looking for... and Ndisasm doesn't attempt to be too bright. Here's something you might like, although it isn't as simple as just adding the "-l" switch...

http://www.agner.org/optimize/#objconv

Here's my test file:

Code: [Select]


[list -]
%macro foo 0.nolist
%push ctx
mov eax, ebx
jz %$skip
add al, 7
%$skip:
%pop

%endmacro
[list +]
global _start

section .text
_start:

foo
foo
foo

mov eax, 1
int 80h

When I first started using "objconv", I had a problem with "objconv -fnasm myfile.o" overwriting "myfile.asm" - it wouldn't accept "-o" as an output file name. A quick RTFM informed me that "objconv -fnasm myfile.o myfileAF.asm" was all I needed to do!

Code: [Select]

; Disassembly of file: t.o
; Sun Oct 10 03:38:31 2010
; Mode: 32 bits
; Syntax: YASM/NASM
; Instruction set: 80386


global _start


SECTION .text   align=16 execute                        ; section number 1, code

_start: ; Function begin
        mov     eax, ebx                                ; 0000 _ 89. D8
        jz      ..@3.skip                               ; 0002 _ 74, 02
        add     al, 7                                   ; 0004 _ 04, 07
..@3.skip:
        mov     eax, ebx                                ; 0006 _ 89. D8
        jz      ..@5.skip                               ; 0008 _ 74, 02
        add     al, 7                                   ; 000A _ 04, 07
..@5.skip:
        mov     eax, ebx                                ; 000C _ 89. D8
        jz      ..@7.skip                               ; 000E _ 74, 02
        add     al, 7                                   ; 0010 _ 04, 07
..@7.skip:
        mov     eax, 1                                  ; 0012 _ B8, 00000001
; Note: Function does not end with ret or jmp
        int     -128                                    ; 0017 _ CD, 80
; _start End of function

Not quite what you're looking for, but perhaps closer. At least distinguishes one "skip" from another. Still a disassembly, but easier to find your way around in than what Ndisasm produces, I think. I find it a useful addition to the toolbox.

Best,
Frank

[cm]

Not quite what you're looking for, but perhaps closer. At least distinguishes one "skip" from another. Still a disassembly, but easier to find your way around in than what Ndisasm produces, I think. I find it a useful addition to the toolbox.

In a similar way, you can use .MAP files (created by the linker, or by NASM's own "[map]" directive if the bin output format is used) to find instructions while disassembling or debugging executables; or use a symbolic debugger if that is available for your object and executable format and NASM supports its debugging information format. This saves a lot of time in debugging, but the farther away from a label your instruction is, the more difficult it gets to find it. (Some of my macros that create a table for a small assembler now only use %assign to define "labels" for each entry, which means these "labels" (really smacros, which give an offset from the start of the table) are not defined while debugging my program. So there's basically this 7 KiB table with one symbol at the beginning.)

[PaoloR]

Thanks to all for the input. 

I guess I will have to learn to use disassemblers.  However before doing that I will take a look at NASM source code and see if I can change the list output within a reasonable time.  As usual time is the deciding factor.

Thanks again and take care