winedbg: resend: analyse far calls in be_i386_is_func_call
Eric Pouech
eric.pouech at wanadoo.fr
Sun Apr 9 07:05:52 CDT 2006
Jeff Latimer wrote:
> Eric Pouech wrote:
>
>> - first of all, a lot of code should be factorized
>
>
> Can you give me an example of what factorised means here? I assume that
> you would like to see the common register code for mod 0, 1, 2 reduced.
> If that is the case, I thought that the variation in mod 0 rm 6 made
> combining it somewhat messy and that the code would execute faster by
> keeping sections separate. If that is not what you meant or I am wrong
> about the performance aspects, let me know.
yes
>> - segment is always expressed as an unsigned short (even in ADDRESS
>> structure), so you shouldn't convert it to an int...
> My mistake, is it better to use unsigned short or WORD when
> specifying this?
WORD
>> in this case, the callee should be kept as AddrMode1616, not in flat
>> mode.
> What happens given that there is no segment filled in the callee
> structure? Happy to fix it but I thought that as the segment is not
> filled in it would be a flat mode.
the callee must be fully filled by the function. if you're in 16bit
mode, then the segment is current cs, and the offset if current IP (not
EIP) + displacement
>
>>>
>>> + return TRUE;
>>> + } + else if (reg == 0x03) /* Indirect
>>> Far call into other segment */
>>> + {
>>> + far char * faraddr;
>>
>>
>> you shouldn't need the far here (it brings nothing)
>
>
> My reading of the m16:32 was that I needed 6 bytes bytes for the
> address, ie it was a far address. Hence the far. Are you saying that
> the indirect address is actually a near address?
yes, but you will never manipulate it directly as a far address (in
sense of 16:32 entity). You'll do the job yourself to read the 16 and
the 32 bit parts.
--
Eric Pouech
More information about the wine-devel
mailing list