[fasmg] Adding member offsets in structured tables

Index > Main > [fasmg] Adding member offsets in structured tables

Author

Thread

donn

Joined: 05 Mar 2010
Posts: 321

donn 02 Jun 2021, 05:06

Super simple structured data question:

If I have some structured data in a data section, how can I get a 'member' offset? I can get offsets of struc members, but this data is different since I dont need multiple instances of the struc, just a single occurrence.

For example:

Code:

vkWin32SurfaceCreateInfoKHRRef:
namespace vkWin32SurfaceCreateInfoKHRRef
sType dd 1000009000             ;VK_STRUCTURE_TYPE_WIN32_SURFACE_CREATE_INFO_KHR
padd1 dd 0
pNext dq 0
flags dd 0
padd2 dd 0
hInstance dq 0
hWnd dq 0
end namespace

I want to replace the hInstance in this table with a real hInstance:

Code:

        mov rbx, vkWin32SurfaceCreateInfoKHRRef
        add rbx, vkWin32SurfaceCreateInfoKHRRef.hInstance     ; This line doesnt work
        mov rcx, hInstRef
        mov r10, [rcx]
        mov [rbx], r10

But running yields:

Code:

 error LNK2017: 'ADDR32' relocation to '.data' invalid without /LARGEADDRESSAWARE:NO
LINK : fatal error LNK1165: link failed because of fixup errors

I CAN access these offsets when defining other tables:

Code:

vkWinDevExtensionsRef:
namespace vkWinDevExtensionsRef
ext1 dq vkWinExt.val1                             ; This syntax is fine using dq instead of add
ext2 dq vkWinExt.val2
ext3 dq vkWinExt.val3
ext4 dq vkWinExt.val4
end namespace


vkWinExt:
namespace vkWinExt
val1 db 'VK_KHR_swapchain',0
val2 db 'VK_KHR_swapchain_mutable_format',0
val3 db 'VK_KHR_maintenance2',0
val4 db 'VK_KHR_image_format_list',0
end namespace

Note vkWinExt.val1 offsets work like this, but not when I'm adding them. For now, I'm adding the amount of bytes as a raw number as a workaround.

adding works when I use the fasmg struc keyword, but I just want the address of these tables to be static and dont want multiple instances of them:

Code:

        struc vk
                label .
                .vkInstanceRef dq 0
                .deviceCount dq 1
...

        mov rbx, [vkRef]
        add rbx, vk.vkInstanceRef         ; This works since it's a struc
        mov rcx, [rbx]

I can clarify anything if needed, think I'm just missing something syntactical when defining these structured tables, or just face the fact that I can't use add the same way as with strucs (might need to stick to lea or something).

Have good one

02 Jun 2021, 05:06

bitRAKE

Joined: 21 Jul 2003
Posts: 4060
Location: vpcmpistri

bitRAKE 02 Jun 2021, 05:25

Code:

mov rbx, vkWin32SurfaceCreateInfoKHRRef
add rbx, vkWin32SurfaceCreateInfoKHRRef.hInstance     ; This line doesnt work

...doesn't work because you're adding the base address twice, and there isn't a 64-bit immediate add instruction. It should be sufficient to do:

Code:

mov rbx, vkWin32SurfaceCreateInfoKHRRef.hInstance

...assuming there is a single instance. The labels are addresses and not offsets from the base. Other than that it looks good.

Should also note that if you do:

Code:

lea rbx,[vkWin32SurfaceCreateInfoKHRRef.hInstance]

... is shorter than moving the 64-bit address (assuming the data is within 32-bit signed range - probably a safe bet).

Edit: if you really wanted just the offset it would be:

Code:

_offset = vkWin32SurfaceCreateInfoKHRRef.hInstance - vkWin32SurfaceCreateInfoKHRRef

This is the reason struc's are typically virtualized at address zero to create the offsets and "simplify" the syntax.

_________________
¯\(°_o)/¯ “languages are not safe - uses can be” Bjarne Stroustrup

02 Jun 2021, 05:25

bitRAKE

Joined: 21 Jul 2003
Posts: 4060
Location: vpcmpistri

bitRAKE 02 Jun 2021, 16:14

Using static structures usually results in simpler code, for example setting the hInstance would be:

Code:

push [hInstRef]
pop [vkWin32SurfaceCreateInfoKHRRef.hInstance]

... since there isn't a mem-to-mem move, or move through a temp register.
(again, assuming data is within 32-bit signed range of instruction)

In 64-bit, not only is there very little syntactical change, but in the local space code doesn't require relocation. (as long as we avoid immediate 64-bit moves, MOVABS in gas/intel syntax) fasmg does the [RIP - relative] work in the background. What we loose is the the ability to do complex immediate accesses (ex. mov rax,[MyStruct+rcx*8+rdx] doesn't work in general); without first loading the base pointer into a register (cont. ex. lea rax,[MyStruct];add rax,rdx;mov rax,[rcx*8+rdx] would be required to perform the same action allowed in 32-bit).

02 Jun 2021, 16:14

DimonSoft

Joined: 03 Mar 2010
Posts: 1228
Location: Belarus

DimonSoft 03 Jun 2021, 17:04

<OffTop>Thought the question was related to FASM1 until I noticed the namespace stuff. Seems like it’s time to add clear separation at this forum Smile

</OffTop>

03 Jun 2021, 17:04

donn

Joined: 05 Mar 2010
Posts: 321

donn 04 Jun 2021, 18:49

It works! Was going to followup on this, but completely slipped my mind, sorry.

Just tried now, and getting same results using the mov instead of add, makes complete sense. Lots of other useful info in these comments also, more techniques in the arsenal is liberating.

Following along with Intel's API Without Secrets series, exploring Vulkan a bit, moving away from AMD APP Compute. Got the Swap Chain up, need to Acquire Images next I think..

Also see the title has fasmg in it now. Thought about that when typing originally, usually I mention that.

04 Jun 2021, 18:49

< Last Thread | Next Thread >

Forum Rules:

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum