This is a useful warning to have on, but keep it off for now since there
are a ton of warnings here, and probably in external projects that use
LK.
CLs incoming to fix the most egregious warning violations this uncovers.
The pendsv_ asm handler has been pushing 9 words on the stack prior to
calling into C code. This violates the ABI which requires 8 byte
alignment. It has worked mostly fine and thus hasn't been caught before.
Add an extra bump of the stack to align it after pushing the registers.
Release the thread lock before context switching to a thread that was
preempted and thus not holding the thread lock. Add a few asserts to
make sure this invariant is maintained in the context switch and PENDSV
handler.
This has never mattered before because the thread lock (and other
spinlocks) were not being tested for validity on by definition single
processor cortex-m systems. After adding some code to test the
spinlocks' values this discrepancy was uncovered.
SysTick_Config() tries to set the systick priority to max. Comment out
this line since arch/arm/arm-m/arch.c sets the priority to medium to
compete with the rest of the exceptions in the system.
Also include lk/compiler.h to avoid redundant cmsis macros.
arch_mmu_map was failing hard, because the identity mapping does not fall within the `vmm_get_kernel_aspace`
this creates a new aspace covering the loader, so it can identity map
linux is also unable to use the FPU if lazy FPU context switching had turned it off prior to the chainload, `arm_fpu_set_enable()` is used to turn it back on
Switch to a more proper matrix. Build each of the projects in a list
with DEBUG=0 and DEBUG=2 and with two versions of the toolchain (7.5.0
and 11.2.0).
Sets things up to be easier to run things like unit tests in a later
patch.
Previously if they couldn't find the toolchain they would full stop the
build. Change to print a warning and then go with the default prefix.
Hopefully this doesn't break anyone downstream but it's helpful for the
CI builder which wants to read from the build system which toolchain to
grab prior to having it in the path.
list-arch and list-toolchain will compute and print the architecture and
toolchain needed to build the project the build is set to.
Used by the CI builder to decide what toolchain to grab.
It seems to be in the case of a string op against a raw address, the
compiler decides the destination object is 0 bytes long and throws a
particular warning. Work around it by not using memcpy in one case and
by disabling the warning in the other.
Both are fairly benign code that basically operates in a hard coded way
that knows the destination buffer is valid.
This will allow in the future multiple instances of it to be active at
at a time. Place the current console in a new TLS slot per thread so
threads created as a side effect of console commands can properly run
commands.
The issue was found on AMD machine when run lk with qemu kvm, it
can't boot if kvm hardware is enable in qemu.
According to Intel system programming guild Chapter 4 "Paging",
if the page table entry is non-leaf entry, then the G bit will be
ignored.
However, According to AMD programmer mannul Volume 2, Chapter 5.3
"Long-Mode Page Translation", the non-leaf page table entry G bit
must be zero.
The patch sets inner page table entry G bit to zero so that it
works on both Intel and AMD CPU
Add build system support for at least being aware of the FPU on
the architecture, not building code to use it.
At the moment, only sets up the FPU into Initial state prior to
entering user space and then ignores it.
For user space support, the sscratch register cannot hold the pointer to
the current cpu, as much as it is convenient.
Change the logic to use tp register (x4) to point to percpu, and
dereference the local thread from it directly.
Create a user space address space, map some pages, query the pages,
context switch, to the new aspace, access the pages.
Basic test that the aspace abstraction is working.
Will generate errors on some of the arches that dont fully implement all
of this, but not a crash.
Kind of wasteful, but much simpler than having to manually sync every time something changes
in the kernel aspace. I think riscv machines with mmu can waste 1MB of page tables up front.
Can revisit later if needed.
When a crash is because of a BRK instruction, print that instead of
the default "unhandled synchronous exception".
Bug: 179516283
Change-Id: I9667d7157d24a79e2b2ceb7ef283ebc2b09398d0
Currently EXTRA_BUILDDEPS is evaluated before build.mk. This means that
userspace apps or other EXTRA_BUILDRULES cannot add items to
EXTRA_BUILDDEPS and have it function as would be expected.
Bug: 143636864
Change-Id: Idc1504b09f31b4c54148bb6892193d11f45e08ff
The compiler.h header defines two macros INCBIN and
INCFILE that can be used to include binary files
into C sources. This patch fixes a few issues with them:
* The .align directive is equivalent to .p2align
on some architectures (ARM/AArch64) and to .balign
on others (x86). INCBIN previously used .align and
now uses .balign for correct alignment.
* .align 1 enforces a 2-byte alignment on ARM/AArch64,
which caused the _end symbol for the binary to be off
by 1 byte in some cases, which the macro previously
accounted for (incorrectly). With the correct .balign
directive the extra byte is never added, so the size
is now correctly computed without the -1 addend.
* INCBIN should end in a .previous directive
to restore the previous section, since the macro
starts with .section.
Bug: 115420908
Change-Id: I2149e21d6f7157369a7b374a51af23933bff6b39
Up until now the bottom part of ram has been identity mapped, left over
from initial bootstrapping. Set up two top level page tables: one with the
the identity map and one without. Once the kernel starts switch to the second
but keep the former around for bootstrapping secondary cpus.
Start adding support for user address spaces, currently mostly untested.
Still have to solve the problem of keeping the kernel parts of the page tables
in sync. Will probably preallocate all of the ones needed.
Forgot to test at DEBUG=0. Both of these are basically cases where
the new DEBUG_ASSERT_COND should be used, since the default DEBUG_ASSERT
will now always emit code that gets cleaned up in the optimizer.
Pull some assert macro improvements back from zircon.
Added new variants that let you pass an arbitrary message.
Move most of the inner routine into a helper, makes for slightly
smaller codegen.
