Re: [uclibc-ng-devel] use safe, even if possibly a few cycles slower, six-argument syscall implementation

On January 29,2017 a patch (9b457baf8d46329f7d7ee2aa084022bb0df88551<https://cgit.uclibc-ng.org/cgi/… mirabilos m@mirbsd.org<mailto:m@mirbsd.org> was accepted in the repository. I have a few questions on this patch. 1) The patch created a new file syscall6.S in the i386 directory. It seems functionally equivalent to the syscall.S. Both process 6 arguments plus the NR. Both use the exact same registers. Only an alignment directive has been added and the order of loading the registers is reverse. It also appears that glib does not have a special syscall6.S. Why did we go this route special casing 6 argument syscalls only? 2) The LOADARGS_6, RESTOREARGS_6 and ASMFMT_6 defines are removed from <bits/syscall.h>. It is not clear why from the patch. 3) There seems to be a deficiency in the syscall setup that is not present in glibc making it impossible to get a backtrace from a syscall. For example, If one looks at uclibs-ng's sysdeps.h in i386, one can see cfi_adjust_cfa_offset/cfi_rel_offset usage in the _PUSH_ARGS_1 and _POP_ARGS_N macros allowing backtrace information to be present on the stack. However, syscall/syscall6.S as well as bits/syscalls.h do not allow for this. In addition, it appears that glibc does have this mechanism in its syscall.S. Thoughts anyone? Thanks, ---- John Ata, CISSP Senior Principal Software Engineer Electronics Systems STOP Operating System<http://www.baesystems.com/en-us/product/stop> Software Development T 703-563-8115 | F 703-668-4359 | john.ata@baesystems.com<mailto:john.ata@baesystems.com> http://www.baesystems.com/csp [cid:image001.png@01D138BC.8E54E330][cid:image003.png@01D138BC.8E54E330]<http://www.twitter.com/baesystemsinc>[cid:image004.png@01D138BC.8E54E330]<http://www.youtube.com/baesystemsinc>[cid:image006.png@01D138BC.8E54E330]<http://www.flickr.com/photos/baesystemsinc/>