UASM icon indicating copy to clipboard operation
UASM copied to clipboard

[Feature] add consistent access to struct members also on local vars

Open LowLevelMahn opened this issue 1 year ago • 2 comments

tested with UASM 2.57

struct member addressing on global vars is different to local proc vars - with globals i can left out the struct on accessing is there a reason for not allowing this address schema also on local variables?

the example is only assemble-able it does not produce an working program

my_struct struc
  one dw ?
  two dw ?
my_struct ends

.MODEL small
.STACK 100h
.DATA
  global_var my_struct<0>	

.CODE

local_var_test proc near
  local_var = my_struct ptr 4

  mov ax,[bp+local_var+my_struct.two] ; OK
  ;mov ax,[bp+local_var.two] ; ERROR: Error A2274: structure field expected <=======

local_var_test endp

start:
  mov ax,[global_var+my_struct.two] ; OK
  mov ax,[global_var.two] ; OK with global <=======
  
end start

i found that while reversing a DOS game using IDA Pro the assembler output of IDA is nearly out of the box re-assemble-able with UASM (much better compared to MASM or WASM) but this struct var access schema difference makes it a little harder to work out of the box

LowLevelMahn avatar Oct 20 '24 12:10 LowLevelMahn

try: mov ax, word ptr local_var.two or mov ax, local_var.two or if you need bp to reference then: mov ax, word ptr [bp].local_var.two

mrfearless avatar Oct 20 '24 12:10 mrfearless

@mrfearless

mov ax, word ptr local_var.two
mov ax, local_var.two
mov ax, word ptr [bp].local_var.two

all fail with the same: Error A2274: structure field expected

IDA Pro (still gold standard in reversing tools) produces this form mov ax,[(e)bp+local_var.two] (for 16/32 bit code) and UASM support it this way on globals so i (just) hoped that can be fixed because i can't see any reason for not supporting that access schema also for locals

so allowing that with UASM would make UASM another step better then MASM/WASM for re-assembling IDA output (its already nearly the best for IDA reassembling)

LowLevelMahn avatar Oct 20 '24 12:10 LowLevelMahn

had an dicussion on https://masm32.com/board/index.php?topic=12351.msg134318#msg134318 with a good explanation from _japheth why having that feature could break compatibility

LowLevelMahn avatar Nov 02 '24 08:11 LowLevelMahn

its kept for MASM compatiblity, can break existing code vastly - wontfix :)

LowLevelMahn avatar Feb 26 '25 09:02 LowLevelMahn