- This file was added.
|* SPDX-License-Identifier: BSD-2-Clause|
|* Copyright (c) 2021 The FreeBSD Foundation|
@jhb this was derived from a header carrying a ECATS sponsorship note. The This software was developed by SRI International and the University of Cambridge Computer Laboratory statement seems confusing in this context, should we remove that?
emaste: @jhb this was derived from a header carrying a ECATS sponsorship note. The //This software was…
From crtbrand.S or the like? (Or maybe the firmware stub?) There's no useful shared content between those files and this. I would just give this a FF copyright from the get go.
jhb: From crtbrand.S or the like? (Or maybe the firmware stub?) There's no useful shared content…
From the firmware stub
emaste: From the firmware stub
The code was copied from firmware.S, and the only changes made were the variables rename. I did removed that copyright as suggested, but feel free to request a revert.
kib: The code was copied from firmware.S, and the only changes made were the variables rename. I…
|* This software was developed by Konstantin Belousov <kib@FreeBSD.org>|
|* under sponsorship from the FreeBSD Foundation.|
|* Redistribution and use in source and binary forms, with or without|
|* modification, are permitted provided that the following conditions|
|* are met:|
|* 1. Redistributions of source code must retain the above copyright|
|* notice, this list of conditions and the following disclaimer.|
|* 2. Redistributions in binary form must reproduce the above copyright|
|* notice, this list of conditions and the following disclaimer in the|
|* documentation and/or other materials provided with the distribution.|
|* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND|
|* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE|
|* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE|
|* ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE|
|* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL|
|* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS|
|* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)|
|* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT|
|* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY|
|* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF|
|* SUCH DAMAGE.|
|#define VDSO_BLOB_START(S) __CONCAT(_binary_, __CONCAT(S, _start))|
|#define VDSO_BLOB_END(S) __CONCAT(_binary_, __CONCAT(S, _end))|
|#define VDSO_BLOB_SIZE(S) __CONCAT(_binary_, __CONCAT(S, _size))|
No need for this if you aren't planning to merge to 12.
jhb: No need for this if you aren't planning to merge to 12.
|.section .rodata, "a", %progbits|
|.type VDSO_BLOB_START(VDSO_NAME), %object|
|.size VDSO_BLOB_START(VDSO_NAME), 0|
|.type VDSO_BLOB_END(VDSO_NAME), %object|
|.size VDSO_BLOB_END(VDSO_NAME), 0|
|.set VDSO_BLOB_SIZE(VDSO_NAME), . - VDSO_BLOB_START(VDSO_NAME)|
Can just make this a normal variable rather than the slightly gross "address is the size" approach that is mandated by objcopy (which doesn't work on RISC-V without -fPIE, and the same might be true for AArch64, due to using PC-relative addressing that assumes everything is +/- 1 GiB). Means the SV_DSO_SIG check when reading sv_szsigcode goes away and it can really be an extern int _binary_elf_vdso_so_1_size. Another benefit of the template asm approach that didn't occur to me.
jrtc27: Can just make this a normal variable rather than the slightly gross "address is the size"…
IMO the sigcodesz thing is gross, not the address as value. The later is the standard ELF way to get symbol value. I do not believe that PC-relative addressing is relevant there, all arches must be able to take address of something.
kib: IMO the sigcodesz thing is gross, not the address as value. The later is the standard ELF way…
The point is the code model explicitly assumes that code and data all fit into a 2GiB region, and thus a 32-bit PC-relative offset is sufficient to access any variable. Since the kernel is linked at a high address (but not high enough to be a small negative) and _binary_elf_vdso_so_1_size is between 0 and 2048, it is not within 2^32 bytes of PC, and thus you will get relocation out of range errors when linking on such architectures.
jrtc27: The point is the code model explicitly assumes that code and data all fit into a 2GiB region…
(Weak symbols are special cased to always use the GOT on AArch64 when building with such a code model, so that weak undef symbols can resolve to 0 and not cause range errors)
jrtc27: (Weak symbols are special cased to always use the GOT on AArch64 when building with such a code…
PC is irrelevant there. It is actually resolved at the static linking time, there is no code involved.
FWIW, amd64 is also linked with 'kernel memory model', where code is assumed to be in [TOP-2G, TOP) region (TOP=0xfffff...ffff). Are you sure that amd64 and riscv kernel models assume that both text _and_ data are in 2G region? It would be too limiting, I expect that only text has this micro-optimization restriction.
kib: PC is irrelevant there. It is actually resolved at the static linking time, there is no code…
Oh good point, I wasn't thinking about the fact that it's in a static initialiser so just a normal R_32/64 relocation.
Yes, that's the code model we compile with for AArch64 and RISC-V (linked at 0xffff000000000000 and 0xffffffc000000000 respectively, which are the lowest higher half addresses that are guaranteed to be supported by their MMUs), it covers both code and data and is the "normal" one that's not "assume everything is in the first 2 GiB". There is no kernel code model outside of x86. On AArch64 you get tiny (everything is within 1 MiB), small (everything is within 4 GiB, not sure why the GCC documentation sys 4, seems like it should be 2, but this is the default and the one I'm talking about) and large which is horribly inefficient (64-bit immediate materialisation everywhere). On RISC-V you get medlow (everything fits in a signed 32-bit integer) and medany (everything is within 2 GiB), there is currently no large (but -fPIC/-fPIE gets you a GOT which lets data grow beyond that, so long as text and the GOT can occupy a single 2 GiB region).
jrtc27: Oh good point, I wasn't thinking about the fact that it's in a static initialiser so just a…