Vince Weaver wrote: > On Sat, 24 Oct 2009, Gabe Black wrote: > >> The getSyscallArg function can be defined differently for different >> types of processes, typically 32 bit vs. 64 bit. Defining those >> differently might do it. It could be more complicated than that if, for >> instance, the number of register pairs is dependent on the syscall so >> the location of argument n depends on how many pairs that particular >> syscall uses before getting to n. In any case, I think the process >> object would be a good place for a fix. >> > > it depends on both of those (the syscall itself and also the exact types > of the preceeding arguments). So it makes it more troublesome. > > I'll be sending an x86 truncate64 patch soon. It shows what is needed to > get x86 working. It might need some extra fixing for the power and other > 32-bit architectures because I'm not sure if the current code is handling > endianess issues properly. > > Vince > _______________________________________________ > m5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/m5-dev >
How about instead of treating the arguments as an array we treat them as a stack? There could be functions getFirstSyscallArg and getNextSyscallArg. The first resets the stack pointer to the first argument, and both increment it appropriately depending on what they just returned. A form with no argument will use the "default" size, most likely one register, and a form with an argument can decide what special behavior is necessary based on that argument. For instance, it sounds like that argument could be the width of the operand. If it's 64, then sometimes the pointer will be incremented differently, register values combined, etc. Gabe _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
