On Sat, 24 Mar 2018 11:59:27 -0700 Andre McCurdy <armccu...@gmail.com> wrote:
> The EABI example applies to 64bit values on 32bit architectures. Since > pointers are 32bit values on 32bit architectures the example doesn't > apply to renameat2 (which only passes int's and pointers - nothing > which would be a 64bit value on a 32bit architecture). ie there is > never any "oldpathhi, oldpathlo", only "oldpath", etc. I didn't see a qualifier about it being only on a 32-bit architecture, it just says "EABI". But in general, this is the reason that musl's ability to work doesn't buy us guarantees; musl doesn't have to *interpret* the arguments. So for instance, they could just pass "the same arguments" for SYS_readahead, we couldn't. (If we needed it, which I don't think we do.) Similarly, they don't have to do Fancy Complicated Fixups around their system calls which can break weird register conventions. Consider: > > On a few architectures, a register is used to indicate > > simple boolean failure of the system call: ia64 > > uses r10 for this purpose, and mips uses a3. I have no evidence that these registers are being reliably saved through all the *other* code pseudo has in and around wrapper functions. By the time we get into wrap_foo(), we've already done a ton of other things, including made system calls, and we make *more* system calls on the way back out. So to handle that reliably, we'd need an extra special fancy wrapper function which bypasses everything for all the non-renameat2 cases, and even then, what would we do for renameat2? I can't write C code which stashes r10-on-ia64-or-a3-on-mips on its way out of the wrapper, then restores them after everything else is done. I can try writing the code, and it might well work, but I want to make it clear that this is a case where there's no guarantees at *all* that any code that can be written in remotely-sane C without assembly can actually do the thing correctly. The musl code is not trying to deal with a case where there's multiple other syscalls after the real syscall has been called, but before returning. This is not "we definitely can't", this is warning that there's reason to think it may not work, or may require a great deal more magic than anything else does. > If there _were_ some architecture dependent ordering of the renameat2 > arguments passed into the syscall() ABI then it would have to be > reflected in the code which originally calls syscall(), e.g. the code > in gnulib. Yeah. But about all my crystal ball will tell me about possible future changes or syscalls or ABI choices is that there might be some. -s -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core