On Tue, 27 Mar 2018 12:11:22 -0700 Andre McCurdy <armccu...@gmail.com> wrote: > In the readahead example, the first syscall argument is the > 32bit file descriptor (which will be passed to the kernel in r0), > therefore a padding argument is required to fill r1 and ensure that > the first word of the 64bit offset gets passed in r2.
Yes. > The above is completely specific to ARM 32bit EABI. I guess *similar* > issues may apply to some other 32bit architectures (as suggested in > the manpage). It's certainly not an issue with is generic to all 32bit > targets though. I was wondering about 64-bit EABI. The man page didn't say "32-bit EABI", it said "EABI". The information that you don't need to do that on at least some ARM EABI arguably makes this *worse*, rather than *better*, from the standpoint of "how do I write correct code for this". So this appears to be at least partially a documentation error, although it's quite possible that the text predates the question having come up. But it does also mean that it should be harmless to us in this case. > If syscall(), or a wrapper for it, *does* need to interpret the > arguments for a particular syscall then the syscall() implementation > would have to also agree with the interpretation of the data defined > by the kernel. Yes. My basic concern is that I don't think I have enough information to produce a Provably Correct handling for syscall arguments in the presence of at least one architecture where argument order can change for at least one syscall. ... That said, an actual *correct* wrapper for renameat2 turns out to be surprisingly hard, mostly because EXCHANGE is impossible to do with pseudo's current IPC data structure. -s -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core