openbsd/src/lib/libcrypto/perlasm, branch libressl-v3.8.0 A mirror of https://github.com/libressl/openbsd.git https://git.lua4.win/openbsd/atom?h=libressl-v3.8.0 2023-02-23T08:49:02+00:00 Fix up the .rodata segment's name for Windows as well. 2023-02-23T08:49:02+00:00 tb 2023-02-23T08:49:02+00:00 urn:sha1:9d264da3f3d1bdaa45983642efbea843e206531b 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 intel 2023-02-21T12:24:39+00:00 tb 2023-02-21T12:24:39+00:00 urn:sha1:bbd3444e2c08eee072f2585081aa72121247bc34 ok jsing Use .section .rodata instead of a plain .rodata 2023-02-09T19:57:00+00:00 tb 2023-02-09T19:57:00+00:00 urn:sha1:4355eb6aeababf0126972f85bdeed63048a99df1 At least gcc 12 on Fedora is very unhappy about a plain .rodata and throws Error: unknown pseudo-op: `.rodata'. So add a .section in front of it to make it happy. ok deraadt miod Move all data blocks from .text to .rodata and cleanup up and homogeneize code 2023-02-01T20:45:04+00:00 miod 2023-02-01T20:45:04+00:00 urn:sha1:5957c398bf683b5334ed18dd0f830b1cfffbf027 responsible from getting the proper address of those blocks. ok tb@ jsing@ Fix logic of picmeup() to only produce one set of statements on OpenBSD; this 2023-01-30T19:26:16+00:00 miod 2023-01-30T19:26:16+00:00 urn:sha1:b4af1cd6cdfa19b7d9906bf466262865305059c6 got accidentally lost in 1.4. spelling fixes; from paul tagliamonte 2022-12-26T07:18:53+00:00 jmc 2022-12-26T07:18:53+00:00 urn:sha1:2eb7e5ff6bb69760f9dd4a43e7e3520ebb930120 i removed the arithmetics -> arithmetic changes, as i felt they were not clearly correct ok tb http://repzret.org/p/repzret/ 2017-12-11T05:48:01+00:00 deraadt 2017-12-11T05:48:01+00:00 urn:sha1:06a79a412573b1755b84374f8fdb1970ca59f1b6 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 .init stub creation doesn't need a jmp + .align to reach a branch target, 2017-06-28T13:34:50+00:00 deraadt 2017-06-28T13:34:50+00:00 urn:sha1:8dee50e45d344123bec1d8e5197c42f009053fec just fall into the code. The .align created a FILL zone in the .init section, which on i386 was filled with a NOP-sled, something we want to get away from. discussed with kettenis and tom Replace all uses of magic numbers when operating on OPENSSL_ia32_P[] by 2016-11-04T17:30:30+00:00 miod 2016-11-04T17:30:30+00:00 urn:sha1:1a12fc8399638223feca8f853e2ac2cc22eeb471 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, but 2015-09-11T14:57:29+00:00 miod 2015-09-11T14:57:29+00:00 urn:sha1:1e96b158b233731c4fcc4561d29354dfa0b7799a 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.