This allows naming the boot loader package canoncically. Due to code
size limitations we cannot perform a more correct name check, but there
shouldn't be any other entries in the packages directory with a name
with "haiku_loader" prefix, anyway.
Instead of listing all the objects we want from the libgcc archive
we just make a copy of it and remove those we don't want, and link
to it.
This should allow returning MAXLINE in jam to a sane value.
* Increase general allocation alignment from 4 to 8 byte. That was even
incorrect.
* Use a splay tree instead of a singly linked list to manage the free
chunks. That increases the size of the per-chunk structure to manage
the free chunks, i.e. the of minimally allocatable memory size (from
align(sizeof(void*)) to align(3 * sizeof(void*))), but make finding
and inserting chunks much faster.
Fixes#10063 respectively improves the situation significantly.
Should already have been done back when the semantics for the
B_COMMON_*DIRECTORY constants was changed.
Currently old and new version behave the same. So this is just a
contingency measure ATM.
* This does intentionally break source compatibility, so that a review
of concerned code is forced.
* Binary compatibility should be maintained in most cases. The values
of the constants for the writable directories are now used for the
writable system directories. The values for the non-writable
directories are mapped to "/boot/system/data/empty/...", an empty or
non-existent directory, so that they will simply be skipped in search
paths. Only code that explicitly expects to find something in a
B_COMMON_* directory, will fail.
* Remove support for the "common" installation location from packagefs,
package kit, package daemon, package managers.
* Rename the B_COMMON_*_DIRECTORY constants referring to writable
directories to B_SYSTEM_*_DIRECTORY.
* Remove/adjust the use of various B_COMMON_*_DIRECTORY constants.
I'm sure some occurrence still remain. They can be adjusted when the
remaining B_COMMON_*_DIRECTORY constants are removed.
* find_directory() and hard-coded paths use /boot/system instead of
/boot/common.
* The build system creates the writable directories in /boot/system
instead of /boot/common.
* The build system no longer installs any packages in /boot/common.
Since we are using libraries originally intendent for user mode in kernel
mode providing them with some userland functions is inevitable. This
particular patch is to make zlib happy and able to call exit() when
its debug assertions fails.
Latest gcc converts the old ones to the new ones anyway...
including when passing to gas, which of course is not new enough,
so we have to also force gcc to pass the old one around in one case.
jam fails in execve() trying to run the command due to
a too large arguments list because of the many objects in libgcc.
We split them into two intermediate objects,
then we link them to libroot.
* __pthread_destroy_thread() will in turn free the pthread_thread object.
* this fixes a leak of 2072 bytes on each thread construction/destruction
and #9945. MediaExtractor spawns a thread on construction, which leaked
its pthread_thread object on destuction.
If the alternate signal stack is used randomize the initial stack
pointer in the same way it is randomized on "normal" thread stacks.
Also, update MINSIGSTKSZ value so that regardless of where the new
stack pointer points to there is at least 4k of stack left.
Support for 64-bit atomic operations for ARMv7+ is currently stubbed
out in libroot, but our current targets do not use it anyway.
We now select atomics-as-syscalls automatically based on the ARM
architecture we're building for. The intent is to do away with
most of the board specifics (at the very least on the kernel side)
and just specify the lowest ARMvX version you want to build for.
This will give flexibility in being able to distribute a single
image for a wide range of devices, and building a tuned system
for one specific core type.
Now we check whether the virtual address corresponding to the PTE lies
in an allocated virtual address range. This fixes a cause of #8345:
The assertion would trigger when such an entry was encountered. There
might be other causes that trigger the same assertion, though.
