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
This patch unifies the core-internal 'Mapping' type across all base
platforms.
As one minor downside on seL4, the diagnostic error messages when
observing faults other than page faults no longer print the faulting
thread and PD names.
Issue #2243
When the own cap quota of a client does not suffice for a cap upgrade of
an existing session to a server, the client must issue a cap-resource
request to the parent. This logic was already in place for RAM quota but
was missing for cap quota.
Issue #4072
When callback functions of `dl_iterate_phdr` required further jump slot
relocations this lead to a deadlock. Therefore, we allow the resolution
of further symbols from callback functions, but protect the ELF object
list during the iteration, which blocks any dynamic loading (e.g.,
dlopen/dlcose) of shared object by other threads while in program header
iteration.
fixes#4071
This patch changes the 'alloc_aligned' interface as follows:
- The former 'from' and 'to' arguments are replaced by a single
'range' argument.
- The distinction of the use cases of regular allocations vs.
address-constrained allocations is now overed by a dedicated
overload instead of relying on a default argument.
- The 'align' argument has been changed from 'int' to 'unsigned'
to be better compatible with 'addr_t' and 'size_t'.
Fixes#4067
The 'Timer::Session::trigger_periodic' RPC function used to accept 0 as
a way to de-schedule the periodic processing. Several components such as
nitpicker relied on this special case. In "timeout: rework timeout
framework", the value of zero was silently clamped to 1, which has the
opposite effect: triggering signals at the maximum rate. This results in
a visible effect in Sculpt where the leitzentrale-nitpicker instance
produces a constant load of 2% CPU time.
This patch restores the original timer semantics by
- Documenting it in timer_session.h,
- Handling the case explicitly in the timer implementation, and
- Replacing the silent clamping of the unexpected value 0 passed
to the timeout framework by a diagnostic error message.
Issue #3884
This patch fixes a corner case where a child is destructed while a
asynchronous close request to a sibling server is still pending.
The child immediately discarded the session ID as the end of the
close-session processing, assuming that this ID is never to be needed
again. The session-state continues to exist to handle asynchrous close
protocol with the server.
However, if the child is destructed at this point (before the server
responded to the session request), the destruction of the child would
not cover the discharging of the session state because the session state
was no longer be part of the client's ID space. So once the asynchronous
close response from the server came in, the session state contained
stale information, in particular a stale closed_callback pointer.
The patch fixes the problem by deferring the discarding of the client ID
to the point where the session state is actually destructed. So the
session of a pending close response is covered by the child destructor.
Thanks to Pirmin Duss for reporting this issue along with a test
scenario for reproducing it!
Fixes#4039
Do not link base and core libraries into on large relocatable .o file,
which is linked later to core - causing long link times. Create an
independent library archive out of the base and core libraries that can
be linked faster.
issue #4027
With this commit libcrypto does not use ARM NEON extension as long as
SPECS includes "neon". arm_v7a does declare "neon" per default while
arm_v8a does.
Issue #3773
- remove Spike/BBL support in favour of Qemu (>=4.2.1)
- add 'riscv_qemu' board, remove 'spike' board'
- update to privileged ISA v1.10 (from v1.9.1)
- use direct system calls for privileged core threads (they call into
the kernel and don't use mode changing system calls, i.e. 'ecall',
semantics)
- use 'OpenSBI' semtantics for SBI calls (to machine mode) instead of
BBL
issue #4012
By first removing unused ranges, implicitly meta data allocations are freed
up. This leads to more unused slab blocks and freed up meta data allocations
in the avl tree.
Issue #4014
Even though the binary patching of ldso must be performed only once,
this postprocessing step was executed on each run because the
postprocess.tag rule is phony (the tag file is never created).
This patch removes this phony behavior by creating the tag file.
Issue #3974
The code in base-hw/src/bootstrap/platform.cc uses segment flags for
identification purposes. Based on this information the code decides
what to do with each segment. Unfortunately the linker script does
not actually ensure the flags for a specific named segment match
expectations. The code relies on implicit linker behaviour.
This implicit behaviour can vary between linkers. This breaks
arm_v7a base-hw builds linked with LLVM's lld linker. The segment
named "ro" ends up having writeable flag set when using LLD.
This patch ensures that all ELF segments in genode.ld have their
required perimssion flags set explicitly.
Fixes#3988
Clang is generally fine with Genode::List and compiles code using it
without emitting any warnings. There is however one exception. Clang
fails hard when building base-hw/src/core/kernel/object.cc.
This is due to a call to Genode::List::remove made from
Object_identity::invalidate function. The error message clang
produces is:
list.h:96:33: error: 'Genode::List<Kernel::Object_identity_reference>::Element::_next'
is not a member of class 'const Kernel::Object_identity'
_first = le->List::Element::_next;
~~~~~~~~~~~~~~~^
When we look at the declaration of the Kernel::Object class on which
the remove method is called. as expected it does inherit Genode::List:
using Object_identity_list
= Genode::List<Kernel::Object_identity>;
class Kernel::Object : private Object_identity_list
{
...
}
Given the error message we see that List::Element should be resolved to
Genode::List<Kernel::Object_identity>::Element, and not
Genode::List<Kernel::Object_identity_reference>::Element. But how does
clang manage to figure out we're talking about Object_identity_refecence
list here? Well, I admit I don't know the exact steps it takes to arrive
at this conclusion, but it is not entirely wrong. If we take a look at
what Kernel::Object_identity is we'll see:
class Kernel::Object_identity
: public Object_identity_list::Element,
public Kernel::Object_identity_reference_list
{
...
}
Where as one can guess Object_identity_reference_list is defined as:
using Object_identity_reference_list
= Genode::List<Object_identity_reference>;
Long story short Kernel::Object has Genode::List of both Kernel::Object_identity
and Kernel::Object_identity_reference in its inheritance chain and clang
is not really sure to which of those the code refers to in
Genode::List::remove method by using List::Element::.
The fix for this is relatively simple, explicitly state the full type of
the base class the code intends to refer to. Replacing List::Element,
with List<LT>::Element makes the code buildable with both clang and GCC.
Fixes#3990
* Remove SPEC declarations from mk/spec
* Remove all board-specific REQUIRE declaratiions left
* Replace [have_spec <board>] run-script declarations with have_board where necessary
* Remove addition of BOARD variable to SPECS in toplevel Makefile
* Move board-specific directories in base-hw out of specs
