WireGuard implementation for the OpenBSD kernel https://git.zx2c4.com/wireguard-openbsd/atom/gnu/usr.bin/binutils/ld/genscripts.sh?h=jd%2Fhistogram 2008-06-13T23:33:32Z 2008-06-13T23:33:32Z kurt kurt@openbsd.org 2008-06-13T23:33:32Z urn:sha1:1c90c84b1a7086d22205ee4f0b5d486f81367317 ldscripts). Correct the xd and xdc ldscripts (pie and pie + combreloc) on i386 and add two new variants for pie + combreloc + Z and pie + Z on all arches. ok drahn@ 2004-11-02T20:44:57Z miod miod@openbsd.org 2004-11-02T20:44:57Z urn:sha1:007c2a4539b8b8aaa95c5e73e77620090abe113b - extra $(SHELL) and sugar for make (so that files not mode +x still work) - safer temp file handling - our W^X binary layout changes in ld - OpenBSD policy for library file selection in ld - arm and m88k changes which were not merged in time for official 2.15 - bfd core file handling - a couple typos New for 2.15: - ld(1) and as(1) manpages now generated at build time - binutils/stabs.c reverted to use our in-tree libiberty for now - we still use our VIA C3 crypto code over stock binutils, as it recognizes more instructions - new emulations for OpenBSD on mips64 machines, to help OpenBSD/sgi - relaxed %f# handling in gas on OpenBSD/sparc64 (same as was in 2.14) Tested on all platforms by various people; special thanks to sturm@ and otto@. 2004-05-30T22:05:40Z drahn drahn@openbsd.org 2004-05-30T22:05:40Z urn:sha1:59a393de3ada9e050d4162a25e04ad95c2b2dc27 of sections were moved for protections purposes. This causes problems with emacs undump. Only move the sections if the W^X padding is active. Generate the scripts properly for newer binutils, on i386 if -Z is active, move the executable start address back to the classic base address. 2004-05-17T21:54:18Z drahn drahn@openbsd.org 2004-05-17T21:54:18Z urn:sha1:c074d1c999f3e07019cd5e9a2f190b057ef3b935 remove testsuites (not useable) remove mmalloc (not part of new binutils). 2003-01-17T20:50:13Z drahn drahn@openbsd.org 2003-01-17T20:50:13Z urn:sha1:58cb065838343f5d972d625775790ebb89f56d88 executable regions which are writable. If a section of an executable is writable and executable, it is much easier for errant code to modify the executable's behavior. Two current areas in shared library environments which have this critical problem are the GOT (Global Offset Table) and PLT (Procedure Linkage Table). The PLT is required to be executable and both GOT and PLT are writable on most architectures. On most ELF architecture machines this would cause shared libraries to have data and BSS marked as executable. Padding to the linker script for programs and shared libraries/objects to isolate the GOT and PLT into their own load sections in the executables. This allows only the text(readonly) region and the PLT region to be marked executable with the normal data and BSS not marked as executable. The PLT region is still marked executable on most architectures because the PLT lives in the "data" or "BSS" regions and the dynamic loader will need to modify it. Since the GOT and PLT should only ever be written by the dynamic linker, it will be modified to mprotect those regions so that they are not writable during normal execution. If the dynamic linker needs to modify the regions later, (eg for lazy binding), it will mprotect the region, make the necessary changes, and mprotect it back. Since it is possible to receive a signal which would interrupt the program flow and perhaps cause the dynamic linker to modify the same (or nearby) PLT references, it is now necessary for signals to be blocked for the duration of the mprotect. 2002-05-13T17:07:28Z fgsch fgsch@openbsd.org 2002-05-13T17:07:28Z urn:sha1:b55d46928a2b71c17e5349c93fca2971ba1cafa1 2002-03-24T18:26:31Z brad brad@openbsd.org 2002-03-24T18:26:31Z urn:sha1:e51681ba682b8a49669f4f737fe5d7b1b0871145 native linker. -- Ok'd by: pval@, fgsch@ and espie@ 2000-09-12T22:24:18Z espie espie@openbsd.org 2000-09-12T22:24:18Z urn:sha1:6a4c786fd1d49fc30ce2d67fbe51c505ff9e8345 (trivial part done, `interesting' patches remain) 2000-09-12T19:10:55Z espie espie@openbsd.org 2000-09-12T19:10:55Z urn:sha1:b305b0f1cb8417acb9d6ca66ca17b05cf1dc8fc9 1996-06-09T19:35:13Z niklas niklas@openbsd.org 1996-06-09T19:35:13Z urn:sha1:191aa56503508614b4308d555aa5d4ae85ef3df7