amd64: revert back struct trapframe to the pre-FRED definition
Trying to use the grown struct trapframe for IDT case broke in cases
where code supposed that hardware consumed sizeof(struct trapframe) of
the stack space when delivering interrupt or exception. In particular,
this was broken for #NM/#DB/#MC. Naive attempt of using IDT-trapframe
size for stack consumption caused later problems with larger C type.
Instead of pretending that IDT event delivery pushed two never-accessed
doubleword to the stack, keep it honest and provide separate type for
the FRED interrupt frame, i.e. struct trapframe_fred.
Convert between trapframe_fred and trapframe can be done by trivial pointer
arithmetic.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
emulators/wine-devel: Improve messages around WoW
Sync with emulators/wine where commit 942473af4d improved a number of
messages (and comments) around WoW, i.e. 32-bit support on amd64.
PR: 293073, 291328
Approved by: Thibault Payet <monwarez at mailoo.org> (maintainer)
LinuxKPI: add supporting #includes
Compiling drm-kmod on !X86 does not include asm/smp.h which includes
preempt.h on FreeBSD. In order to compile drm-kmod on other
architectures add the secondary #includes for preempt.h to
spinlock.h and hardirq.h (which now also gets included from highmem.h)
to connect the #include chain.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
PR: 279864
Reviewed by: jhibbits, emaste
Differential Revision: https://reviews.freebsd.org/D55974
sbuf: make assertion message a lot more useable
Saying that we are called with an (un)finished or corrupted sbuf
is like saying "error" (though [un]finished is an extra hint).
Add the pointer to the sbuf so one could easily check it,
add the flags we are checking so one could see quickly about
a possible state mismatch.
Given we already dereference the pointer in the KASSERT there is no
extra harm adding it to the message.
Found while: testing lindebugfs changes
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Reviewed by: jhb
Differential Revision: https://reviews.freebsd.org/D55919
math/ess: Update to 26.01.0
ESS[BUGS] is still relevant due to NIMBLE keeping the language alive.
However, only syntax highlighting and key-presses will be supported
moving forward. For example, the < key now generates <- rather than
the former = since equals is a valid character in NIMBLE BUGS.
Reported by: Repology
math/eigen5: Remove GL_TAGNAME
This didn't work iin GitLab a long time ago, GL_TAGNAME
was mandatory, amd the latent memory of this caused me
to add GL_TAGNAME.
Reported by: Gleb Popov <arrowd at freebsd.org>
math/eigen5: New port: Lightweight library for vector and matrix math
math/eigen3 is obviously 2 major version numbers behind.
The misc/quantum++ port needs eigen-5.x
It might or might not be better to update math/eigen to 5.x - I am not
sure. Let's have math/eigen5 for now for ports that need it.
Revert "vmimage.subr: pkg autoremove after pkg install"
This reverts commit 6a13aeac3c1f98db7cf156f24a4d6bc8d3c321f6.
The "bogus dependencies being installed" issue was traced down to pkg
confusion surrounding libclang_rt.asan-i386.so linking to a 32-bit
libgcc_s.so.1, and a more minimal workaround of "install clibs-lib32"
has been applied, so this hack is no longer required.
MFC after: 3 days
Sponsored by: Amazon
EC2: Add clibs-lib32 pkg to small/builder images
The FreeBSD-clang package on amd64 contains libclang_rt.asan-i386.so,
which links to the 32-bit version of libgcc_s.so.1. It is not clear
if that file belongs in FreeBSD-clang or if it should be placed into
a different package.
For unknown reasons, pkg *sometimes* recognizes this and decides that
it needs to install a package to supply libgcc_s.so.1:32.
In particular, when we initially install the VM with 'pkg install
[long list of FreeBSD-* packages]', pkg does not recognize that it
wants this; but the *next* time 'pkg install' runs, it decides that
it needs libgcc_s.so.1:32 -- even though that particular library is
not needed by the particular package we're trying to install -- and
goes looking for it... and ends up picking gcc12-devel as a provider.
Later in the EC2 image building process, we run 'pkg autoremove' (which
was added during 15.0 to get rid of the "bogus dependencies" which were
[19 lines not shown]
Revert "lang/rust: fix build with LLVM 22 (PORT_LLVM option)"
This reverts commit 91d047221724449855d84465d8ca53bdddb9fcc2.
This patch was not approved.
This patch interferes with pending rust update (pr 293615)
There was no rush to push this patch since there is a pending rust update (pr 293615)
It breaks lang/rust-nightly
