Add empty implementation of timer, elf, vm, debugger support, to let the
kernel link.
Also add the kernel linker script.
Change-Id: If0795fa6554aea3df1ee544c25cc4832634ffd78
Reviewed-on: https://review.haiku-os.org/c/1108
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Previous commit adding these was merged very quickly, so here's one
more...
Change-Id: I23c424db7631db1f0ec48e2d0ae47c8409ae6af2
Reviewed-on: https://review.haiku-os.org/c/1088
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
I'm copypasting a lot from this, so I may as well clean it up while I'm
at it.
Change-Id: I9288c087abbf95475f980b5539f2fd19fad7f775
Reviewed-on: https://review.haiku-os.org/c/1136
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Getting 64 bytes of data in a 32 bit variable is a bad idea
Change-Id: I760e1cfb996a9be053dbc50d6610b3e865cde65d
Reviewed-on: https://review.haiku-os.org/c/1096
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Gets the stage0 bootstrap to run.
Imlementation is probably nonsense at this point.
Change-Id: I10876efbb54314b864c0ad951152757cdb2fd366
Reviewed-on: https://review.haiku-os.org/c/1061
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Since NULL is not considered a user address anymore, we must check for
it first.
This fixes the "mount: Bad address" error after hrev52905.
Change-Id: If60ea58bb81b6c35c6bf27ecfa9b29bd7a25d8aa
This is technically only a functional change following the previous
commit, which unconditionally made sure the address was larger than
the base except for B_EXACT_ADDRESS. Essentially this makes sure
that if an address is passed which is smaller than the base is
passed in, it won't immediately fail just by being too small.
Checked against BeOS (0x0 passed to create_area with B_BASE_ADDRESS
succeeds, and returns 0x2000 consistently.) This is also needed
to not break userland initialization following the next commit.
VM86 was removed in 2012, so these are no longer needed.
The USER_BASE vs. USER_BASE_ANY distinction still seems like a
potentially useful one, though, so I've left all those changes in.
This reverts commit 58ed2965d0.
This reverts commit 055d49b1fd.
I was mistaken, it is perfectly legal to block a pinned thread.
It seems we'll need some other way to detect invalid context
switches.
int_io_* functions do not touch the thread state, but we already have
it here as we will modify its contents later, so it makes more sense
to set this flag here.
This is mostly only relevant following the previous commit, i.e.
finding interrupt handlers that brokenly try to context-switch.
Preventing "normal" context switches caused by a time interrupt
is the primary reason for pinning threads. "thread_block" and friends,
however, cause an explicit context switch and will not return until
another thread unblocks us.
Calling these while a thread is pinned is thus undefined behavior,
and so we should just panic in the case anyone attempts to do so.
The kernel version is only partially tested.
Change-Id: I9a2f6c78087154ab137eadbced99062a8a2dd688
Reviewed-on: https://review.haiku-os.org/c/918
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Private semaphores will have a key of -1, but IPC_PRIVATE is 0,
meaning it is possible to wind up here and get a NULL semaphoreSet
if someone passes us an argument of -1.
Reported on Twitter.
This didn't trigger any panics on my bare-metal dev install when tested,
but it might explain some easily-reproducible hardlocks (i.e. can't
even drop to KDL via emergency keys) I was seeing on other machines.
"are_interrupts_enabled()" is a "relatively" expensive function, so avoiding
it makes sense. This is the same way it's done elsewhere in sem.cpp, as well
as for mutexes and condition variables also.
The HashMap and HashSet classes are copied from userlandfs. The
HashMap one works as-is as it's already used in userlandfs; the
HashSet does not even compile yet.
Change-Id: I1deabb54deb3f289e266794ce618948b60be58c0
Reviewed-on: https://review.haiku-os.org/c/1041
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
I wasn't thinking correctly when I made the previous change --
init_term_dyn is compiled into all applications, and so these
functions need to remain in order to not break them.
No "real" functional change, but this causes GCC7 to throw errors when
these functions are declared without the image_id argument, which
in some files they were (as this commit repairs.)
This change is largely inconsequential on x86, but on callee-cleanup-args
targets, leaving out the argument would probably cause stack corruption.
It is only used as an argument to _kern_load_image directly, not to
any of the load_image functions in image.h, so it belongs in a syscall-
specific header like other such constants.
No functional change intended.
* Add a utility thread_check_permissions(), which takes the target
thread, the calling thread, and whether or not this is a "kernel" call,
and then returns whether the target thread may be legally modified.
* Refactor all calls that operate by sending a signal to the thread
into a single thread_send_signal() utility function, which now uses
thread_check_permissions() appropriately.
* Manually add the permissions checks to other functions as needed.
Solves a bunch of decade+-old TODOs.
* This iSCSI implementation only worked on PPC big-endian atm.
* We're pretty sure iSCSI support in haiku_loader doesn't make
much sense anymore. iPXE on (on arm,x86,etc EFI/BIOS platforms)
supports iSCSI boot of disks.
* Haiku could use a iSCSI driver add-on, but it would exist much
higher up and likely use standard drivers vs bare-minimum iSCSI
target impementations.
* Leaving TCP and adding to all arches since it could make sense
for haiku's native network disk subsystem or network debugging?
Change-Id: Ic181b93a1d8ffd77f69e00e372b44b79abbddb42
Reviewed-on: https://review.haiku-os.org/c/899
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Previously, static initializers were just in ".ctors", which was handled
by GCC's crtbeginS, and that was injected in-between crti and crtn. Now,
however, binutils puts static initializers into init_array/fini_array by
default, which runtime_loader handles, but of course as initialize_after and
terminate_after are supposed to be called *after* all static initializers
are called; and since runtime_loader called init_array after _init, they
were not.
Now, we get rid of the __haiku_init_before/etc. functions, and move their
functionality inside runtime_loader. This is a "soft" ABI breakage,
which is mitigated by adding another ABI breakage (runtime_loader now
returns NULL for the initialize_before/etc. symbols, as otherwise
old applications would have their initialize_before/etc. called twice;
once by runtime_loader, and then once by __haiku_init_before/etc.)
I don't see or know of any reason why an application would want to
get those symbols at runtime, though, so this shouldn't have any
adverse effects.
Change-Id: I42344c63f69c6f8ef260f6c3ca30202b6dfb153e
Reviewed-on: https://review.haiku-os.org/c/907
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Broadcast console output as syslog debug messages, stripped of trailing newlines.
Disabled by default.
Patch from #6168.
Change-Id: I1754381477dcde00bdcfa4482017daf5eb682cd3
Reviewed-on: https://review.haiku-os.org/c/912
Reviewed-by: Stephan Aßmus <superstippi@gmx.de>
Preserving the assert failure message in debug reports is desirable,
so if possible we should do so, not just print it to stderr. So
now we reuse the same trick from abort() directly.
Sorry for the extra noise; I should have combined these commits.
As per the POSIX specification.
This gives the calling program a chance to catch the assertion. But
in the case where no signal handler is installed for SIGABRT, we
will call debugger() anyway and present as a crash as before.
Fixes#10295.
The -Werror=uninitialized caught this, but I fixed it the wrong way
rather than looking at the code a little closer.
Should fix the strange bugs that cropped up after the first VFS patch.
**Lots** of syscalls here don't check if strlcpy truncated the user
supplied argument. This commit adds them where appropriate.
Closes#2642
Change-Id: Iff89055aeb3a1870c8baf327b60873ce85815cd7
Reviewed-on: https://review.haiku-os.org/c/890
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Implemented against POSIX-1.2013.
The implementation POSIX requirement thats setpriority() shall affect the
priority of all system scope threads only extends to POSIX threads. This
is implemented by modifying the default attributes for newly spawned
pthreads.
It is not possible to modify the default pthread attributes for different
processes with the current implementation, as default pthread attributes
are implemented in user-space. As a result, PRIO_PROCESS for which and 0
for who is the only supported combination for setpriority().
While it is possible to move the default attributes to the kernel, it
is chosen not to so as to keep the pthread implementation user-space only.
POSIX requires that lowering the nice value (increasing priority) can be
done only by processes with appropriate privileges. However, as Haiku
currently doesn't harbor any restrictions in setting the thread priority,
this is not implemented.
It is possible to have small precision errors when converting from Unix-
style thread priority to Be-style. For example, the following program
outputs "17" instead of the expected "18":
#include <stdio.h>
#include <sys/resource.h>
int
main()
{
setpriority(PRIO_PROCESS, 0, 18);
printf("%d\n", getpriority(PRIO_PROCESS, 0));
return 0;
}
The underlying reason is because when you setpriority() both 18 and 19
are converted to the Be-style "2". This problem should not happen with
priority levels lower than or equal to 20, when the Be notation is more
precise than the Unix-style.
Done as a part of GCI 2014. Fixes#2817.
Signed-off-by: Timothy Gu <timothygu99@gmail.com>
Co-authored-by: Leorize <leorize+oss@disroot.org>
Change-Id: Ie14f105b00fe8563d16b3562748e1c2e56c873a6
Reviewed-on: https://review.haiku-os.org/c/78
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
...rather than enumerating again. Solves a TODO (all filesystems
save tarfs and packagefs, which require special parameters and
of course will not be on standard "partitions", have implemented
the required function.)