I just committed a fix which should take care of both of these problems. 
I think I ran into this once before when working with o3 as evidenced by 
the fix there, but I was trying to get things working for a deadline and 
apparently neglected to fix the other CPUs too. Please let me know if 
you still have this problem with the fix.

Gabe

Ali Saidi wrote:
> I noticed that happening in the syscall stubs as well. Could you open  
> up a bug report on the website so thath we'll make sure and get this  
> handled at some point?
>
> Thanks,
>
> Ali
>
> On Dec 16, 2008, at 6:09 PM, Jack Whitham wrote:
>
>   
>> On Tue, Dec 16, 2008 at 04:51:55PM -0500, [email protected] wrote:
>>     
>>> Thank you for pointing this out. I can't look at this in detail at  
>>> the moment,
>>> but what probably should be changed is the part of getSyscallArg  
>>> that the ISA
>>> provides. It should probably truncate the register values as  
>>> they're retrieved
>>> for the system call emulation function if it's from a 32 bit  
>>> application. I'll
>>> try to look at this more closely soon to give you a more definitive  
>>> answer and
>>> hopefully a patch.
>>>       
>> Thanks very much for your response. This fix sounds like the right  
>> thing.
>> I'm in no hurry for an official fix, because I have written a  
>> temporary
>> hack to fix it, but it will break 64 bit SPARC applications so it's no
>> use to you.
>>
>> However, when you do have time to look at this problem, I think I may
>> have found a related issue. Values *returned* by system calls should  
>> *also*
>> be truncated for 32 bit applications, when M5 has been compiled for  
>> x86_64.
>>
>> Here, for example, are two instructions that are run immediately after
>> the lseek system call completes. This is a diff of two traces from the
>> same program, one produced on a 64 bit machine (<) and the other
>> produced on a 32 bit machine (>). The system call has left some data  
>> in
>> the top 32 bits (in %o0).
>>
>> 60842,60843c60842,60843
>> < 30466500: system.cpu T0 : @__libc_lseek+40 :  mov   %o0, %i0
>> : IntAlu :  D=0x00c4c5bc00bcc5c4
>> < 30467000: system.cpu T0 : @__libc_lseek+48 :  add   %i0, 0xff, %g1
>> : IntAlu :  D=0x00c4c5bc00bcc6c3
>> ---
>>     
>>> 30466500: system.cpu T0 : @__libc_lseek+40 :  mov   %o0, %i0
>>> : IntAlu :  D=0x0000000000bcc5c4
>>> 30467000: system.cpu T0 : @__libc_lseek+48 :  add   %i0, 0xff, %g1
>>> : IntAlu :  D=0x0000000000bcc6c3
>>>       
>>
>> -- 
>> Jack Whitham
>> [email protected]
>>
>> _______________________________________________
>> m5-users mailing list
>> [email protected]
>> http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
>>
>>     
>
> _______________________________________________
> m5-users mailing list
> [email protected]
> http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
>   

_______________________________________________
m5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/m5-users

Reply via email to