call instruction
JohnSmith
Hi,
I have dynamically allocated areas for some manually compiled asm
routines. In some cases calling from Area1 to Area2 the EIP is
computed wrong way. Maybe because call is working with CS?
Im using call near (opcode: E8 cd), and the rel32 part is computed
manually. So it working in many case. Is there segment override prefix
for call or how to resolve this problem?
Rod Pemberton
"JohnSmith" <csne...@MUNGED.microcosmotalk.com> wrote in message
news:4b2645e8$0$5115$9a6e...@unlimited.newshosting.com...
>
> I have dynamically allocated areas for some manually compiled asm
> routines. In some cases calling from Area1 to Area2 the EIP is
> computed wrong way.
Wrong in what way? "Off into the weeds"? GPF? etc?
Do you display the two addresses "Area1" and "Area2" and the computed rel32
value to see if they match your expected values?
How do you obtain the addresses for "Area1" and "Area2"? E.g., you're
providing them? from Windows/Linux OS call? from a C compiler's malloc()?
Is this for 32-bit code? Is this for a flat un-segmented address space, is
it for a segmented address space, or is it with paging enabled?
> Maybe because call is working with CS?
Maybe. If it's a 32-bit flat address space, you also have to take into
account the base address of the segment which is stored in the descriptor
for the selector (CS in this case). I.e., the base address for "Area1" or
"Area2" might be something other than zero. E.g., "Area2" may use a
different selector in DS than "Area1" and it may have a different base
address. If so, you'll have to add/subtract the base addresses depending
their values. If paging is involved, someone else will need to tell you how
to compute the differences from the paging tables or whatever...
> Im using call near (opcode: E8 cd), and the rel32 part is computed
> manually.
Self-modifying code...
> So it working in many case.
And, it isn't working in some cases. Wouldn't this imply something is wrong
with the calculation of rel32, or the storing or rel32 in the self-modifying
code?
> Is there segment override prefix
> for call or how to resolve this problem?
You could try a DS (3E) segment override. But, at this point, I have no
idea what your problem is. So, it might not help.
Rod Pemberton
BGB / cr88192
"JohnSmith" <csne...@MUNGED.microcosmotalk.com> wrote in message
news:4b2645e8$0$5115$9a6e...@unlimited.newshosting.com...
>
just to verify, you are calculating rel32 from after the instruction,
right?...
this would mean something like:
*(int *)src=dest-(src+4);
rather than simply:
*(int *)src=dest-src;
where dest and src here are byte pointers...
JohnSmith
On Dec 15, 7:09 am, "BGB / cr88192"
<cr88...@MUNGED.microcosmotalk.com> wrote:
> "JohnSmith" <csnew...@MUNGED.microcosmotalk.com> wrote in message
I changed it to 'call [reg]'. I cannot figure what was the problem. I
have a very simple calculation of 'rel32' that was worked in many
case. This is a manually compiled routine on a dynamically allocated
area in a delphi program. In documentation I have found that 'call
near' is relativ to CS, however my program is not in the CS. (It is on
SS probably)
Tim Roberts
JohnSmith <csne...@MUNGED.microcosmotalk.com> wrote:
>
>I changed it to 'call [reg]'. I cannot figure what was the problem. I
>have a very simple calculation of 'rel32' that was worked in many
>case. This is a manually compiled routine on a dynamically allocated
>area in a delphi program. In documentation I have found that 'call
>near' is relativ to CS, however my program is not in the CS. (It is on
>SS probably)
Well, if CS and SS are not the same, you have to compensate for that. EIP
is ALWAYS referenced through CS.
However, if this is a 32-bit Delphi program, then CS and SS will be the
same (well, they both point to 0).
--
Tim Roberts, ti...@probo.com
Providenza & Boekelheide, Inc.
robert...@munged.microcosmotalk.com
On Dec 15, 10:54 pm, Tim Roberts <t...@MUNGED.microcosmotalk.com>
wrote:
> JohnSmith <csnew...@MUNGED.microcosmotalk.com> wrote:
>
> >I changed it to 'call [reg]'. I cannot figure what was the problem. I
> >have a very simple calculation of 'rel32' that was worked in many
> >case. This is a manually compiled routine on a dynamically allocated
> >area in a delphi program. In documentation I have found that 'call
> >near' is relativ to CS, however my program is not in the CS. (It is on
> >SS probably)
>
> Well, if CS and SS are not the same, you have to compensate for that. EIP
> is ALWAYS referenced through CS.
>
> However, if this is a 32-bit Delphi program, then CS and SS will be the
> same (well, they both point to 0).
Just to clarify: The values (selectors) in CS and SS *must* be
different, or you'll either be unable to write to the stack or execute
code (or perhaps both), which will likely reduce the utility of the
system. The two selectors will, however, in flat model, alias the
same addresses (both will map the entire linear address space,
starting at zero).
BGB / cr88192
"JohnSmith" <csne...@MUNGED.microcosmotalk.com> wrote in message
news:4b276c5c$0$5107$9a6e...@unlimited.newshosting.com...
On Dec 15, 7:09 am, "BGB / cr88192"
<cr88...@MUNGED.microcosmotalk.com> wrote:
> "JohnSmith" <csnew...@MUNGED.microcosmotalk.com> wrote in message
>
> news:4b2645e8$0$5115$9a6e...@unlimited.newshosting.com...
>
>
>
> > Hi,
>
> > I have dynamically allocated areas for some manually compiled asm
> > routines. In some cases calling from Area1 to Area2 the EIP is
> > computed wrong way. Maybe because call is working with CS?
> > Im using call near (opcode: E8 cd), and the rel32 part is computed
> > manually. So it working in many case. Is there segment override prefix
> > for call or how to resolve this problem?
>
> just to verify, you are calculating rel32 from after the instruction,
> right?...
>
> this would mean something like:
> *(int *)src=dest-(src+4);
>
> rather than simply:
> *(int *)src=dest-src;
>
> where dest and src here are byte pointers...
<--
I changed it to 'call [reg]'. I cannot figure what was the problem. I
have a very simple calculation of 'rel32' that was worked in many
case. This is a manually compiled routine on a dynamically allocated
area in a delphi program. In documentation I have found that 'call
near' is relativ to CS, however my program is not in the CS. (It is on
SS probably)
-->
call near is also relative to the EIP of the next instruction, FWIW.
but, then again, it is always possible there was a mess-up elsewhere...
it is much the same as with short jumps, where a short jump uses a single
byte for the address.
this is not because it jumps only to an 8 bit address, rather, that it jumps
+-127 bytes from the next instruction...
usually, CS and SS have the same base address in modern systems, as a grace
of the flat memory model, so this much should not be an issue (unless it is
DOS, or some oddball OS, anyways, but for something like Windows or Linux,
it is almost gueranteed...).
JohnSmith
On Dec 16, 6:39 pm, "BGB / cr88192"
I checked in 'Windows XP/Borland C++ Builder 6'. CS is different.
However DS, ES, SS are the same.
BGB / cr88192
"JohnSmith" <csne...@MUNGED.microcosmotalk.com> wrote in message
news:4b2a7c3b$0$4948$9a6e...@unlimited.newshosting.com...
<--
I checked in 'Windows XP/Borland C++ Builder 6'. CS is different.
However DS, ES, SS are the same.
-->
the sgement register is different, but the base addess is the same (in
nearly all cases, the base address is 0, where page tables are used for
implementing the different address spaces).
technically, CS refers to an code segment descriptor, usually in the GDT
(LDT is possible).
DS, ES, and SS, refer to a different descriptor, which contains info
relevant to a data segment.
FS or GS (FS for Win32, GS for Win64) are different, in that they reference
something normally known as a TEB or TIB. this holds info about the current
thread, values for TLS, ...
so, you can't execute code "in" DS, but you can jump to the same address as
in DS, and expect to get something sane there.
IOW: linear address in CS == linear address in DS/ES/SS, but CS !=
DS/ES/SS...