)]}' { "commit": "0d5b6086143d19f86cc5d01b8944a1c13f99be24", "tree": "40caedcccf29fdc726b99902eafc21e4b314ff4c", "parents": [ "1c9d18307bdf75bee7f3ec7f7d2e421a734831f1" ], "author": { "name": "David Benjamin", "email": "davidben@google.com", "time": "Wed Jan 18 18:55:39 2023 -0500" }, "committer": { "name": "Boringssl LUCI CQ", "email": "boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com", "time": "Mon Jan 23 20:21:52 2023 +0000" }, "message": "Maintain a frame pointer in aesni-gcm-x86_64.pl and add SEH unwind codes\n\nSome profiling systems cannot unwind with CFI and benefit from having a\nframe pointer. Since this code doesn\u0027t have enough register pressure to\nactually need to use rbp as a general register, this change tweaks\nthings so that a frame pointer is preserved.\n\nAs this would invalidate the SEH handler, just replace it with proper\nunwind codes, which are more profiler-friendly and supportable by our\nunwind tests. Some notes on this:\n\n- We don\u0027t currently support the automatic calling convention conversion\n with unwind codes, but this file already puts all arguments in\n registers, so I just renamed the arguments and put the last two\n arguments in RDI and RSI. Those I stashed into the parameter stack\n area because it\u0027s free storage.\n\n- It is tedious to write the same directives in both CFI and SEH. We\n really could do with an abstraction. Although since most of our\n functions need a Windows variation anyway.\n\n- I restored the original file\u0027s use of PUSH to save the registers.\n This matches what Clang likes to output anyway, and push is probably\n smaller than the corresponding move with offset. (And it reduces how\n much thinking about offsets I need to do.)\n\n- Although it\u0027s an extra instruction, I restored the original file\u0027s\n separate fixed stack allocation and alloca for the sake of clarity.\n\n- The epilog is constrained by Windows being extremely picky about\n epilogs. (Windows doesn\u0027t annotate epilogs and instead simulates\n forward.) I think other options are possible, but using LEA with an\n offset to realign the stack for the POPs both matches the examples in\n Windows and what Clang seems to like to output. The original file used\n MOV with offset, but it seems to be related to the funny SEH handler.\n\n- The offsets in SEH directives may be surprising to someone used to CFI\n directives or a SysV RBP frame pointer. All three use slightly\n different baselines:\n\n CFI\u0027s canonical frame address (CFA) is RSP just before a CALL (so\n before the saved RIP in stack order). It is 16-byte aligned by ABI.\n\n A SysV RBP frame pointer is 16 bytes after that, after a saved RIP and\n saved RBP. It is also 16-byte aligned.\n\n Windows\u0027 baseline is the top of the fixed stack allocation, so\n potentially some bytes after that (all pushreg and allocstack\n directives). This too is required to be 16-byte aligned.\n\n Windows, however, doesn\u0027t require the frame register actually contain\n the fixed stack allocation. You can specify an offset from the value\n in the register to the actual top. But all the offsets in savereg,\n etc., directives use this baseline.\n\nPerformance difference is within measurement noise.\n\nThis does not create a stack frame for internal functions so\nframe-pointer unwinding may miss a function or two, but the broad\nattribution will be correct.\n\nChange originally by Clemens Fruhwirth. Then reworked from Adam\nLangley\u0027s https://boringssl-review.googlesource.com/c/boringssl/+/55945\nby me to work on Windows and fix up some issues with the RBP setup.\n\nBug: b/33072965, 259\nChange-Id: I52302635a8ad3d9272404feac125e2a4a4a5d14c\nReviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56128\nReviewed-by: Adam Langley \u003cagl@google.com\u003e\nCommit-Queue: David Benjamin \u003cdavidben@google.com\u003e\n", "tree_diff": [ { "type": "modify", "old_id": "21dbf6964ff01e0c9d85c54dd588e6732dba2eaf", "old_mode": 33188, "old_path": "crypto/fipsmodule/modes/asm/aesni-gcm-x86_64.pl", "new_id": "e726c048f51628d1855caeac3f3a3e4283787bb6", "new_mode": 33188, "new_path": "crypto/fipsmodule/modes/asm/aesni-gcm-x86_64.pl" }, { "type": "modify", "old_id": "8d15cc6c71b28fa55c89542587bcd0fc0bbe72c0", "old_mode": 33188, "old_path": "crypto/fipsmodule/modes/gcm_test.cc", "new_id": "324d0e8c42c1e725136655220a90d5e8a578013a", "new_mode": 33188, "new_path": "crypto/fipsmodule/modes/gcm_test.cc" } ] }