On Mon, 26 Mar 2018 13:12:44 -0700 Andre McCurdy <armccu...@gmail.com> wrote:
> That's based on your assumption that a C wrapper needs to care about > results in architecture specific registers, which I contend is not a > correct interpretation of the syscall manpage. My observation is: If this doesn't matter, why is glibc doing it? It seems really weird to mention this thing, and bother doing it, if it *never* matters. So possibly it does matter. Sometimes. When? I don't feel comfortable assuming I understand the code if it's doing something like that, I can't see when it would affect anything, and the code hasn't been removed to improve performance. I'd be a lot more comfortable disregarding the weird return values and register specifications if I could look at real-world examples of how that information is used. > Did you find any evidence to support your interpretation? e.g. Did you > find any examples of callers to the libc syscall() API which use > architecture specific assembler to examine the result of the syscall? I have seen exactly one use of syscall() in the wild at all, that being the recent addition to coreutils. The evidence for my interpretation that you *could* need to know about arch-specific behavior is the EABI example, which clearly indicates the *possibility* that code in C has to care about architectural variance in non-obvious ways. I don't know what ways those might be, and this call is so rarely used that I'm not sure it would be reasonable to generalize about it. (I also don't know whether it's still true on 64-bit ARM, and whether it also applies to pointer values or only to integer values, or...) > The gnulib code calling syscall(SYS_renameat2, ...) certainly doesn't > do that - it just checks the C function return value and errno. Since > there's no architecture specific code to examine the syscall() result, > do you expect coreutils mv to now incorrectly detect errors on ia64? No. But I don't know whether *anyone* is using syscall(), other than this one single example I've seen identified. I also don't know how widely tested the code in question is, or on what architectures. Testing on non-x86 architectures has often been sporadic in the open source community, and I think that's improved, but I don't know how much. If I'm looking at something that's almost never used, and I don't have specific information that the existing usage is being fully tested on "obscure" targets (such as mips, arm, etc), I am going to be at least a little distrustful. -s -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core