winedbg: resend: analyse far calls in be_i386_is_func_call

[Eric Pouech]

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