|author||David Benjamin <email@example.com>||Wed Jan 18 18:55:39 2023 -0500|
|committer||Boringssl LUCI CQ <firstname.lastname@example.org>||Mon Jan 23 20:21:52 2023 +0000|
Maintain a frame pointer in aesni-gcm-x86_64.pl and add SEH unwind codes Some profiling systems cannot unwind with CFI and benefit from having a frame pointer. Since this code doesn't have enough register pressure to actually need to use rbp as a general register, this change tweaks things so that a frame pointer is preserved. As this would invalidate the SEH handler, just replace it with proper unwind codes, which are more profiler-friendly and supportable by our unwind tests. Some notes on this: - We don't currently support the automatic calling convention conversion with unwind codes, but this file already puts all arguments in registers, so I just renamed the arguments and put the last two arguments in RDI and RSI. Those I stashed into the parameter stack area because it's free storage. - It is tedious to write the same directives in both CFI and SEH. We really could do with an abstraction. Although since most of our functions need a Windows variation anyway. - I restored the original file's use of PUSH to save the registers. This matches what Clang likes to output anyway, and push is probably smaller than the corresponding move with offset. (And it reduces how much thinking about offsets I need to do.) - Although it's an extra instruction, I restored the original file's separate fixed stack allocation and alloca for the sake of clarity. - The epilog is constrained by Windows being extremely picky about epilogs. (Windows doesn't annotate epilogs and instead simulates forward.) I think other options are possible, but using LEA with an offset to realign the stack for the POPs both matches the examples in Windows and what Clang seems to like to output. The original file used MOV with offset, but it seems to be related to the funny SEH handler. - The offsets in SEH directives may be surprising to someone used to CFI directives or a SysV RBP frame pointer. All three use slightly different baselines: CFI's canonical frame address (CFA) is RSP just before a CALL (so before the saved RIP in stack order). It is 16-byte aligned by ABI. A SysV RBP frame pointer is 16 bytes after that, after a saved RIP and saved RBP. It is also 16-byte aligned. Windows' baseline is the top of the fixed stack allocation, so potentially some bytes after that (all pushreg and allocstack directives). This too is required to be 16-byte aligned. Windows, however, doesn't require the frame register actually contain the fixed stack allocation. You can specify an offset from the value in the register to the actual top. But all the offsets in savereg, etc., directives use this baseline. Performance difference is within measurement noise. This does not create a stack frame for internal functions so frame-pointer unwinding may miss a function or two, but the broad attribution will be correct. Change originally by Clemens Fruhwirth. Then reworked from Adam Langley's https://boringssl-review.googlesource.com/c/boringssl/+/55945 by me to work on Windows and fix up some issues with the RBP setup. Bug: b/33072965, 259 Change-Id: I52302635a8ad3d9272404feac125e2a4a4a5d14c Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56128 Reviewed-by: Adam Langley <email@example.com> Commit-Queue: David Benjamin <firstname.lastname@example.org>
BoringSSL is a fork of OpenSSL that is designed to meet Google's needs.
Although BoringSSL is an open source project, it is not intended for general use, as OpenSSL is. We don't recommend that third parties depend upon it. Doing so is likely to be frustrating because there are no guarantees of API or ABI stability.
Programs ship their own copies of BoringSSL when they use it and we update everything as needed when deciding to make API changes. This allows us to mostly avoid compromises in the name of compatibility. It works for us, but it may not work for you.
BoringSSL arose because Google used OpenSSL for many years in various ways and, over time, built up a large number of patches that were maintained while tracking upstream OpenSSL. As Google's product portfolio became more complex, more copies of OpenSSL sprung up and the effort involved in maintaining all these patches in multiple places was growing steadily.
Currently BoringSSL is the SSL library in Chrome/Chromium, Android (but it's not part of the NDK) and a number of other apps/programs.
There are other files in this directory which might be helpful: