| commit | b6bca9c6dde177f641137d2991aa677997c54c67 | [log] [tgz] |
|---|---|---|
| author | David Benjamin <davidben@google.com> | Thu Apr 04 00:50:59 2024 -0400 |
| committer | Boringssl LUCI CQ <boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com> | Sat May 11 08:10:43 2024 +0000 |
| tree | e75c4536ab7a13bc55430d677710c0961ee12d6c | |
| parent | 03d1b7c544851d9f44df1e9ff21839742e08c819 [diff] |
Align perlasm SEH directives with gas/clang-assembler perlasm broadly uses gas syntax. gas and clang-assembler already have SEH directives. From what I can tell, no one ever properly documented this, but this mail describes this. LLVM's test data also has examples. https://sourceware.org/legacy-ml/binutils/2009-08/msg00193.html First, we named ours based on the MASM directives and prepended ".seh_". gas says "endprologue" instead of "endprolog", "savexmm" instead of "savexmm128", and "stackalloc" instead of "allocstack". Since perlasm mostly looks like gas, I've switched to the gas spellings. Second, we made .seh_endprologue implicit because it's always immediately after the last directive. Both MASM and clang-assembler make it explicit. Synthesizing an .seh_endprologue for those syntaxes would require buffering the up the whole function, so just require it be explicit in the source. The last difference is that gas says ".seh_proc name_of_function". I've not aligned on that one because MASM actually integrates it into the PROC line. You add the FRAME keyword or not depending on whether it's a frame function. To make the MASM output easier, I think we need to diverge from both gas and what we've currently done. I'll resolve that in a follow-up change. Along the way, fix a couple of instances where the _CET_ENDBR got put on the wrong side of the SEH directive. I don't think that macro works on Windows anyway, so it's moot. But if it did emit anything, it should be included in the prologue. Bug: 571 Change-Id: I39701a952a654afe6bfc8b3b908ca8fe65d6f1a1 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/68292 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Bob Beck <bbe@google.com>
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.
Project links:
There are other files in this directory which might be helpful: