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

Ata, John (US) john.ata at baesystems.com
Fri Dec 7 00:06:15 CET 2018


On January 29,2017 a patch (9b457baf8d46329f7d7ee2aa084022bb0df88551<https://cgit.uclibc-ng.org/cgi/cgit/uclibc-ng.git/commit/?id=9b457baf8d46329f7d7ee2aa084022bb0df88551>)by mirabilos m at mirbsd.org<mailto:m at 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 at baesystems.com<mailto:john.ata at baesystems.com>
http://www.baesystems.com/csp

[cid:image001.png at 01D138BC.8E54E330][cid:image003.png at 01D138BC.8E54E330]<http://www.twitter.com/baesystemsinc>[cid:image004.png at 01D138BC.8E54E330]<http://www.youtube.com/baesystemsinc>[cid:image006.png at 01D138BC.8E54E330]<http://www.flickr.com/photos/baesystemsinc/>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclibc-ng.org/pipermail/devel/attachments/20181206/e2ae7aed/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 2889 bytes
Desc: image001.png
URL: <http://mailman.uclibc-ng.org/pipermail/devel/attachments/20181206/e2ae7aed/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 1171 bytes
Desc: image002.png
URL: <http://mailman.uclibc-ng.org/pipermail/devel/attachments/20181206/e2ae7aed/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 1393 bytes
Desc: image003.png
URL: <http://mailman.uclibc-ng.org/pipermail/devel/attachments/20181206/e2ae7aed/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.png
Type: image/png
Size: 968 bytes
Desc: image004.png
URL: <http://mailman.uclibc-ng.org/pipermail/devel/attachments/20181206/e2ae7aed/attachment-0003.png>


More information about the devel mailing list