Bug in SIZEOF in x64

[Yuri]

In this code the size of the EXAMPLE type is correctly reported as 24 bytes, keeping in mind how GoAsm aligns structures.

Code Select Expand


EXAMPLE STRUCT
    a DD
    b DQ
    c DD
ENDS


DATA SECTION

;ex EXAMPLE <sizeof EXAMPLE, 0, 0>


CODE SECTION

Start:
    invoke msvcrt:printf, "%d", sizeof EXAMPLE
    ret

But if I uncomment the definition of ex, the reported size becomes 16 bytes.

Although "sizeof ex" works correctly, the first member of it still contains 16.

Code Select Expand


EXAMPLE STRUCT
    a DD
    b DQ
    c DD
ENDS


DATA SECTION

ex EXAMPLE <sizeof EXAMPLE, 0, 0>


CODE SECTION

Start:
    invoke msvcrt:printf, "%d %d %d", sizeof EXAMPLE, sizeof ex, [ex.a]
    ret


Code Select Expand


16 24 16

Actually I encountered this bug when using the OPENFILENAME structure. Because of the wrong structure size written to the first member (144 instead of 152), it didn't work in x64.

[wjr]

This one will take a bit more time for me to track down, so the fix probably won't make it into the upcoming GoAsm Version 0.57.

[wjr]

Sneaky little bug, but finally a fix forwarded to Jeremy for inclusion in GoAsm version 0.57.0.3.

[Yuri]

Thanks, Wayne, for this and the JMP fixes. :U

[jorgon]

Hi Yuri

Yes, it's true.  Wayne tracked down the bug fixed it and sent the source back to me!

So GoAsm 0.57.0.3 is available from here.

Thanks Wayne!

[donkey]

Thanks Wayne and Jeremy,

Awesome work.

[Yuri]

I seem to have found one more bug in SIZEOF. The sizes of the structure members are reported correctly in x86, but in x64 they are both 0.

Code Select Expand


EXAMPLE STRUCT
    a DB 10 DUP
    b DD
ENDS

CODE SECTION

Start:
    invoke msvcrt:printf, "%d %d", sizeof EXAMPLE.a, sizeof EXAMPLE.b
    #if ! x64
        add esp,0Ch
    #endif
    ret


x86

Code Select Expand


10 4


x64

Code Select Expand


0 0


[wjr]

Soon... this has taken a bit more time to track down and fix, partly because, with the example that I ended up using to test things out, I found three more similar x86/64 bugs involving the use of unions.

Also, padding complicates things. For labels, GoAsm SIZEOF finds the distance from the given label to the next data label. For global or LOCAL data structure definitions, a member's size will still include this padding. However, I believe that I have managed to introduce a useful variation to SIZEOF which in the case of a structure member using the structure name itself (as in your EXAMPLE.a), SIZEOF will return the size without the padding (10 instead of 12 for x64 in your EXAMPLE.a).

[Yuri]

Thanks, Wayne!