Polink bug?

[jj2007]

I have a library module that has a buffer in the .DATA? section; the symbol is not exported, i.e. the buffer is known only to the module.

Now I discovered that the start address coincides with the start of another buffer in a different module.

This happens only with polink, both with the Masm32 version of 16.4.2011 and the latest polink of 21.3.15

Is this a known problem? Any workaround?

[hutch--]

This much, the module format without a stack frame is different to MASM.

[jj2007]

Your answer is somewhat cryptic, dear Hutch ::)

Anyway, I've found the culprit, polink is innocent, M$ linkers are half guilty because they allocate memory too generously, so the missing dword went unnoticed for quite a while :redface:

[hutch--]

This is a leftover from 2006. A no-stack frame procedure.


; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««

    .model flat, stdcall    ; 32 bit memory model
    option casemap :none    ; case sensitive
    option cstrings:on      ; enable C string escapes

  ; *************
  ; include files
  ; *************
    include \poasm\include\windows.inc
    include \poasm\include\plib.inc
    include \poasm\include\gdi32.inc
    include \poasm\include\user32.inc
    include \poasm\include\kernel32.inc
    include \poasm\include\Comctl32.inc
    include \poasm\include\comdlg32.inc
    include \poasm\include\shell32.inc
    include \poasm\include\msvcrt.inc
    include \poasm\macros\macros.asm

    EXTERNDEF [your label name] :DWORD

    .code

; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««

align 16

[your label name]:

  ; your code here

    ret [balance stack here]

; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««

    end