TEXTEQU

[hfheatherfox07]

Some body on the old forum posted this in a reply to something (Forgot what) ....
But I saved it to study later .....

Code Select Expand

;yes - when you assign a string with EQU, the assembler actually makes it a TEXTEQU, which can be reassigned
;i like to use them when i make my own stack frames   :)
; _________________________________________________________________________________________________________________
_ModeControl  TEXTEQU <[EBP+36]> ;signed/unsigned mode control
_OutBufSize   TEXTEQU <[EBP+32]> ;output buffer size in bytes
_OutBufBase   TEXTEQU <[EBP+28]> ;output buffer base address
_InpValSize   TEXTEQU <[EBP+24]> ;input value size in bytes
_InpValBase   TEXTEQU <[EBP+20]> ;input value base address

;                      [EBP+16]   PROC return address
;                      [EBP+12]   saved ESI contents
;                      [EBP+8]    saved EDI contents
;                      [EBP+4]    saved EBX contents
;                      [EBP]      saved EBP contents

_SignXorMask  TEXTEQU <[EBP-4]>  ;sign XOR mask
_OutLastDword TEXTEQU <[EBP-8]>  ;address of last dword in output buffer
;
;
;
        mov     ecx,_InpValBase  ;mov ecx,[ebp+20]

I looked at it Tonight.....
And I was wondering what does negative mean ?

Code Select Expand


[ebp-04] 
[ebp-06]
[ebp-10]
[ebp-14]
[ebp-18]


And how to use this ?

Thank you  8)

[dedndave]

well - it does not have to be that way
but, generally, we use positive offsets from EBP for passed parameters and preserved register values
and we use negative offsets from EBP for local variables
there are cases where you get an advantage by doing things a little differently, but that's another subject

if you look at how the stack frame is created, you might get a better understanding

in this case, the function has 5 passed parameters that are pushed by INVOKE
those are on the stack, above the RET address that is pushed by the call

next, the registers that are to be preserved are pushed
the last of these is the EBP register, that will be used as the stack frame base pointer

at that point, the EBP register is initialized with

Code Select Expand

        mov     ebp,esp
so, all the things that were pushed previously will have a positive offset, relative to the EBP value

from there, the local variables are created by pushing them onto the stack
they will have a negative offset relative to the value that is in EBP

[hfheatherfox07]

Huh ?

[ebp-04]  = ?  [ebp-10] =?

I Looked Here http://www.webalice.it/jj2006/Masm32_Tips_Tricks_and_Traps.htm

[Ryan]

It is not negative necessarily.  It is a subtraction.

ebp contains an address to a location on the stack.  [ebp-04] offsets the pointer down by 4, while the square brackets tells it to give the value at the offset address.

[Ryan]

Try creating a small proc with a few LOCAL variables, and do some operations with them.  Once you assemble your code, you can disassemble it to see what the macro assembler does for LOCAL variables.

[qWord]

maybe he isn't familiar with the x86 memory addressing? scale, index, base, and displacement are known?

[hfheatherfox07]

I think I Got Confuse with this Statement :

Code Select Expand

;yes - when you assign a string with EQU, the assembler actually makes it a TEXTEQU, which can be reassigned
;i like to use them when i make my own stack frames   :)

So If you have something in the .asm Like :
ID_Timer    EQU    1   
Than the "assembler actually makes it a TEXTEQU"  So Only if you look at it with a disassembler will you see :
TEXTEQU <[EBP+28]>

How does it determine the # in the EBP brakets ?
I don't think I get that ?

I looked at random .exe's that I have made and I see stuff like this?????

MOV EAX,DWORD PTR SS:[EBP-10]          ; <- What Does [EBP-10] even mean ???
MOV EDX,DWORD PTR SS:[EBP-4]            ; <- What Does [EBP-4] even mean ???
MOVZX EAX,BYTE PTR DS:[EAX+EDX-1]     ; <- What Does [EAX+EDX-1]  even mean ???

I don't really do any debugger work ....Is that the only place were you would see these textequo's ?

I have not found a single tutorial on how to use a debugger to trace a crashing app....
and what is wrong that makes it crash ......

If you Google asm and debug ...al the tuts are on fishing .... you know what
That does not explain where an app crashed and why ? 

Were do you learn that?
like a simple  Helloworld.exe that crashes and a tut to explain how to trace what and why
Most of the recommended literature on MASM looks like a wiring schematic for the Manhattan project

[Ryan]

TEXTEQU performs a Find/Replace in a sense.

_OutBufBase   TEXTEQU <[EBP+28]>
The above statement tells the assembler to replace all occurrences of _OutBufBase with [EBP+28].  If the location on the stack for this variable (_OutBufBase) were to change, it would be easiest to change one statement, instead of searching the entire code for the occurrences.  I believe that is the point of the statement "can be reassigned".

The # in the EBP brackets is an offset.  A word is 2 bytes; a dword is 4 bytes.  If allocation for a dword is desired, the # would be 4 less than the previous variable on the stack.  This is the hard way to do things in my opinion.  It makes code harder to read, and MASM has very good handling of local variables built in.

[hfheatherfox07]

SO .... in MOV EAX,DWORD PTR SS:[EBP-10]    for example in a draw text.exe
The [EBP-10]  is the occurrences of the letters being drawn or hdc in the
 
LOCAL  hdc:HDC

Or it could be the

sZText  db ' Flashing Text',0

And than the assembler just chooses the letters in the bracket per order of the .asm


So Now I am Getting into   word and  dword which I don't get that well....
I know that WORD is 16-bit unsigned integer and DWORD is 32-bit unsigned integer.

[Ryan]

[EBP-10] could point to anything.  It's impossible to know what it is without more information.

mov eax, hdc
would translate to:
mov eax, dword ptr [ebp-4]
assuming hdc is the only local variable.  HDC is really a dword, so it would result in an offset of 4 bytes.

szText is not a variable on the stack, so ebp does not apply.

[dedndave]

let's start with "EQU" and "TEXTEQU"
they are somewhat similar, with 2 very important differences

numeric values assigned with EQU may not be redefined later in the source

Code Select Expand

SomeEqu  EQU 1
if you try to assign SomeEqu a different value later on, the assembler will bark a redefinition error
it is important to understand that 1, in this case, is a number - not a string
the assembler resolves it to a numeric value

you can assign a string to an EQU
if you do, it behaves more like TEXTEQU

Code Select Expand

SomeText TEXTEQU <xyzzy>
TEXTEQU finds the occurances of "SomeText" in the source and replaces it with "xyzzy" before evaluating a line of code
TEXTEQU labels may be reassigned to different values later in the source
the assembler will use the most recent definition when evaluating a line of code
notice that if you assign a value "1" in a TEXTEQU, it is treated as a replacement string - not a numeric value

now - let's hit on stack frames a bit...

the EBP register is often used as a stack frame Base Pointer
during execution of a proc, it holds a stable address, which is simply a reference point on the stack
by stable, i mean that it does not change when values are pushed on or popped off the stack
ESP does change each time you push or pop - and thus would be inconvenient to use this way

let's make a simple stack frame.....

Code Select Expand

        push    1
        push    2
        push    3
        mov     ebp,esp
        push    4
        push    5
        push    6
the EBP register is used to establish a stable address on the stack
in this case, it will always point to our 3 value

Code Select Expand

        mov     eax,[ebp]     ;EAX = 3
at the location [EBP-4], we have a 4
at the location [EBP-8], we have a 5
at the location [EBP+8], we have a 1
these references will not change if we push/pop other values onto the stack
on 32-bit processors, we generally try to keep the stack 4-aligned
so, [EBP-10] will not be seen as often as, say, [EBP-12]   :P

stack frames are used to hold temporary data
when the proc exits, the stack frame is destroyed, and anything we had on it is essentially lost

if you look at disassembled code, you might see something like this

Code Select Expand

        push    ebp
        mov     ebp,esp
        sub     esp,32
here, stack space has been reserved for 8 dwords (or maybe a 32 byte string)
they are not initialized with any particular value, however

[jj2007]

I have not found a single tutorial on how to use a debugger to trace a crashing app....
and what is wrong that makes it crash ......

That is easy. Assemble & link the mini-app below, and open the exe in Olly. Then press F7 and see what happens...

Code Select Expand

include \masm32\include\masm32rt.inc

MyTest PROTO: DWORD, :DWORD

.code
AppName db "Masm32 is great!", 0
Hello db "A message:", 0

start:
int 3
invoke MyTest, offset AppName, addr Hello
exit

MyTest proc arg1:DWORD, arg2:DWORD
LOCAL lv1, lv2, locbuf[260]:BYTE
nop
mov lv1, 123
nop
mov lv2, eax
nop
mul lv2
nop
  MsgBox 0, arg1, arg2, MB_OK
  ret
MyTest endp

end start


[hfheatherfox07]

@ jj2007
I meant a tutorial ...explaining every line in that ....and what it means
I don't know how to read debugger

[jj2007]

You don't have to "read debugger". Just press F7 and watch in the upper right corner how the contents of eax changes when you hit a mov eax, 123 etc

Just do it. Olly won't bite you, promised 8)

[Gunther]

Just do it. Olly won't bite you, promised 8)

yes, Jochen is right. Olly won't bite you.

Gunther