|
Revision tags: v6.2.1, v6.2.0, v6.3.0, v6.0.1, v6.0.0, v6.0.0rc1, v6.1.0, v5.8.3, v5.8.2, v5.8.1, v5.8.0, v5.9.0, v5.8.0rc1, v5.6.3, v5.6.2, v5.6.1, v5.6.0, v5.6.0rc1, v5.7.0, v5.4.3, v5.4.2, v5.4.1, v5.4.0, v5.5.0, v5.4.0rc1, v5.2.2, v5.2.1, v5.2.0, v5.3.0, v5.2.0rc, v5.0.2, v5.0.1, v5.0.0, v5.0.0rc2, v5.1.0, v5.0.0rc1, v4.8.1 |
|
| #
3e925ec2 |
| 03-Apr-2017 |
Matthew Dillon <dillon@apollo.backplane.com> |
kernel - Implement NX
* Implement the NX (no-execute) pmap bit.
* Shift sigtramp down to a page-bound and protect it prot|VM_PROT_EXECUTE.
* Map the rest of the user stack VM_PROT_READ|VM_PROT_WRI
kernel - Implement NX
* Implement the NX (no-execute) pmap bit.
* Shift sigtramp down to a page-bound and protect it prot|VM_PROT_EXECUTE.
* Map the rest of the user stack VM_PROT_READ|VM_PROT_WRITE without
VM_PROT_EXECUTE.
show more ...
|
| #
b48dd284 |
| 29-Mar-2017 |
Matthew Dillon <dillon@apollo.backplane.com> |
Kernel - Temporarily move sigtramp lower
* There is a bug in Ryzen related to the kernel iretq'ing into a high user
%rip address near the end of the user address space (top of user stack).
This
Kernel - Temporarily move sigtramp lower
* There is a bug in Ryzen related to the kernel iretq'ing into a high user
%rip address near the end of the user address space (top of user stack).
This is a temporary workaround for the issue.
* The original %rip for sigtramp was 0x00007fffffffffe0. Moving it down
to fa0 wasn't sufficient. Moving it down to f00 moved the bug from nearly
instant to taking a few hours to reproduce. Moving it down to be0 it took
a day to reproduce. Moving it down to 0x00007ffffffffba0 (this commit)
survived the overnight test.
show more ...
|
|
Revision tags: v4.8.0 |
|
| #
25829230 |
| 26-Mar-2017 |
Matthew Dillon <dillon@apollo.backplane.com> |
Kernel - quick workaround for Ryzen
* Quick workaround for a Ryzen issue that we can release with.
|
|
Revision tags: v4.6.2, v4.9.0, v4.8.0rc, v4.6.1, v4.6.0, v4.6.0rc2, v4.6.0rc, v4.7.0, v4.4.3, v4.4.2, v4.4.1, v4.4.0, v4.5.0, v4.4.0rc, v4.2.4, v4.3.1, v4.2.3, v4.2.1, v4.2.0, v4.0.6, v4.3.0, v4.2.0rc, v4.0.5, v4.0.4, v4.0.3, v4.0.2, v4.0.1, v4.0.0, v4.0.0rc3, v4.0.0rc2, v4.0.0rc, v4.1.0, v3.8.2, v3.8.1, v3.6.3, v3.8.0, v3.8.0rc2, v3.9.0, v3.8.0rc, v3.6.2, v3.6.1, v3.6.0, v3.7.1, v3.6.0rc, v3.7.0, v3.4.3, v3.4.2, v3.4.0, v3.4.1, v3.4.0rc, v3.5.0, v3.2.2, v3.2.1, v3.2.0, v3.3.0, v3.0.3, v3.0.2, v3.0.1, v3.1.0, v3.0.0 |
|
| #
86d7f5d3 |
| 26-Nov-2011 |
John Marino <draco@marino.st> |
Initial import of binutils 2.22 on the new vendor branch
Future versions of binutils will also reside on this branch rather
than continuing to create new binutils branches for each new version.
|
|
Revision tags: v2.12.0, v2.13.0, v2.10.1, v2.11.0, v2.10.0, v2.9.1, v2.8.2, v2.8.1, v2.8.0, v2.9.0, v2.6.3, v2.7.3, v2.6.2, v2.7.2, v2.7.1, v2.6.1, v2.7.0, v2.6.0 |
|
| #
b2b3ffcd |
| 04-Nov-2009 |
Simon Schubert <corecode@dragonflybsd.org> |
rename amd64 architecture to x86_64
The rest of the world seems to call amd64 x86_64. Bite the bullet and
rename all of the architecture files and references. This will
hopefully make pkgsrc build
rename amd64 architecture to x86_64
The rest of the world seems to call amd64 x86_64. Bite the bullet and
rename all of the architecture files and references. This will
hopefully make pkgsrc builds less painful.
Discussed-with: dillon@
show more ...
|
| #
c1543a89 |
| 04-Nov-2009 |
Simon Schubert <corecode@dragonflybsd.org> |
rename amd64 architecture to x86_64
The rest of the world seems to call amd64 x86_64. Bite the bullet and
rename all of the architecture files and references. This will
hopefully make pkgsrc build
rename amd64 architecture to x86_64
The rest of the world seems to call amd64 x86_64. Bite the bullet and
rename all of the architecture files and references. This will
hopefully make pkgsrc builds less painful.
Discussed-with: dillon@
show more ...
|