I believe that the rules are as follows (from some google searches,
but I couldn't find a definitive list):
64 bit arch/app -- Do nothing special
32 bit arch/app -- 64 bit values are aligned evenly with the exception
of x86 and ARM OABI (which we don't support and don't intend to).
Assuming that is the case, all of the other OSes should have something
like the following. If we support two endians for a given architecture
(which we don't at the moment) the stitching together will have have
to take that into account.
For some reason I feel that the getSyscallArg should be templated on
the size. Either machine bytes (actually something similar), or 64bits
(if the argument is always 64 bits).
uint64_t
ArmLiveProcess::getSyscallArg(ThreadContext *tc, int &i, int width)
{
assert(width == 32 || width == 64);
assert(i < NumArgumentRegs);
// Align index to even argument register
if (width == 64 && index % 2)
index++;
uint64_t arg = (uint64_t)tc->readIntReg(index) << 32 | tc-
>readIntReg(index+1);
index += 2;
return retVal;
}
Ali
On Oct 25, 2009, at 5:00 PM, Gabe Black wrote:
> This patch is similar to but not the same as what I described earlier.
> Instead of keeping track of a stack pointer in the background in the
> process or threadcontext where it could end up out of sync, not being
> updated properly in subclasses, getting trashed in multithreaded
> environments, etc., I put the index into the syscall functions using a
> reference argument. This had the nice (to me at least) property of not
> introducing another set of functions. All the quick regressions pass
> except memtest-ruby. I made ftruncate64 use the new capabilities of
> this
> setup, but it doesn't appear to be used by any ISA so I can't really
> test it explicitly. Also, I only put in special rules for 32 bit
> x86. It
> sounds like other ISAs have other rules which I'm not necessarily
> familiar with. It should be easy to fix them up using I386LinuxProcess
> as an example.
>
> Gabe
>
> Gabe Black wrote:
>> _______________________________________________
>> m5-dev mailing list
>> [email protected]
>> http://m5sim.org/mailman/listinfo/m5-dev
>
> _______________________________________________
> m5-dev mailing list
> [email protected]
> http://m5sim.org/mailman/listinfo/m5-dev
>
_______________________________________________
m5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/m5-dev
