Only a few definitions (and some "hacks", to force glibc to
use __builtin_* where possible) that are not in our math.h
remain. This cuts out a lot more of the "bits" headers.
No "functional" change intended (but should help
fix the build on arches where we do not include
__fpclassify, etc. anymore.)
This was the last function remaining in the glibc "string" directory,
so now we can remove that directory and a bunch of related files
that are no longer needed.
The glibc libm code was showing its age, and has recently been
the subject of a number of tickets about its inaccuracy.
Additionally, some developers have complained about
how convoluted the headers are, and thus how hard it is
to add support for new architectures (and how flaky
the support for the existing architectures is.)
So, with this commit, nearly the entire glibc libm has been
gutted and replaced with the one from musl 1.1.24.
The complex functions from glibc are retained (as they
are more mature than musl's), as are some glibc-internal
libm functions.
This also has the advantage that these functions are
actually using our <math.h>, whereas GCC used its own,
which was rather dangerous for obvious reasons.
Additionally, the new math functions are always compiled
with GCC 8 (even on x86_gcc2), as it seems GCC 2 does
not quite understand some of the union-aliasing they
use (a lot of which was added in C99, I suppose.)
FFmpeg on x86_gcc2 is already compiled with GCC 8
and that has so far worked out well, so there should
not be any problems caused by this.
I did verify that ARM and PPC at least still compile,
though other architectures may require a bit more work
(they are not bootstrapped so I could not do much.)
Should fix#14933 among other issues.
Change-Id: Ifeea0ddab23a8d0480fc26dece1b0192afc263bd
glibc does the same. Technically, some of these builtins did
not exist / did not work before GCC 4.4, but the source tree
cannot be compiled with a version that old anyway.
x86_64 and _x86 need to keep the old functions for now, of
course; but all other architectures can probably feel free
to drop the s_isnan, etc. functions from their glibc.
This will make upcoming patches easier...
Change-Id: Ifb76ea74076553228c9741a8ee3ecb0e1cf736a3
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2076
Reviewed-by: waddlesplash <[email protected]>
There is a section of the spec that dictates how TRBs need to be
sized within a TD, and we were not following that. This should
bring us into compliance.
See inline comments for more details.
Even if we are still not so sure about the veracity of other
filesystem drivers, the BFS driver has had no reported corruption
bugs for quite some time (almost 2 years I think). In fact the
only real corruption issues heard of recently are from KDLs,
which are also a vanishing issue.
So, disabling the warning entirely for BFS partitions probably makes
sense at this point.
Change-Id: I5470c956d57b90ea00b647bf15299ba606ba01c4
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1822
Reviewed-by: waddlesplash <[email protected]>
The PCI enumeration functions are not implemented in the compat layer,
so we need a glue function that performs the Haiku equivalent here.
This code existed in the old Haiku-native driver, so it's just
copied from there.
The within-an-attempt timeout did not successfully break up
deadlocks that occur on a system with a lot of USB transfers
going, as we may never hit 2 seconds in between wake-ups,
but the size requested may be un-fulfillable regardless.
So, now we have a 2-second overall timeout. This fixes
the system freeze in #15569, but now attached USB disk
drives enter a Stall state, making the system unusable
anyway.
In hrev53370, leavengood refactored this function out of
PackageVolumeInfo::SetTo(). Inside that function, there
is a "state" variable which is initialized to the first,
default state, which is always the head state.
Refactoring it out of there and changing this to NULL meant
that GetNext would always return a NULL state, so the
states would never be initialized, and booting from an
old state would thus not be possible.
Fixes#15380.
It seems some drivers do not create dmamaps for all their bustags,
so we can't allocate the segments there. And of course, some also
do not go through dmamem_alloc, so the only option then is to revert
to where FreeBSD allocates them, inside dmamap_load.
It seems that some drivers (e.g. broadcom43xx) create a parent DMA tag
with nsegments set to BUS_SPACE_UNRESTRICTED, i.e. MAX_INT, which of
course fails allocation, expecting to never allocate memory for this
tag, only for child tags. So in order to handle this, we have to
delay allocating the segment array until we are certain that the nsegments
value is the "real deal".
Doing it in dmamap_load would be fine, but as there is more than one
entry point to that, we would have to allocate this in multiple places.
dmamap_create() must be called and there is only one way through it,
so put the allocation there.
Fixes#15500 (i.e. both the KDL and the underlying problem that
led to it; it only crashed because the wrong pointer was passed
to kernel_free, whoops.)
Creating a BReferenceable sets its reference count to 1.
create_port() was then acquiring 2 references for the two lists
it inserts the port object into, and subsequently delete_port()
releases those.
But that "reference 0" never was released anywhere, and so
despite being removed from hashes, etc. port objects were
just leaked, along with whatever messages remained in their
queue, never to be freed. This of course can add up pretty
quickly in systems that created and deleted ports frequently,
for instance, in long-running media playback, opening/closing
applications, etc.
As far as I can tell, this bug was introduced in the fix to
#8007 (7f64b301b1), which introduced
the ref-counting system to the port heap, so it has been with us
since 2013 (!).
Fixes#15489, and probably some of the other "media playback
memory leak" tickets.
The old implementation was based on an ancient copy of the FreeBSD
busdma code for x86, and did not make a bunch of assumptions that
we make basically everywhere else (for instance, that we can request
arbitrarily-aligned contiguous physical memory from the VM.)
As a consequence, it had a significant amount of code devoted to
bounce pages, which are just a waste of resources on x86, and
for that matter, probably any other architecture Haiku will ever
be ported to. (Even if we do need to run on some system where
only a small portion of system memory can be accessed by devices,
likely we would reserve that memory for just this occasion anyway.)
I was initially under the impression that the bounce-pages code
never turned on, but apparently due to the "alignment" check
(and also the "Maxmem" check, which was to defined to 32KB...?!)
it does indeed activate on a variety of systems, and maybe
(in the case of drivers that do not call sync() properly) even
is the cause of some of our ported driver breakage.
The new implementation is pretty much optimized for Haiku,
and shares almost no code or structure with the old one (save
for a few functions that really only have one proper implementation.)
Tested with ipro1000 and rtl81xx. Regressions are more than possible,
so please don't hesitate to file bugs if your network driver now
fails to come up (or you get KDLs.)
* Rename device.c to device_hooks.c, as this is what it really contains.
* Rename compat.c to device.c, as it implements the generic "device"
related functions, both for compat layer internals and FreeBSD
public ones.
* Move malloc and related operations out of the now-device.c,
and place them in a new "malloc.cpp", which also incorporates
compat_cpp.cpp.
No functional change intended.
This reinstates commit 2b5ebfcfd5.
According to the POSIX specification, a NULL iov_base means
"do nothing." So we should treat that as such properly,
and not consider it an invalid address.
Fixes#15356.
fQuantumStart and fLastInterruptTime were not set to 0 here, so they
would default to the "malloc-cleared" data and then always overflow
the first time the interrupt time was tracked. I can't find any
reason that was supposed to be the behavior, so just set them to 0.
Also reorder the field initializations to be the same as the class
definition, which should allow some store merging optimizations.
Spotted by KUBSAN.
Since _DispatchViewDrawingMessage sends single B_ERROR replies
in a number of generic cases, doing so here is probably fine;
it's much better than crashing, anyway.
This is the generalized case of PulkoMandy's earlier patch,
which only applied to one drawing operation. This now affects
all AGG calls.
Change-Id: I751439e43cc300b964ac4cf41c48c1df30baf0a3
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1863
Reviewed-by: Stephan Aßmus <[email protected]>
The real reason none were found is likely in the syslog.
Even if the last 15 messages do not have the real error, they
may be enough to point towards what the problem is, or at least
uniquely identify the issue.
Fixes#15348.
The iovecs themselves were checked before they were copied,
but the iov_base inside each was not, making it possible
for evil (or just broken) user applications to put kernel
addresses in here.
Part of #14961.
No functional change intended; but if I missed a case,
it will now be caught by the "return false" instead of
the "return true", which is a better default.
Non-KDEBUG kernels and kernel add-ons use atomic operations to acquire
and release the locks inline, so non-KDEBUG kernels/addons are only
compatible with other non-KDEBUG kernels/addons.
Following this change, though, KDEBUG kernels/addons should be able
to run under non-KDEBUG kernels/addons, too, since they always call
into the actual kernel functions and do not inline anything of
consequence.
As the inline comment notes, just because we could not scan one
partition does not mean we won't be able to scan the following ones.
This fixes scanning for disks on certain systems following axeld's
change in 7c2135591b.
Part of #15330.
On x86_64, it is possible for a frame address to be in non-canonical
form (i.e. have bits 48-63 not all zero) if one writes hand-generated
assembly which does not use registers for their intended purpose, as
there is no processor requirement about the contents of those registers
or stack portions except when using "ret" or similar such instructions.
As it turns out, OpenSSL's libcrypto has such hand-generated assembly
for cryptography routines; so on 64-bit this caused a GPE when running
the profiler on applications that used OpenSSL.
Fixes#14530.
Even if we are still not so sure about the veracity of other
filesystem drivers, the BFS driver has had no reported corruption
bugs for quite some time (almost 2 years I think). In fact the
only real corruption issues heard of recently are from KDLs,
which are also a vanishing issue.
So, disabling the warning entirely for BFS partitions probably makes
sense at this point.
Now it is possible to run applications, do Git checkouts, etc.
on a ramfs (and those seem to work just fine -- a git checkout
followed by a git fsck both succeeded.)
This adds one (private) VFS function, and checks in all usages of
the vnode->cache as a VMVnodeCache that it really is one. (Generic
usages, for the moment just the ReleaseRef() calls in vnode
destruction, are intentionally not touched.)
This will be used by ramfs to set the cache from its own,
so that map_file() calls on a ramfs can work.
This only works because DataCollector stores its data in blocks
which are mapped into the kernel's address space. After the
next series of commits, it won't, so we can't depend on that.
This required some changes to the indexes to keep a copy of the
keys.
Now that Attributes don't use a table, we can replace the generic
system with a specific DirectoryEntryTable, upgrading to BOpenHashTable
in the process.
This is what packagefs does; so if it's performant enough for packagefs,
it's performant enough for us. Greatly simplifies this code (and will
allow for further simplification of the NodeChildHash.)
The "exec" tool can only handle one command with environs set at
the beginning of the line, so now we set the ADD_BUILD_COMPAT...
in this format. This also seems to be a general performance
improvement to builds using real shells, too.
Change-Id: If4b3117651b5475039d5e8116cd3de398582290a
Refactored out of execvpe. Originally I did this for my attempted
change to posix_spawn, but that change turned out to be wrong and
actually not that beneficial. This bit seems potentially useful,
though, so here it is.
VAL=xxx... and VAL=$VAL:xxx... are supported; all other syntaxes
will fail with an error message.
When combined with a build/jam patch that will come in a later
commit, this makes it possible to build a large number of targets
using exec as JAMSHELL; including all of libroot. The performance
difference is extremely obvious:
jam -j2 libroot, JAMSHELL=/bin/sh (32-bit Haiku)
real 1m43.571s
user 1m10.961s
sys 1m7.965s
jam -j2 libroot, JAMSHELL=exec
real 1m28.364s
user 0m58.190s
sys 0m57.563s
So that is a savings of 15.21 seconds, or 15% of the build time.
Something that is less I/O bound and more fork-bound (e.g.
linking application catalogs) will almost certainly see
an even bigger performance difference.
Changes to add the necessary JAMSHELL overrides for those
targets which need it, in order to make it possible to
enable usage of "exec" by default, will be coming
over the next few days/weeks...
This utility takes command-strings, e.g. "gcc -c file.c -D...",
parses them into an argv, and then execvp()s that. The use-case
is Jam, which cannot do this itself, but instead simply calls
JAMSHELL (usually just "/bin/sh -c") to do that for it.
Shells in general have a large amount of overhead (and bash in
particular is especially bad here), so using a utility like this
as JAMSHELL in most cases can be a significant speed-up.
For example, on Haiku (32-bit):
$ time sh -c 'for i in {1..100}; do sh -c "./exec test"; done'
real 0m3.335s
user 0m1.603s
sys 0m1.612s
$ time sh -c 'for i in {1..100}; do ./exec test; done'
real 0m1.547s
user 0m0.597s
sys 0m0.867s
So this means for every 100 executions, using bash has about 3.3s of
overhead, and this tool cuts out over half of that. Probably for
longer command strings, the overhead is significantly greater.
But that should be clear soon enough...
This was using unsigned integer math and then trying to clamp to 0.
That won't work. Use off_t instead, which is an int64 and thus signed.
May fix behavior in some stranger error conditions.
While I'm at it, avoid reading in the beginning partial block
if we don't need to.
Augustin Cavalier