It probably has something to do with x64 structure alignment.
ONE STRUCT
a DQ
b DD
ENDS
TWO STRUCT
c ONE <>
ENDS
CODE SECTION
Start:
invoke msvcrt:printf, "%d %d", ONE.b, TWO.c.b
ret
8 12
The second offset will be correct ( 8 ) if you change b's type to DQ or put one more structure member after it.
Nice find. Definite signs of a bug nesting in a structure, but I haven't managed to catch it yet (while also trying to maintain momentum with progress on a remaining challenging complexity with a GoLink update)...
Yes, this was an issue with x64 padding for the last member of a nested structure. Now fixed in GoASM v0.58.0.4.
However, while looking into this I found another one that occurs if padding is needed for the first member, but this is less likely and easier to work around. Using the above, for example:
DATA SECTION
First DD 0
Second TWO <>
TWO gets QWORD aligned, but the address for Second will be in error, being before the padding. The more specific labels Second.c or Second.c.a are correct taking into account the padding. Manually place an ALIGN 8 before Second would correct that address.
The fix for this one is in a different area of coding that is more complex, so this will take a bit longer...