GCC knows whether these functions need to be implemented using syscalls
(or more clever solutions like in Linux) and calls libgcc in such case.
Signed-off-by: Paweł Dziepak <pdziepak@quarnos.org>
The less assembler in our sources the better. These functions wouldn't
be used very much since SupportDef.h inlines them, but the symbols should
be available.
Signed-off-by: Paweł Dziepak <pdziepak@quarnos.org>
Time to get rid of some asm code. Surprisingly, it appears that
on x86[_64] the emitted code for atomic_test_and_get() isn't as efficient
as it could be, even with -O2, but cmpxchg is so expensive that this slight
difference shouldn't matter much.
Signed-off-by: Paweł Dziepak <pdziepak@quarnos.org>
* Restore missing definitions of std::nothrow and mynothrow that are
required for the debug build.
* Additionally, cleanup function overrides provided by kernel_cpp,
such that any exceptions in kernel, bootloader or runtime_loader will
trigger a panic.
* From now on, the gcc-specific system libraries (libgcc, libsupc++ and
libstdc++) are provided by separate packages built along with gcc:
- gcc_syslibs contains the shared libraries (libgcc_s.so, libsupc++.so and
libstdc++.so)
- gcc_syslibs_devel contains the static libraries and both c++ and gcc
headers
The shared libraries now make proper use of symbol versioning and there
are version-specific symlinks
* The buildsystem has been adjusted to no longer use the libraries and
headers from the cross-compiler, but use the ones provided by the
above-mentioned packages. The only exception is that the 32-bit libraries
required for the bootloader of the x86_64 architecture are still taken
from the cross-compiler.
* <stubbed>libroot.so is a shared library which contains all the symbols
from libroot, but without any code. This library will be required by
the (to be introduced) stage0 of the bootstrap process, in order to
be able to link the shared gcc syslibs (libstdc++.so, libsupc++.so
and libgcc_s.so).
* The new libstdc++.so contains program headers of type PT_RELRO (for
making segments read-only after relocation). While the actual feature
has not been implemented, the runtime_loader should now silently
accept (and ignore) those program headers.
* Instead of faking libstdc++.so from libstdc++.a, use libstdc++.so
from the gcc_syslibs build feature for everything except x86_gcc2.
* Use libgcc_s.so from the gcc_syslibs build feature for everything but
x86_gcc2 (which still carries libgcc as part of libroot.so).
* Drop filtering of libgcc objects for libroot, as that is no longer
necessary since we're only using libgcc-as-single-object for libroot
with x86_gcc2, where the filtered object file doesn't exist. Should
the objects that used to be filtered cause any problems as part of
libgcc_s.so, we can always filter them as part of the gcc build.
* Use libsupc++.so from the gcc_syslibs build feature for everything but
x86_gcc2.
* Adjust all Jamfiles accordingly.
* Deactivate building of faked libstdc++.so for non-x86-gcc2. For
x86_gcc2, we still build libstdc++.so from the sources in the Haiku
source tree as part of the Haiku build .
* Put gcc_syslibs package onto the image, when needed.
instead or additionally to string.h, in preparation for functions move.
* moves str[n]casecmp() functions and others to strings.h.
* strings.h doesn't include string.h anymore.
* this solves #10949
in arch_vm_translation_map_is_kernel_page_accessible. Fix borrowed from x86
(commit 428b9e758c).
Signed-off-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
Fixes#11107.
It only makes sense to add the ABI directories to library paths
created by Haiku itself. E.g. on a gcc2h build, appending x86.
This also fixes build issues where LIBRARY_PATH is amended, and
the target binaries and libraries are in different locations.
Note: the develop lib directories were excluded, as runtime_loader
shouldn't be looking at these in the first place.
* Prefix lock functions with __ to mark them as private. Add
forwarding macros to keep existing code working.
* Avoids symbol name clashes with kernel lock APIs, occuring when
using kernellandemu-lib in userlandfs. Thanks to Ingo for the
suggestion.
* PackageFileHeap{Reader,Writer} as well as Package{Reader,Writer} and
their implementation and super classes do now internally use a
BPositionIO instead of a FD to access the package file. This provides
more flexibility needed for features to come.
* BPackageReader has already grown a new Init() version with a
BPositionIO* parameter.
* Ingo copied the methods into a shared location, and then obviously
"forgot" to let BFS use them. As a side note for Ingo: the complete
error GCC reported was "std::fssh_size_t" not defined with the macro
wrapper as code location. The actual problem was a "using std::size_t"
in some C++ header that accidentally got included after the wrapper.
* The shared Query code is not yet used. That'll be done another time.
* Renamed BFS_SHELL define to FS_SHELL, such that QueryParserUtils can be
used in any file system shell, not just the bfs_shell.
* The number of IO vectors is not 256 on x86, but rather 224 as set by
NUM_IO_VECTORS in "arch_int.h".
* Jessicah mentioned hearing about MSI crashes before, but that was a
few weeks ago.
* These were the only CIDs in the MSI code.
Signed-off-by: Michael Lotz <mmlr@mlotz.ch>
* I tried having this test in KDiskDeviceManager.cpp, but it
failed booting in one case and did not solve the problem in another.
I think this is because there is an Open() call here, and that rereads
the blocksize.
* Tested and it solved the problem for me.
* Should fix#10717 and #9489 at least.
Signed-off-by: Jessica Hamilton <jessica.l.hamilton@gmail.com>
* Currently, no command line options are being passed via u-boot
to haiku. However, the comparison doesn't ensure that cmdline
is not an empty string - it merely ensures cmdline is not null.
Signed-off-by: Ithamar R. Adema <ithamar@upgrade-android.com>
* After initializing the page table and enabling MMU,
the pre-MMU stack becomes invalid leading to a fault.
This was fixed by moving the stack to SDRAM as specified
in LOADER_MEMORYMAP before ARM entry point start_netbsd.
Signed-off-by: Ithamar R. Adema <ithamar@upgrade-android.com>
When an ARMv7 CPU is detected, immediately turn on the FPU. This allows
us to use vsnprintf in the TRACE call in that function, as our libc is
compiled with floating point support and will trigger a fault if the FPU
is not available.
This lets the boot go further, and crash in mmu_init. Next steps:
* Find why mmu_init is crashing
* Setup some fault handlers, otherwise we call uboot ones, and they are
not very helpful. They will also probably not work once the mmu is
enabledvery helpful. They will also probably not work once the mmu is
enabledvery helpful. They will also probably not work once the mmu is
enabled...
Loading of haiku_loader from an uImage is a 2-step process:
* First, the uImage is loaded (in our case from SD card using fatload)
to RAM at a temporary address.
* Then (using bootm), it is unpacked. The uImage is a container format
and can hold several files, with a load and execution address. The files
are copied from the uImage to their final location, and it's better if
that doesn't overlap with the uImage content
When this loading is done, bootm jumps to the entry point found in the
uImage.
We now actually execute our code from haiku_loader. This crashes with
the following call stack:
* vsnprintf
* dprintf
* boot_arch_cpu_init
* cpu_init
It seems vsnprintf is trying to use VFP instructions (probably from the
libgcc) but that triggers some kind of fault, and the handler (setup by
uboot?) ends up crashing the system by jumping to unmapped memory at 0.
* Cleanup the SD card image building to allow jam -q @bootstrap-mmc to
work.
There are a few remaining tricks before you can safely build an image:
* This uses a non-POSIX du option, and is only tested with Linux du
only (Linux is the only supported system to run bootstrap builds,
anyway)
* The Python recipe in haikuports.cross is known to not build on
Debian/Ubuntu, but work fine on OpenSuse. There is a patch available in
haikuports bugtracker to allow the reverse.
* You need to populate the haikuports repo package list with some
packages (which don't exist yet) to make the build system happy. But our
git hook to generate the repositories is preventnig me to share this
hack.
Once built, the image currently crashes early in the kernel execution.
On to debug that!
* thanks to Ingo for suggesting the idea, quoting him:
"by holding sVnodeLock read-locked, get_mount() ensures that fs_unmount() can't
process the nodes. If it is already past that point, the root node check
(not NULL, not busy, ref count > 0) is supposed to detect that. But it doesn't
look like this can work. fs_unmount() doesn't set the root node to NULL (the
root node field is NULL only during a short period in fs_mount()), but it just
frees the nodes after releasing sVnodeLock. So the not busy and ref count > 0
checks could already access freed memory".
* tested OK, this fixes#10522.
* replaced mount->root_vnode by the local variable with the same value.
The way we handle paging is very wasteful and relies heavily on virtual
funcions even if there is absolutely no reason to do so. The proper
solution would be to do a major rework of paging code (including
arch-independent parts).
On x86_64 physical page mapper is very simple what makes the overhead
resulting from the desing of paging interface very expensive. This
patch attempts to make things a bit better by helping GCC with
devirtualization and allowing inlining physical page mapper impementation
(well, only when it is devirtualized).
This fixes the problem with find_unique_check_sums() taking a very long
time to complete when one or more drives report read errors.
Fixes#10880.
[Paweł: minor style issue]
Signed-off-by: Paweł Dziepak <pdziepak@quarnos.org>
* A problem with our gcc requires adding casts for gcc4 when
the __builtin_bswap functions are used with a format string
* Unlike gcc2, the __builtin_bswap functions do not get disabled
despite using -fno-builtins, hence added compiler check in
runtime_loader/utility.cpp
This patch makes it possible to inline rdmsr and wrmsr instruction. The
performance impact shouldn't be significant since they are used relatively
rarely and wrmsr is usually a serializing instruction, but there is no reason
not to do so.
The goal of this patch is to amortize the cost of context switch by making
the compiler aware that context switch clobbers all registers. Because all
register need to be saved anyway there is no additional cost of using
callee saved register in the function that does the context switch.
Similarly to previous patch regarding GDT this is mostly a rewrite of
IDT handling code from C to C++. Thanks to constexpr IDT is now entirely
generated at compile-time.
Virtually no functional change, just rewriting the code from
"C in *.cpp files" to C++. Use of constexpr may be advantageous but
that code is not performance critical anyway.
While resolving TLS related relocations it is necessary to know the DSO
that defines the symbol. Without proper support in caching that information
is available only when the symbol is resolved first time. That works well
for TLS since TLS_DTPMOD is guaranteed to be before TLS_DTPOFF relocation.
This patch makes the newly introduced parts of the interface work in a
general case.
Previously TLS_DTPMOD relocation blindly returned ID of the current DSO.
This patch does proper symbol lookup if there is a symbol assigned to the
relocation and uses ID of the DSO in which the symbol is defined.
This patch introduces support of ELF based TLS handling with lazy allocation
and initalization of TLS block for each DSO and thread. The implementation
generally follows the official ABI except that generation counter in dtv
is in fact a pointer to Generation object that contains both generation
counter and size of the dtv. That simplified the implementation a bit, but
could be changed later. The ABI requirements regariding in memory position
of TLS block is not honoured what results in static TLS model being
unsupported. However, that should not be a problem as long as
"executables" in Haiku are in fact shared objects and optimizations which
require specific TLS block in memory layout are not possible anyway.
* Fixes missing atomic stuff that gcc requires
* The gcc build still fails further down, because of a mixup of
VFP/nonVFP objects (at least for beagle build).
The scheduler expects that all threads expect the initial idle threads
have priority in range [THREAD_MIN_SET_PRIORITY, THREAD_MAX_SET_PRIORITY].
If the requested pririty is out of range the value is clamped. Failing
with B_BAD_VALUE is probably an overkill since there isn't any real
change in the guarantees provided by the scheduler about the behavior
of such thread. Also, BeBook suggests that spawn_thread() can specify
priority 0.
For potential boot volumes with older packages states the respective
item in the boot volume menu now has a sub menu for selecting a state.
The boot loader functionality for this feature is complete -- i.e. the
respective kernel is loaded and the name of the old state is added to
the kernel args -- but kernel packagefs and package daemon support is
still missing.
... in filenames. Replace the existing Unicode conversion functions
with UTF conversion functions from js that he relicensed MIT for us.
Put the UTF conversion functions in a private but shared code location
so that they can be accessed throughout the kernel.
Right now we only provide functions to convert between UTF-8 and UTF-16.
At some point we should also add functions to convert between UTF-8 and
UTF-32 and UTF-16 and UTF-32 but these aren't needed by exfat.
Remove the old Unicode conversion functions from exfat as they assumed
UCS-2 characters and don't work with UTF-16 used by exfat.
Rename most variables with the term length with code unit where code units
are intended. The term length, when used, means length in bytes while code
units represent either a full 2-byte UTF-16 character or half a 4-byte
surrogate pair.
This patch remove the old thread migration logic which used few special
cases and (broken) general check that attempted to balance threads.
The new logic is pretty straightforward and seems perform well without
any additional special cases. Current core is compared with the least loaded
one and the thread is migrated if that would result in estimated loads of
both cores (i.e. the current one and the least loaded one) to become closer
to the average load (i.e. average of that two cores).
Currently, ThreadData::ShouldRebalance() (and mode specific functions
it calls) only decides whether to migrate thread to another core or not.
However, in most cases it actually needs to find the best candidate for
new core so it could as well return that information.