I have been playing with making absolute jumps to a given DWORD size address and have not had much luck with the opcodes EA or FF so I made a small macro to do the same job.

Jump Absolute.


jabs MACRO address
push address
retn
ENDM

Allows coding like,


jabs [00401000h]

Its simpler than using a register and seems to work OK. I tested it on the "start:" label on a masm EXE file.

Regards,

hutch@movsd.com
Posted on 2002-05-20 22:57:05 by hutch--
jmp CS:VALUE
jmp DS:
Posted on 2002-05-21 00:27:16 by The Svin
Alex,

I tried it but it does not work.

error A2023: instruction operand must have size.

If I add DWORD PTR to it, it GP faults.

Regards,

hutch@movsd.com
Posted on 2002-05-21 00:44:49 by hutch--
absjmp macro address
local lbl
.data
lbl dd address
.code
jmp dword ptr lbl
endm

But your way is much better
Posted on 2002-05-21 02:22:06 by The Svin
Still not a completly messless method:


ALabel TYPEDEF PROTO
_ALabel TYPEDEF PTR ALabel

.CODE
jmp _ALabel PTR eax



But this generates:


00401000 FFE0 jmp eax
Posted on 2002-05-21 02:49:34 by huh

jabs [00401000h]

That wouldn't "jump" (rather, return) to address 401000h, it
would transfer control indirectly... and "jmp dword ptr [401000h]"
would be better in this case.


If I add DWORD PTR to it, it GP faults.

Not too strange, as you're (again) jumping indirectly. Ie,
"jmp dword ptr cs:401000h" does a "jmp d.[401000h]". Yay for
masm and it's indirection ambiguities.

Anyway, I'm afraid it's not possible doing "direct absolute jumps"
when outputting win32 coff, the format just doesn't support the
necessary relocations.
Posted on 2002-05-21 02:55:43 by f0dder
That wouldn't "jump" (rather, return) to address 401000h, it would transfer control indirectly... and "jmp dword ptr [401000h]" would be better in this case.


it wouldnt??, its common practice in exe-packers loader to use those push & ret combination instead of relative jmp-s, eg:

push offset entrypointVA
ret

or :)

call @f
dd 401000h
@@:
pop eax
jmp dword ptr


Anyway, I'm afraid it's not possible doing "direct absolute jumps"
when outputting win32 coff, the format just doesn't support the
necessary relocations.


when we are talking about PE EXEs, you dont have to worry about relocations (image base >= 0x400000) :)
when relocations are applied (PE DLL) its better to use relative jmp
Posted on 2002-05-21 03:13:55 by bart
hm, actually the "jabs [401000h]" *does* do what hutch intends
it to do... which is pretty weird, as mean memory dereference...
which is *NOT* being done. All the following (incorrectly) produce
the same results:



jabs 401000h
jabs [401000h]
jabs <dword ptr [401000h]>


bart, I was talking about *coff* (intermediary object format produced
by masm) relocations, not PE relocations. Since imagebase is not
known until link-time, call/jmp are EIP-relative, and coff has "delta"
type fixups... it just isn't possible to do absolute call/jmp.
Posted on 2002-05-21 03:30:07 by f0dder
Yes,

In fact it does not need the square brackets, I was still playing with the format when I posted the small macro.


mov eax, 00401000h
jmp eax

Works OK but it uses a register where the small macro does not so it is probably more useful in the way it branches to an absolute address.

BRANCH = JMP/CALL/RET(n)(f)

Regards,

hutch@movsd.com
Posted on 2002-05-21 09:32:13 by hutch--
I think it's interesting masm doesn't do "the proper thing" when
you add brackets in the jabs macro "call". Perhaps some macro
guru (read: bitRAKE) can explain why :).
Posted on 2002-05-21 10:01:40 by f0dder
Its simple, putting square brackets around a number does not produce an address for it as there is no address for it. MASM simply ignores it the same way as it allow people to decorate some of their code with brackets in other places.

It just happens that MASM has enough parsing grunt to distinguish between cases where some of the other assemblers are not that advanced.


mov eax, named_variable
is the same as,
mov eax, [named variable]

as MASM ignores the coding error of the unnecessary brackets.

Your idea of "the proper thing" is based on a personal theory of how an assembler SHOULD be but it has nothing to do with how an assembler works. If you like assemblers that work this way, fine but not all of them are restricted in this manner.

Regards,

hutch@movsd.com
Posted on 2002-05-21 10:34:18 by hutch--
I'm sorry hutch, but you are wrong. "jmp 401000h" ought to jump
to address 401000h (which can't be assembled directly when doing
coff output, but would work with eg binary output), while "jmp [401000h]"
(or "jmp dword ptr [401000h]") should jump to the address pointed
to by the dword at address 401000h. Brackets mean indirection.
You don't think that "jmp eax" and "jmp " ought to produce
the same instructions, do you now?
Posted on 2002-05-21 11:17:43 by f0dder
Posted on 2002-05-21 11:22:42 by bitRAKE
bitRAKE, don't you agree that

"jmp 401000h" would generate E9 <eip-relative 40100h>,
while
"jmp dword ptr [401000h]" would generate FF25 00104000 ?
Same thing goes for "push"...

push 401000h = 68 01004000
push dword ptr [401000h] = FF35 00104000

so, how come "jabs" generates the immediate push for all the
three cases I showed below?
Posted on 2002-05-21 12:07:37 by f0dder
f0dder, "jabs" seems like the little quibs you and Hutch-- throw at each other. :tongue: I don't feel like explaining what Hutch-- has already said. MASM doesn't map directly to the Intel instruction set, or the Intel syntax. MASM generates the expect result for those who know MASM syntax.
Posted on 2002-05-21 12:15:41 by bitRAKE
Probably just me who don't understand masm's macro argument
expansion then. I would have assumed that passing <dword ptr [401000h]>"
as argument would make



push [b]address[/b]


resolve to



push [b]dword ptr [401000h][/b]


Humm. Seems you have to add a DS: to get it working properly,
as in "push dword ptr ". How quirky.
Posted on 2002-05-21 12:21:33 by f0dder
The macro can be easily created if one can find solution to calculate
absaddress - $
Posted on 2002-05-21 12:38:09 by The Svin
That would indeed make it easy svin... but I don't think "$ - constant"
is possible, as the necessary relocation type does not exist in the coff format.
Posted on 2002-05-21 12:50:01 by f0dder
$(+-)constant is not a problem
the problem is constant-$
a have solutions only when section address is known.
Posted on 2002-05-21 13:08:16 by The Svin
Here is simple example if you know base and section alignment of your app:


.code
sectaddr equ $ ;at first occurence of .code set the constant
start:
;jmp to 810000h
db 0E9h
dd 810000h-endop ;810000h - absolute addr
endop = $+401000h-sectaddr
;401000h = base + section alignment



You can easily make macro from the above.
But it works if and only if you know for sure base and section alignment. (default masm is 400000h for base and 1000h for alignment ) and if text section is the first.
Posted on 2002-05-21 14:35:53 by The Svin