summaryrefslogtreecommitdiff
path: root/src/lib/libcrypto/perlasm/x86_64-xlate.pl (follow)
Commit message (Collapse)AuthorAgeFilesLines
* align read-only sections on masm/windows to 64 bytesbcook2024-02-271-1/+9
| | | | | | | Avoid conflicts where alignment is specified later in the underlying assembly. ok tb@
* Replace uses of endbr64 with _CET_ENDBR from cet.htb2024-02-241-0/+16
| | | | | | | | | cet.h is needed for other platforms to emit the relevant .gnu.properties sections that are necessary for them to enable IBT. It also avoids issues with older toolchains on macOS that explode on encountering endbr64. based on a diff by kettenis ok beck kettenis
* Fix up the .rodata segment's name for Windows as well.tb2023-02-231-2/+3
| | | | | | | | Here we need .rdata with some alignment goo. Fortunately, this was already present for .pdata and .xdata, so the change is easy. Also, this is a code path that doesn't affect OpenBSD at all. ok jsing miod
* perlasm: properly spell .rodata for macOS on inteltb2023-02-211-0/+3
| | | | ok jsing
* spelling fixes; from paul tagliamontejmc2022-12-261-3/+3
| | | | | | | i removed the arithmetics -> arithmetic changes, as i felt they were not clearly correct ok tb
* http://repzret.org/p/repzret/deraadt2017-12-111-1/+1
| | | | | | | | | | My read of this: Long time ago (Think Conan, not dinasaurs) during the race to make speedier processors, a cpu vendor built a pipeline with a bad stall, and proposed a tremendously hasky workaround. A wizard adopted this into his perl scroll, and failed to reflect later when no compiler adopted the practice. This relic remains at the tail end of some functions in OpenSSL as ".byte 0xf3,0xc3". Banish it straight to hell. ok mlarkin, others also stared blankly
* Replace all uses of magic numbers when operating on OPENSSL_ia32_P[] bymiod2016-11-041-1/+3
| | | | | | | | | | | | | | | meaningful constants in a private header file, so that reviewers can actually get a chance to figure out what the code is attempting to do without knowing all cpuid bits. While there, turn it from an array of two 32-bit ints into a properly aligned 64-bit int. Use of OPENSSL_ia32_P is now restricted to the assembler parts. C code will now always use OPENSSL_cpu_caps() and check for the proper bits in the whole 64-bit word it returns. i386 tests and ok jsing@
* Bring back the expansion-into-.byte-sequences routines removed in r1.9, butmiod2015-09-111-12/+67
| | | | | | | | | | | | only define them if not building for the "openbsd" flavour. This way, non-obfuscated output can still be generated for analysis, by using the "openbsd" flavour (which OpenBSD HEAD will do), and obfuscated output, compatible with older as(1), will be generated for other platforms. The portable version of LibreSSL can then use "openbsd-portable" as the flavour for OpenBSD/amd64 so that generated files can be compiled with OpenBSD 5.7 and other older versions stuck with as(1) 2.15.
* Fixup inter-bank movq/movd operations, emit bytes for pclmulqdq again.bcook2015-09-111-1/+15
| | | | | | | | | | Fixes builds gcc + Apple's assembler, working on reenabling builds with older OpenBSD releases. based on OpenSSL commit: https://git.openssl.org/?p=openssl.git;a=commitdiff;h=902b30df193afc3417a96ba72a81ed390bd50de3 ok miod@
* Remove the logic responsible for outputting most AES-NI instructions asmiod2015-07-191-61/+0
| | | | | | | | | raw byte sequences. The toolchains have had some time to update and assemble the instructions correctly (except for p{ins,ext}rd which are not supported yet by as(1) under OpenBSD, but will be fixed shortly). Inspired by a discussion between tedu@ and John-Mark Gurney. Verified to still work on Mac OS X and average Linux distros by bcook@
* A few months back there was a big community fuss regarding direct-usederaadt2014-06-021-13/+0
| | | | | | | | | | | | of the intel RDRAND instruction. Consensus was RDRAND should probably only be used as an additional source of entropy in a mixer. Guess which library bends over backwards to provide easy access to RDRAND? Yep. Guess which applications are using this support? Not even one... but still, this is being placed as a trap for someone. Send this support straight to the abyss. ok kettenis
* On amd64 OPENSSL_cpuid_setup and OPENSSL_ia32cap_P are now hidden so we don'tkettenis2012-10-311-4/+1
| | | | | | | | | | have to go through the PLT/GOT to get at them anymore. In fact going through the GOT now fails since we no longer have a GOT entry for OPENSSL_ia32cap_P. Fixes the problem spotted by jasper@ and sthen@. Based on a diff from mikeb@ who did most of the actual work of tracking down the issue. ok millert@, mikeb@
* resolve conflictsdjm2012-10-131-29/+192
|
* openssl-1.0.0e: resolve conflictsdjm2011-11-031-1/+5
|
* More OpenSSL fixes:djm2010-10-061-1/+1
| | | | | | | | | - Update local engines for the EVP API change (len u_int => size_t) - Use hw_cryptodev.c instead of eng_cryptodev.c - Make x86_64-xlate.pl always write to the output file and not stdout, fixing "make -j" builds (spotted by naddy@) ok naddy@
* resolve conflicts, fix local changesdjm2010-10-011-133/+492
|
* fix some cause of bad TEXTREL on i386 and amd64otto2008-09-191-1/+4
| | | | | | | - global function calls in .init sections (diff makes them via PLT) - calls to global functions in aes-586.S (made static or local) - global variable accesses in rc4-x86_64.S (now made via GOT) from djm@large; ok miod@
* import of OpenSSL 0.9.8hdjm2008-09-061-0/+554
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2025-03-21 14:13:23 +0000