summaryrefslogtreecommitdiffstats
path: root/gnu (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Never automatically rewrite perl/dist/Devel-PPPort/t/01_test.tafresh12021-03-041-1/+1
| | | | | | | | | We are never going to update the files that generate this test and the interaction with "cvs up" means we can accidentally hit it when they hange between releases but permissions when building the system prevent us from writing the update and breaks the build. Found by naddy@, krw@, and deraadt@
* Apply pre-built unicore patch, remove excess files - perl-5.32.1afresh12021-03-01550-124170/+216104
| | | | OK sthen@
* Apply local patches, remove excess files - perl-5.32.1afresh12021-03-0154-525/+363
| | | | OK sthen@
* Fix merge issues, remove excess files - match perl-5.32.1 distafresh12021-03-01981-71740/+84299
| | | | OK sthen@
* Import perl-5.32.1afresh12021-03-01752-17266/+45020
| | | | OK sthen@
* Make the unwind cache tread-safe by declaring it thread_local. Solvesotto2021-02-201-1/+1
| | | | segfaults seen on exception handling. ok kettenis@
* Recommit upstream alignment fix plus libperl version bumpafresh12021-02-204-25/+41
| | | | | | | This reapplies commit e0lLUzj1XNW7pJMh and moves libperl to 21.0 The ABI change appears to be fine after XS modules are rebuilt. OK sthen@
* Revery previous hash alignment fixafresh12021-02-163-40/+24
| | | | Unintentionally changes ABI and breaks perl ports
* Backport upstream perl 64bit hash alignment fixesafresh12021-02-163-24/+40
| | | | | | | | | | | | | | | | Different flags triggering new compiler optimizations means that luck has run out on this working by chance with the strict alignment of octeon. Upstream issue: https://github.com/Perl/perl5/issues/18555 This is a combination of three commits from upstream. https://github.com/Perl/perl5/commit/d18575f18c6ee61ce80492e82cae7361358d570a https://github.com/Perl/perl5/commit/6027b190154088fbbcbde08a80c49531e4e4c012 https://github.com/Perl/perl5/commit/f43079cb514e3d0be0036424695438ae3fb58451 works on all arch deraadt@
* Shuffle how lldb register contexts are built.mortimer2021-02-149-29/+48
| | | | | | | | | | | | Instead of using #if defined(__arch__) to include / exclude the entire contents of the NativeRegisterContext implementations, use a single NativeRegisterContextOpenBSD_arch which includes the right arch specific register context, and provides a dummy implementation for unsupported architectures. This allows building lldb on architectures which do not have a register context implementation so it can be used as a remote client. ok patrick@
* Cleanup lldb amd64 support.mortimer2021-02-134-474/+213
| | | | | | | | | | | | | | | | - Remove watchpoint support since we do not support hardware watchpoints. - Support floating point regsisters in the ReadAll/WriteAll interface. - Standardize the sizes used in GerGPRSize() and GetFPRSize() to correspond to the sizes we get from ptrace. - Fix the r/w of the mmx registers to map onto the st fp registers instead of xmm registers. - Normalize some variable names to be architecture neutral. ok patrick@
* When clang was changed to -fcommon, perl's P_hash_{seed,state} variablesderaadt2021-02-111-1/+2
| | | | | | | | | | | | | | moved into BSS in the .o, with padding rules following the types -- they are both char[]. Since P_hash_seed is (system-dependent) not a multiple of 8, P_hash_state gets layed out misaligned, which sucks because the hash functions demand 64-bit alignment for both variables. There is the possibility of using misalignment macros, but this is not cheap. Could also use kernel-trap fault repair, but the performance would really suck for something so crucial. The correct fix would be for upstream to declare these types as uint64[], we have requested that in https://github.com/Perl/perl5/issues/18555 In the meantime, carry a diff to roundup P_hash_seed to 64-bit alignment so that P_hash_state will land aligned. ok afresh1
* only amd64 & arm64 lldb work at the momentderaadt2021-02-102-2/+12
|
* Build and install lldb.patrick2021-02-092-4/+4
| | | | Discussed with deraadt@
* Fix lldb.mortimer2021-02-092-14/+4
| | | | | | | | Map deliberately invalid signal to zero when passing to PT_STEP and P_CONTINUE. Also clean up getting Environment so setting LLDB_DEBUGSERVER env vars works again. ok patrick@
* switch clang to -fno-common by defaultnaddy2021-02-063-21/+6
| | | | | | | | | | Common variables will be flagged as errors by default. This can be overridden with -fcommon. Cherry-pick this change that will be part of LLVM11. We bring it forward so we can finish fixing the fallout in the ports tree. ok deraadt@ sthen@ mglocker@
* a regular function decl collides with an inline, due to C99 inline rules.deraadt2021-02-011-1/+2
| | | | | | | We are never updating this sub-tree. Knock out the collision in the simplest way. diff from mortimer. This is the last change required for -fno-common on all architectures, thanks to mortimer for starting the effort and encouraging others.
* Extern dwarf2_loc_mark_labels. Fixes compiation with -fno-common.mortimer2021-01-281-1/+1
| | | | ok deraadt@
* Explicitly enable -fcommon, rather than untangle common symbols.mortimer2021-01-281-1/+2
| | | | ok deraadt@
* Switch libc++ and libc++abi to version 10.0.1.patrick2021-01-114-20/+15
| | | | | | Further libc++ header fixes for ports thanks to kettenis@ Ports build test and fixes thanks to naddy@ "Startschuss!" naddy@
* Backport fix to avoid including math.h from stdlib.h.kettenis2021-01-102-62/+63
| | | | | | Fixes building the textproc/groff port (and maybe others). ok naddy@
* Re-apply our libc++ 8.0.0 patches to libc++ 10.0.1.patrick2021-01-027-12/+35
|
* Adjust link path for libc++ to find libc++abi to match change of Makefilepatrick2021-01-021-2/+2
| | | | and build location.
* Import libc++abi 10.0.1 release.patrick2021-01-0249-0/+15495
|
* Import libc++ 10.0.1 release.patrick2021-01-02469-0/+220737
|
* Move Makefiles for libc++ and libc++abi to gnu/lib in preparation for anpatrick2021-01-025-1/+408
| | | | | | | | upcoming update to those, which will see both codebases heading into the gnu/llvm dumpster. Feedback from jsg@ ok deraadt@ kettenis@
* Merge compiler-rt 11.0.0.patrick2021-01-027-157/+10
| | | | ok kettenis@
* Import compiler-rt 11.0.0 release.patrick2021-01-02357-3776/+10123
| | | | ok kettenis@
* Adjust local modifications to follow changes made upstream.kettenis2021-01-022-3/+3
| | | | | | Fixes build on powerpc and sparc64. ok patrick@
* Re-apply our libunwind 8.0.0 patches to libunwind 11.0.0. Patches to thepatrick2021-01-0212-23/+407
| | | | | | | PPC ASM had to be re-applied manually due to whitespace changes upstream, other merge conflicts were harmless. "Looks good" kettenis@
* Import libunwind 11.0.0 in new LLVM directory, thus not yet linked topatrick2021-01-0233-0/+19171
| | | | | | build. Encouraged by kettenis@
* Skip leaf function optimization under some circumstances.mortimer2021-01-011-1/+110
| | | | | | | | On architectures that do not always spill the return address to the stack, it is possible for local stack frame data corruption in leaf functions to span stack frames if the retguard cookie is not spilled in the function. In leaf functions on these architectures, now spill the retguard cookie if the function contains arrays or has variables which have their address taken.
* Fix a bug that GDB could not show the symbols of the core dump it wasasou2020-12-021-1/+35
| | | | | | generated with the static linked ELF file. ok mpi@
* Implement Loongson 2F BTB bug workaround in clangvisa2020-12-018-1/+162
| | | | | | | | | | This adapts the -mfix-loongson2f-btb workaround from as(1) to LLVM/clang. Because LLVM emits machine code directly without using assembly as intermediary form, the workaround has to be applied in the compiler backend in addition to the integrated assembler. Discussed with miod@ OK mortimer@
* Teach lld to link the macppc kernelgkoehler2020-11-291-0/+2
| | | | | | | | | | | | | | | | Add R_PPC_ADDR24 to lld. We need R_PPC_ADDR24 for absolute branches "ba" and "bla" in locore.S in the kernel. In Makefile.macppc, add a gapdummy (like in Makefile.powerpc64) to avoid an lld error. Also adapt a part of Makefile.i386, so my powerpc64 can use clang and lld to build and link the macppc kernel. (I didn't boot that kernel.) My macppc can now build, link, and boot kernels with either ld.bfd or ld.lld. Beware that kernels linked with ld.lld have at least one problem (wrong &etext) not yet fixed. ok kettenis@
* Backport https://reviews.llvm.org/D75419. This adds a workaround forkettenis2020-11-212-4/+9
| | | | | | | undefined references to .got2 on powerpc making it possible to link llvm with lld. ok gkoehler@
* Fix va_arg in C++, Objective-C on 32-bit powerpcgkoehler2020-11-201-3/+2
| | | | | | | | | | | | | | | | | In the PPC32 SVR4 ABI, a va_list has copies of registers from the function call. va_arg looked in the wrong registers for (the pointer representation of) an object in Objective-C, and for some types in C++. Fix va_arg to look in the general-purpose registers, not the floating-point registers. Also fix va_arg for some C++ types, like a member function pointer, that are aggregates for the ABI. Anthony Richardby found the problem in Objective-C. Eli Friedman suggested part of this fix. Fixes https://bugs.llvm.org/show_bug.cgi?id=47921 I have submitted this diff as https://reviews.llvm.org/D90329 ok kettenis@
* Sort list of archs in alphabetical order.patrick2020-11-101-4/+4
| | | | | From Brad ok mortimer@
* Do not reserve PowerPC GOT header entries when creating a relocatablekettenis2020-11-011-1/+1
| | | | | | object file. ok guenther@
* Use all 64 bits of the RETGUARD cookie on powerpc64gkoehler2020-10-181-14/+7
| | | | | | | Change the 64-bit target to use "ld" (load 64-bit doubleword) for the cookie. The 32-bit target stays with "lwz" (load 32-bit word). ok mortimer@
* Disable retguard for clang build.mortimer2020-10-121-2/+2
| | | | Fixes build on powerpc
* Add RETGUARD implementation for powerpc and powerpc64.mortimer2020-10-129-1/+451
| | | | ok deraadt@ kettenis@
* Always allocate GOT header entries on powerpc.kettenis2020-10-111-0/+2
| | | | ok deraadt@
* Add minimal support for OpenBSD/powerpc64.kettenis2020-09-307-0/+748
|
* Don't pass the -dynamic-linker flag to ld when linking statically.millert2020-09-2311-11/+11
| | | | | Fixes creation of static binaries with base gcc and ld.lld. OK kettenis@ a while ago, prodded by daniel@
* Fix frame pointer slot on aarch64 for functions that do not save calleemortimer2020-09-191-12/+6
| | | | | | registers with retguard enabled. ok kettenis@
* Avoid generating a core dump during make build. The Perl configurebluhm2020-09-161-0/+1
| | | | | | | test program "try" already has a signal handler for SIGSEGV, but OpenBSD generates a SIGBUS. Also set a handler for the latter to exit cleanly. from deraadt@; OK afresh1@
* Disable strict floating point if not X86gkoehler2020-09-1012-0/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Disable options like clang -fno-unsafe-math-optimizations for all targets except X86 (and SystemZ). This prevents a crash of clang, reported by cwen@, in graphics/babl or emulators/mednafen for powerpc. ok mortimer@ This change comes from llvm 11.x: https://github.com/llvm/llvm-project/commit/d4ce862 Reland "[FPEnv][Clang][Driver] Disable constrained floating point on targets lacking support." We currently have strict floating point/constrained floating point enabled for all targets. Constrained SDAG nodes get converted to the regular ones before reaching the target layer. In theory this should be fine. However, the changes are exposed to users through multiple clang options already in use in the field, and the changes are _completely_ _untested_ on almost all of our targets. Bugs have already been found, like "https://bugs.llvm.org/show_bug.cgi?id=45274". This patch disables constrained floating point options in clang everywhere except X86 and SystemZ. A warning will be printed when this happens. Use the new -fexperimental-strict-floating-point flag to force allowing strict floating point on hosts that aren't already marked as supporting it (X86 and SystemZ). Differential Revision: https://reviews.llvm.org/D80952
* Delete my leftover comment.gkoehler2020-08-311-1/+0
| | | | | | | | | | | This comment was from my commit of 2020-05-02, > Don't make an illegal adde. Avoids fatal error on PowerPC. When we merged LLVM 10, we got upstream's fix for the illegal adde problem, and this comment became the only difference in this file between us and upstream. Found by Brad Smith.
* Remove local change to fix powerpc floating-point alignmentgkoehler2020-08-142-9/+0
| | | | | | | | LLVM 10 includes a different fix (https://reviews.llvm.org/D71954), so this change (by kettenis on 2019-02-18) is no longer needed. Thanks to Brad Smith for providing the removal diff. ok kettenis@
Copyright © 1996 – 2023 Jason A. Donenfeld. All Rights Reverse Engineered.