[Nasm-bugs] [Bug 3392543] New: Pain with %arg names in macro expansions

[noreply-nasm at gorcunov.org]

https://bugzilla.nasm.us/show_bug.cgi?id=3392543

            Bug ID: 3392543
           Summary: Pain with %arg names in macro expansions
           Product: NASM
           Version: 2.14.xx
          Hardware: All
                OS: All
            Status: OPEN
          Severity: normal
          Priority: Medium
         Component: Assembler
          Assignee: nobody at nasm.us
          Reporter: james.harris.1 at gmail.com
                CC: chang.seok.bae at intel.com, gorcunov at gmail.com,
                    hpa at zytor.com, nasm-bugs at nasm.us
     Obtained from: Binary from nasm.us

It seems that macro parameter names which are used in %arg statements persist
between macro invocations rather than remaining local to a macro (or even to a
context). Details follow. 

The issue appeared when defining proc and endproc macros to aid creation of
procedure headers and trailers. Omitting all other details the proc header
invocations might look like this:

proc fprintf, stream, first_arg
proc char_print, stream, ch
proc integer_print, stream, num

The problem comes in where a parameter name (in this case "stream") is used in
more than one macro invocation in a source file. Nasm complains about
subsequent uses with a message such as 

t6.nasm:27: error: (proc:8) `%arg' missing argument parameter

The code works perfectly as long as names differ. The above can be got round by
making sure all parameter names are unique

proc fprintf, stream, first_arg
proc char_print, stream1, ch
proc integer_print, stream2, num

But that seems unnecessary, and it took a few hours of programmer time to
realise what was going on. 

I'm not sure I have this all correct but from tests it /appears/ that 'stream'
becomes (ebp+8) in the first macro invocation, as it should, but then that
stream is still (ebp+8) when the second macro begins. So that instead of seeing

  %arg stream

the assembler sees

  %arg (ebp+8)

which is obviously wrong. 

I have tried wrapping invocations in %push/%pop but it makes no difference. 

I am aware that I haven't shown an example of the code, yet. This post is
already too long so I'll follow up separately with two things: the full macros
in which the problem was seen and a simplified test case which hopefully makes
the problem easier to repeat.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are watching all bug changes.