Masm bug? Workaround? WTF...

[japheth]

On a side note.. i have a strange issue with one particular project. It will assemble and link perfectly with MASM. It Assembles perfectly with JWASM too, but when I try to link I get:
error LNK2005: _$$$00020@0 already defined in spatialflow.obj

symbols starting with "$$$" are created by jwasm if line number information is to be generated ( -Zd or -Zi ) and there's code outside of a procedure ( see linnum.c ). Perhaps it's necessary to make this procedure explicitely "private". Simplest workaround: put the code in a "dummy" proc.

[johnsa]

Hey,

I've tried manually searching for any code that might be outside of a PROC and cannot find it.

Is there any way to get a dump of that symbol and try to work out where in the source the issue lies? (I'd be quite happy to adjust the source if only I could find it! :)

John

[hutch--]

John,

Its easy to do in MASM manually but if you are writing modules in MASM to use with C/C++ your code should only be within the procedures, not outside the PROC definitions that are common in MASM. You pick the PROC statements by a normal manual stack frame. The non stack frame procs are a bit harder to pick but if you know what alignment padding looks like and usually but not exxclusively the RET location you can find a non stack frame proc.

The latter comment is because some folks use a JMP to exit a proc, even though it leaves the CALL/RET matching unbalanced.

[japheth]

Is there any way to get a dump of that symbol and try to work out where in the source the issue lies? (I'd be quite happy to adjust the source if only I could find it! :)

There's the MS DUMPBIN utility: dumpbin /symbols <object_module>

I looked a bit closer to this issue - Masm also creates those $$$-symbols, and the number behind the "$$$" is the same as in jwasm. That number, btw, is the "procedure #", which starts at 1 and is incremented with every new procedure.

btw, I updated the v2.09 jwasm and fixed a "minor" problem with those symbols becoming public. It's not that much probable that the error you got will disappear, but still might be worth a try.

Here's the DUMPBIN tool in action:

Code Select Expand


COFF SYMBOL TABLE
000 00000000 DEBUG  notype       Filename     | .file
    aaa4.asm
002 00000000 SECT1  notype       Static       | .text
    Section length    1, #relocs    0, #linenums    2, checksum        0
004 00000000 SECT2  notype       Static       | .data
    Section length    0, #relocs    0, #linenums    0, checksum        0
006 00000000 SECT3  notype       Static       | .drectve
    Section length    D, #relocs    0, #linenums    0, checksum        0
008 00000000 SECT1  notype ()    Static       | _$$$00001@0
    tag index 0000000A size 00000001 lines 0000008D next function 00000000
00A 00000000 SECT1  notype       BeginFunction | .bf
    line# 0008 end 00000000
00C 00000002 SECT1  notype       .bf or.ef    | .lf
00D 00000001 SECT1  notype       EndFunction  | .ef
    line# 0008
00F 00000000 SECT1  notype       External     | _start


the .bf, .lf and .ef entries are COFF line number infos ( and will only be seen if the source is assembled with -Zd or -Zi ). All _$$$ symbols found in the list should be marked as "static".

and the source was:

Code Select Expand


.686
.model flat,stdcall
option casemap :none

.code

start:
ret

end start


[johnsa]

Ok, well I had the earlier 2.09 which still caused the issue, I just downloaded the latest 2.09 pre now and tried again. The problem seems to have gone away! Assembled and Linked with both ML and JWASM. Awesome :)

[vengy]

OPTION PROC:PRIVATE

Seems MASM wants the procedure defined BEFORE it's actually used.

For example, this pseudocode generates Main1 and Main2 as "Public"

Main
Main1{}
Main2{}


Main1 PROC
...


Main2 PROC
...

However, rearranging the functions like this defines Main1 and Main2 as "Private"

Main1 PROC
...


Main2 PROC
...


Main
Main1{}
Main2{}


Thanks.

[dedndave]

it's not a matter of public or private
it's a matter of forward or reverse referencing a symbol

this behavior changes a little, so it's hard to say when the assembler will not recognize a forward symbol - lol
generally, if i call a routine, it's ok - if i invoke it, it doesn't work so well

if you want to be sure, use a PROTOtype...

Code Select Expand

        INCLUDE  \masm32\include\masm32rt.inc

MyFunc PROTO

        .CODE

main    PROC

        call    MyFunc

        inkey
        exit

main    ENDP

MyFunc  PROC

        print   chr$('Hello'),13,10
        ret

MyFunc  ENDP

        END     main