Hi Ciro. There are some folks from AMD I think who have been doing quite a lot with syscall emulation and should probably chime in too, but here is my understanding.
If you're accepting an address, you should use the Addr type. This is sometimes treated specially, and even though it's a 64 bit value should be filled from, for example, a 32 bit register where the native pointer is that size. I have an idea for something slightly more automatic than that which I've sent to my team internally and which I'll probably send externally shortly (I just realized I hadn't :-) ). Don't worry about that for now, just using an Addr and constructing a BufferArg manually is fine. If you're accepting a type of a fixed size, then use a uintXX_t or an intXX_t which will be the same size no matter who's frame of reference you're talking about. If you're using something that varies from system to system like I think a size_t or a structure with variable field placement and types, you can either wing it and hope it's consistent (less headache, more possibility for bugs, probably not great but it's in the codebase now I think), or you can implement your syscall as a template, define your types, structures, constants, etc., in the OS class, and then use that as the template parameter and get all your actual types from that. Gabe On Fri, Apr 17, 2020 at 1:39 PM Ciro Santilli <ciro.santi...@arm.com> wrote: > I want to implement the simple getcpu syscall. > > According to man getcpu and kernel source in kernel/sys.c, that function > as an argument an unsigned *cpu to which it writes the value. > > I was looking through the other syscall implementations in syscall_emul.hh > but all I've seen so far appear to assume host and guest sizes match and > simply do a sizeof() to determine the size of their BufferArg. > > Is this supported by your Guest ABI patches Gabe, and if so is there an > example usage somewhere in the code? > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. > _______________________________________________ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
