genode/repos/base
Sebastian Sumpf 80cf47d906 ldso: protect object list with mutex
When we allowed symbol resolution during exceptions, we used the shared
object lock to protect ELF object list manipulation (e.g., dlopen,
dclose) when executing exception unwinding code in the linker.
Unfortunately, sometimes libraries that are loaded by 'dlopen' may raise
exceptions in the process, leading to a deadlock within the unwind code.
In order to resolve this, we now protect the object list operations
(i.e., enqueue, removal, iteration) by a separate mutex. This allows
the shared object interface to throw exceptions.

issue #4071
2021-04-20 12:10:58 +02:00
..
etc tools.conf: fix check for arm_64 2019-11-19 14:17:29 +01:00
include base/cache.h: rename Cache_attribute to Cache 2021-04-20 12:10:31 +02:00
lib base: Refine Range_allocator::alloc_aligned 2021-04-20 12:03:04 +02:00
mk build system: support for CUSTOM_TARGET_DEPS 2021-04-20 12:03:03 +02:00
ports grub2: avoid hardcoding boot disc 2020-06-29 14:22:28 +02:00
recipes depot: update recipe hashes 2021-03-12 12:08:24 +01:00
run platform_drv.inc: check board=pc not spec=x86 2021-02-23 12:02:43 +01:00
src ldso: protect object list with mutex 2021-04-20 12:10:58 +02:00
xsd base_types.xsd: allow session labels of length 0 2018-11-16 14:37:19 +01:00
README core: add information about infos provided by core 2017-06-29 11:59:52 +02:00

This is generic part of the Genode implementation. It consists of two parts:

:_Core_: is the ultimate root of the Genode application tree
  and provides abstractions for the lowest-level hardware resources
  such as RAM, ROM, CPU, and generic device access. All generic parts of Core
  can be found here - for system-specific implementations refer to the
  appropriate 'base-<system>' directory.

:_Base libraries and protocols_: that are used by each Genode component
  to interact with other components. This is the glue that holds everything
  together.

_Core_ may export information about the hardware platform by an ROM
called 'platform_info'. Depending on the platform, e.g. ARM or x86 or riscv,
and depending on the boot mode and boot loader and kernel, some nodes may not
be populated.

!<platform_info>
! <acpi revision="2" rsdt="0x1fe93074" xsdt="0x1fe930e8"/>
! <boot>
!   <framebuffer phys="0x7300000" width="1024" height="768" bpp="32"/>
! </boot>
!</platform_info>

If the ACPI RSDT and XSDT physical pointer is reported by the used kernel
and/or bootloader, _Core_ may provide this information by the ROM.

If the graphic device is initialised and can be directly used by a framebuffer
driver, _Core_ may provide the physical pointer to the framebuffer, the
resolution and color depth in bits.