On Sat, 24 Oct 2009, nathan binkert wrote:
> I don't know the code super well, but I'd think it possible to process
> arguments in order without too much trouble. Given the C calling
> convention, it would be extraordinarily odd to have a later argument
> define the semantics of an earlier one.
The problem is like this:
int syscall_blah(int a, long long b);
On x86 arg0=%ebx arg1-low=%ecx arg1-high=%edx
So on x86 regs are consecutive like you'd expect
On arm, arg0=%r0 arg1-low=%r2 arg1-high=%r3
*note r1 was skipped because 64-bit value has to be passed in
even/odd register pair!*
But, if a function is as so:
int syscall_blah2(int a, int b, long long c)
Then there is no gap, because argument c naturally fits on
an even/odd pair.
So it depends on whether you are a 32-bit architecture, whether that
architecure places restrictions on how a 64-bit value is passed in
registers, and then if there are an odd or even number of 32-bit
values passed before it.
It can get more complicated if there are multiple 64-bit values (the ARM
kernel maintainers try to stop things like this from happening but
somtimes syscalls slip through w/o them noticing).
It might be possible to come up with some elaborate way of handling this
automatically, but I don't think it's worth the trouble if a few simple
ifdefs will handle it.
>From a look at qemu, syscalls that have this problem, at least for ARM
are only:
truncate64
ftruncate64
pread
pwrite
readahead
I think m5 only supports the first two of those, and that's only within
the past few days, which is why this problem hasn't shown up before. And
it's probably a small enough problem that a few ifdefs (while ugly) can
deal with the problem.
Vince
_______________________________________________
m5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/m5-dev
