* Add function core_dump_write_core_file(). It writes a core file for
the current thread's team. The file format is similar to that of
other OSs (i.e. ELF with PT_LOAD segments and a PT_NOTE segment), but
most of the notes are Haiku specific (infos for team, areas, images,
threads). More data will probably need to be added.
* Add team flag TEAM_FLAG_DUMP_CORE, thread flag
THREAD_FLAGS_TRAP_FOR_CORE_DUMP, and Team property coreDumpCondition,
a condition variable available while a core dump is progress. A
thread that finds its flag THREAD_FLAGS_TRAP_FOR_CORE_DUMP set before
exiting the kernel to userland calls core_dump_trap_thread(), which
blocks on the condition variable until the core dump has finished. We
need the team's threads to stop so we can get their CPU state (and
have a generally unchanging team state while writing the core file).
* Add user debugger message B_DEBUG_WRITE_CORE_FILE. It causes
core_dump_write_core_file() to be called for the team.
* Dumping core as an immediate effect of a terminal signal has not been
implemented yet, but that should be fairly straight forward.
Similar to arch_get_debug_cpu_state(), but the thread whose CPU state
to retrieve is specified. Works only for threads that aren't running,
and on x86-64 we can get the FPU state only when the thread was
interrupted in userland.
Not implemented for the incomplete architecture ports.
This resolves a TODO: We used thread_interrupt() to wake up the thread
from an interruptable wait. However, if the thread was already in the
kernel and about to start waiting, that would have no effect and the
thread would wait anyway. Now there's the new non-blockable signal
SIGNAL_DEBUG_THREAD, which is sent to the thread instead, making sure
that thread doesn't start waiting.
* New Intel SkyLake seems to have 9 mapped ranges
at boot. It seems like this define has been creeping
up for a while.
* Resolves the inital issue reported in #11377 on SkyLake
as well. Bonefish mentioned it might need to be raised
again... he had some good foresight there :-)
* I'm seeing the same no bootable partitions issue though
via USB after this raise. (maybe a USB 3.1 thing?)
* When a watched directory contains a mount point, we need to resolve
the actual parent directory of the mount point in the file system to
serve the monitor.
Reduce duplication of code by
* Removing from elf_common.h definitions available in os/kernel/elf.h
* Deleting elf32.h and elf64.h
* Renaming elf_common.h to elf_private.h
* Updating source to build using public and private ELF header files
together
Signed-off-by: Jessica Hamilton <jessica.l.hamilton@gmail.com>
* Each io_context now has a "inherit_fds" member that decides whether
or not this context allows to inherit FDs to its children.
* This replaces the former O_CLOEXEC mechanism.
* Instead of letting the kernel search for the syslog port, the
daemon now registers itself with the kernel (which even solves
a TODO).
* A port is created for the actual log messages from the launch_daemon,
and used on start.
* However, the SyslogTest does not yet work, due to the BMessage <->
KMessage communication problems.
* This enables a mechanism to profile almost the complete boot process
(starting with main2()), if SYSTEM_PROFILER is defined to 1.
* You can access the profiling data using "profile -r".
* Fixes sharing semantics, so non-shared semaphores in non-shared
memory do not become shared after a fork.
* Adds two new system calls: _user_mutex_sem_acquire/release(),
which reuse the user_mutex address-hashed wait mechanism.
* Named semaphores continue to use traditional sem_id semaphores.
The get_stack_trace syscall generates a stack trace using the kernel
debugging facilities and copies the resulting return address array to
the preallocated buffer from userland. It is only possible to get a
stack trace of the current thread.
The lookup_symbol syscall can be used to look up the symbol and image
name corresponding to an address. It can be used to resolve symbols
from a stack trace generated by the get_stack_trace syscall. Only
symbols of the current team can be looked up. Note that this uses
the symbol lookup of the kernel debugger which does not support lookup
of all symbols (static functions are missing for example).
This is meant to be used in situations where more elaborate stack trace
generation, like done in the userland debugging helpers, is not possible
due to constraints.
* drop my fdt tests
* we have to call fdt parsing code *after* cpu_init (why?)
* pass fdt pointer to all FDT support calls to avoid confusion
once we get into the kernel land
* look for PL011 compatible uart and use it
* Add some saftey checks to serial putc code to avoid null*
* fdt_node_check_compatible returns 0 on success not 1
* fdt_get_device_reg needs to add the SOC base to the result
* fdt_get_device_reg might need to add the second range cell
instead of reg?
* Move more code into fdt_support
* We now can query FDT registers based on name or alias
* Return addr_t where it makes sense
* Copyright change ok'ed by mmu_man
* Called via arm_mailbox_bcm2835 *and* arm_framebuffer_bcm2835
* This is a bit messy. We really should be getting these
chipset-centric bases from the provided FDT / DTB.
* I can't think of a way to redo this without undoing
work towards FDT.
* The Raspberry pi 2 uses a new SoC which differs slightly
from the Raspberry Pi 1.
* Someday these two board targets could go away when we get
FDT support.
* To while there was some compatibility between
BCM2708 and BCM2805, it makes the BCM2806 changes
more confusing. We don't have any valueable BCM2708
targets.
* offsetof is not allowed on non-POD types so we need to use
offset_of_member (gcc2 accepts offsetof, and C++11 relaxed the
constraints on where it is allowed so it should work there too)
* we have offset_of_member as a workaround until we switch to C++11,
move it from khash (which is soon to be removed) to list.h which is the
other place where it is used (for this one single call in our whole
codebase)
Also fix a typo in vfs.cpp.
CreateThreadEvent::DoDPC() missed a reference release to balance the
acquired reference before queuing the DPC, resulting in the
CreateThreadEvent objects being leaked.
This also removes the destructor that tried to cancel the DPC. Since
the class is reference counted and only destroyed when the DPC has
run and released the last reference, this didn't make much sense.
