d/freebsd-dev
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
0d5af38ceb
freebsd-dev/sys/contrib/cloudabi/cloudabi_vdso_armv6.S

406 lines
7.3 KiB
ArmAsm
Raw Normal View History

Add very preliminary support for CloudABI for ARMv6. In order to make CloudABI work on ARMv6, start off by copying over the sysvec for ARM64 and adjust it to use 32-bit registers. Also add code for fetching arguments from the stack if needed, as there are fewer register than on ARM64. Also import the vDSO that is needed to invoke system calls. This vDSO uses the intra procedure call register (ip) to store the system call number. This is a bit simpler than what native FreeBSD does, as FreeBSD uses r7, while preserving the original r7 into ip. This sysvec seems to be complete enough to start CloudABI processes. These processes are capable of linking in the vDSO and are therefore capable of executing (most?) system calls successfully. Unfortunately, the biggest show stopper is still that TLS is completely broken: - The linker used by CloudABI, LLD, still has troubles with some of the relocations needed for TLS. See LLVM bug 30218 for more details. - Whereas FreeBSD uses the tpidruro register for TLS, for CloudABI I want to make use of tpidrurw, so that userspace can modify the base address directly. This is needed for efficient emulation. Unfortunately, this register doesn't seem to be preserved across context switches yet. Obtained from: https://github.com/NuxiNL/cloudabi (the vDSO)
2016-09-18 11:36:54 +00:00
// Copyright (c) 2016 Nuxi (https://nuxi.nl/) and contributors.
//
// 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.
//
// This file is automatically generated. Do not edit.
//
// Source: https://github.com/NuxiNL/cloudabi
#define ENTRY(name) \
.text; \
.p2align 2; \
.global name; \
.type name, %function; \
name:
#define END(name) .size name, . - name
ENTRY(cloudabi_sys_clock_res_get)
str r1, [sp, #-4]
mov ip, #0
swi 0
Sync in latest vDSOs from upstream. - Use conditional instruction to simplify the ARMv6 vDSO. This means that we no longer perform any branching. In the failure case, we simply slide over the assignments of the return values. The vDSO could be improved even further by using stmia to do assignments in parallel. Unfortunately, the script used to generate these is not smart enough for that (yet). Spotted by: andrew@. - Make the style of the i686 vDSO more similar to the others by using decimal literals.
2016-09-19 17:31:05 +00:00
ldrcc r2, [sp, #-4]
strcc r0, [r2, 0]
strcc r1, [r2, 4]
movcc r0, $0
Add very preliminary support for CloudABI for ARMv6. In order to make CloudABI work on ARMv6, start off by copying over the sysvec for ARM64 and adjust it to use 32-bit registers. Also add code for fetching arguments from the stack if needed, as there are fewer register than on ARM64. Also import the vDSO that is needed to invoke system calls. This vDSO uses the intra procedure call register (ip) to store the system call number. This is a bit simpler than what native FreeBSD does, as FreeBSD uses r7, while preserving the original r7 into ip. This sysvec seems to be complete enough to start CloudABI processes. These processes are capable of linking in the vDSO and are therefore capable of executing (most?) system calls successfully. Unfortunately, the biggest show stopper is still that TLS is completely broken: - The linker used by CloudABI, LLD, still has troubles with some of the relocations needed for TLS. See LLVM bug 30218 for more details. - Whereas FreeBSD uses the tpidruro register for TLS, for CloudABI I want to make use of tpidrurw, so that userspace can modify the base address directly. This is needed for efficient emulation. Unfortunately, this register doesn't seem to be preserved across context switches yet. Obtained from: https://github.com/NuxiNL/cloudabi (the vDSO)
2016-09-18 11:36:54 +00:00
bx lr
END(cloudabi_sys_clock_res_get)
ENTRY(cloudabi_sys_clock_time_get)
mov ip, #1
swi 0
Sync in latest vDSOs from upstream. - Use conditional instruction to simplify the ARMv6 vDSO. This means that we no longer perform any branching. In the failure case, we simply slide over the assignments of the return values. The vDSO could be improved even further by using stmia to do assignments in parallel. Unfortunately, the script used to generate these is not smart enough for that (yet). Spotted by: andrew@. - Make the style of the i686 vDSO more similar to the others by using decimal literals.
2016-09-19 17:31:05 +00:00
ldrcc r2, [sp, #0]
strcc r0, [r2, 0]
strcc r1, [r2, 4]
movcc r0, $0
Add very preliminary support for CloudABI for ARMv6. In order to make CloudABI work on ARMv6, start off by copying over the sysvec for ARM64 and adjust it to use 32-bit registers. Also add code for fetching arguments from the stack if needed, as there are fewer register than on ARM64. Also import the vDSO that is needed to invoke system calls. This vDSO uses the intra procedure call register (ip) to store the system call number. This is a bit simpler than what native FreeBSD does, as FreeBSD uses r7, while preserving the original r7 into ip. This sysvec seems to be complete enough to start CloudABI processes. These processes are capable of linking in the vDSO and are therefore capable of executing (most?) system calls successfully. Unfortunately, the biggest show stopper is still that TLS is completely broken: - The linker used by CloudABI, LLD, still has troubles with some of the relocations needed for TLS. See LLVM bug 30218 for more details. - Whereas FreeBSD uses the tpidruro register for TLS, for CloudABI I want to make use of tpidrurw, so that userspace can modify the base address directly. This is needed for efficient emulation. Unfortunately, this register doesn't seem to be preserved across context switches yet. Obtained from: https://github.com/NuxiNL/cloudabi (the vDSO)
2016-09-18 11:36:54 +00:00
bx lr
END(cloudabi_sys_clock_time_get)
ENTRY(cloudabi_sys_condvar_signal)
mov ip, #2
swi 0
bx lr
END(cloudabi_sys_condvar_signal)
ENTRY(cloudabi_sys_fd_close)
mov ip, #3
swi 0
bx lr
END(cloudabi_sys_fd_close)
ENTRY(cloudabi_sys_fd_create1)
str r1, [sp, #-4]
mov ip, #4
swi 0
Sync in latest vDSOs from upstream. - Use conditional instruction to simplify the ARMv6 vDSO. This means that we no longer perform any branching. In the failure case, we simply slide over the assignments of the return values. The vDSO could be improved even further by using stmia to do assignments in parallel. Unfortunately, the script used to generate these is not smart enough for that (yet). Spotted by: andrew@. - Make the style of the i686 vDSO more similar to the others by using decimal literals.
2016-09-19 17:31:05 +00:00
ldrcc r2, [sp, #-4]
strcc r0, [r2]
movcc r0, $0
Add very preliminary support for CloudABI for ARMv6. In order to make CloudABI work on ARMv6, start off by copying over the sysvec for ARM64 and adjust it to use 32-bit registers. Also add code for fetching arguments from the stack if needed, as there are fewer register than on ARM64. Also import the vDSO that is needed to invoke system calls. This vDSO uses the intra procedure call register (ip) to store the system call number. This is a bit simpler than what native FreeBSD does, as FreeBSD uses r7, while preserving the original r7 into ip. This sysvec seems to be complete enough to start CloudABI processes. These processes are capable of linking in the vDSO and are therefore capable of executing (most?) system calls successfully. Unfortunately, the biggest show stopper is still that TLS is completely broken: - The linker used by CloudABI, LLD, still has troubles with some of the relocations needed for TLS. See LLVM bug 30218 for more details. - Whereas FreeBSD uses the tpidruro register for TLS, for CloudABI I want to make use of tpidrurw, so that userspace can modify the base address directly. This is needed for efficient emulation. Unfortunately, this register doesn't seem to be preserved across context switches yet. Obtained from: https://github.com/NuxiNL/cloudabi (the vDSO)
2016-09-18 11:36:54 +00:00
bx lr
END(cloudabi_sys_fd_create1)
ENTRY(cloudabi_sys_fd_create2)
str r1, [sp, #-4]
str r2, [sp, #-8]
mov ip, #5
swi 0
Sync in latest vDSOs from upstream. - Use conditional instruction to simplify the ARMv6 vDSO. This means that we no longer perform any branching. In the failure case, we simply slide over the assignments of the return values. The vDSO could be improved even further by using stmia to do assignments in parallel. Unfortunately, the script used to generate these is not smart enough for that (yet). Spotted by: andrew@. - Make the style of the i686 vDSO more similar to the others by using decimal literals.
2016-09-19 17:31:05 +00:00
ldrcc r2, [sp, #-4]
ldrcc r3, [sp, #-8]
strcc r0, [r2]
strcc r1, [r3]
movcc r0, $0
Add very preliminary support for CloudABI for ARMv6. In order to make CloudABI work on ARMv6, start off by copying over the sysvec for ARM64 and adjust it to use 32-bit registers. Also add code for fetching arguments from the stack if needed, as there are fewer register than on ARM64. Also import the vDSO that is needed to invoke system calls. This vDSO uses the intra procedure call register (ip) to store the system call number. This is a bit simpler than what native FreeBSD does, as FreeBSD uses r7, while preserving the original r7 into ip. This sysvec seems to be complete enough to start CloudABI processes. These processes are capable of linking in the vDSO and are therefore capable of executing (most?) system calls successfully. Unfortunately, the biggest show stopper is still that TLS is completely broken: - The linker used by CloudABI, LLD, still has troubles with some of the relocations needed for TLS. See LLVM bug 30218 for more details. - Whereas FreeBSD uses the tpidruro register for TLS, for CloudABI I want to make use of tpidrurw, so that userspace can modify the base address directly. This is needed for efficient emulation. Unfortunately, this register doesn't seem to be preserved across context switches yet. Obtained from: https://github.com/NuxiNL/cloudabi (the vDSO)
2016-09-18 11:36:54 +00:00
bx lr
END(cloudabi_sys_fd_create2)
ENTRY(cloudabi_sys_fd_datasync)
mov ip, #6
swi 0
bx lr
END(cloudabi_sys_fd_datasync)
ENTRY(cloudabi_sys_fd_dup)
str r1, [sp, #-4]
mov ip, #7
swi 0
Sync in latest vDSOs from upstream. - Use conditional instruction to simplify the ARMv6 vDSO. This means that we no longer perform any branching. In the failure case, we simply slide over the assignments of the return values. The vDSO could be improved even further by using stmia to do assignments in parallel. Unfortunately, the script used to generate these is not smart enough for that (yet). Spotted by: andrew@. - Make the style of the i686 vDSO more similar to the others by using decimal literals.
2016-09-19 17:31:05 +00:00
ldrcc r2, [sp, #-4]
strcc r0, [r2]
movcc r0, $0
Add very preliminary support for CloudABI for ARMv6. In order to make CloudABI work on ARMv6, start off by copying over the sysvec for ARM64 and adjust it to use 32-bit registers. Also add code for fetching arguments from the stack if needed, as there are fewer register than on ARM64. Also import the vDSO that is needed to invoke system calls. This vDSO uses the intra procedure call register (ip) to store the system call number. This is a bit simpler than what native FreeBSD does, as FreeBSD uses r7, while preserving the original r7 into ip. This sysvec seems to be complete enough to start CloudABI processes. These processes are capable of linking in the vDSO and are therefore capable of executing (most?) system calls successfully. Unfortunately, the biggest show stopper is still that TLS is completely broken: - The linker used by CloudABI, LLD, still has troubles with some of the relocations needed for TLS. See LLVM bug 30218 for more details. - Whereas FreeBSD uses the tpidruro register for TLS, for CloudABI I want to make use of tpidrurw, so that userspace can modify the base address directly. This is needed for efficient emulation. Unfortunately, this register doesn't seem to be preserved across context switches yet. Obtained from: https://github.com/NuxiNL/cloudabi (the vDSO)
2016-09-18 11:36:54 +00:00
bx lr
END(cloudabi_sys_fd_dup)
ENTRY(cloudabi_sys_fd_pread)
mov ip, #8
swi 0
Sync in latest vDSOs from upstream. - Use conditional instruction to simplify the ARMv6 vDSO. This means that we no longer perform any branching. In the failure case, we simply slide over the assignments of the return values. The vDSO could be improved even further by using stmia to do assignments in parallel. Unfortunately, the script used to generate these is not smart enough for that (yet). Spotted by: andrew@. - Make the style of the i686 vDSO more similar to the others by using decimal literals.
2016-09-19 17:31:05 +00:00
ldrcc r2, [sp, #8]
strcc r0, [r2]
movcc r0, $0
Add very preliminary support for CloudABI for ARMv6. In order to make CloudABI work on ARMv6, start off by copying over the sysvec for ARM64 and adjust it to use 32-bit registers. Also add code for fetching arguments from the stack if needed, as there are fewer register than on ARM64. Also import the vDSO that is needed to invoke system calls. This vDSO uses the intra procedure call register (ip) to store the system call number. This is a bit simpler than what native FreeBSD does, as FreeBSD uses r7, while preserving the original r7 into ip. This sysvec seems to be complete enough to start CloudABI processes. These processes are capable of linking in the vDSO and are therefore capable of executing (most?) system calls successfully. Unfortunately, the biggest show stopper is still that TLS is completely broken: - The linker used by CloudABI, LLD, still has troubles with some of the relocations needed for TLS. See LLVM bug 30218 for more details. - Whereas FreeBSD uses the tpidruro register for TLS, for CloudABI I want to make use of tpidrurw, so that userspace can modify the base address directly. This is needed for efficient emulation. Unfortunately, this register doesn't seem to be preserved across context switches yet. Obtained from: https://github.com/NuxiNL/cloudabi (the vDSO)
2016-09-18 11:36:54 +00:00
bx lr
END(cloudabi_sys_fd_pread)
ENTRY(cloudabi_sys_fd_pwrite)
mov ip, #9
swi 0
Sync in latest vDSOs from upstream. - Use conditional instruction to simplify the ARMv6 vDSO. This means that we no longer perform any branching. In the failure case, we simply slide over the assignments of the return values. The vDSO could be improved even further by using stmia to do assignments in parallel. Unfortunately, the script used to generate these is not smart enough for that (yet). Spotted by: andrew@. - Make the style of the i686 vDSO more similar to the others by using decimal literals.
2016-09-19 17:31:05 +00:00
ldrcc r2, [sp, #8]
strcc r0, [r2]
movcc r0, $0
Add very preliminary support for CloudABI for ARMv6. In order to make CloudABI work on ARMv6, start off by copying over the sysvec for ARM64 and adjust it to use 32-bit registers. Also add code for fetching arguments from the stack if needed, as there are fewer register than on ARM64. Also import the vDSO that is needed to invoke system calls. This vDSO uses the intra procedure call register (ip) to store the system call number. This is a bit simpler than what native FreeBSD does, as FreeBSD uses r7, while preserving the original r7 into ip. This sysvec seems to be complete enough to start CloudABI processes. These processes are capable of linking in the vDSO and are therefore capable of executing (most?) system calls successfully. Unfortunately, the biggest show stopper is still that TLS is completely broken: - The linker used by CloudABI, LLD, still has troubles with some of the relocations needed for TLS. See LLVM bug 30218 for more details. - Whereas FreeBSD uses the tpidruro register for TLS, for CloudABI I want to make use of tpidrurw, so that userspace can modify the base address directly. This is needed for efficient emulation. Unfortunately, this register doesn't seem to be preserved across context switches yet. Obtained from: https://github.com/NuxiNL/cloudabi (the vDSO)
2016-09-18 11:36:54 +00:00
bx lr
END(cloudabi_sys_fd_pwrite)
ENTRY(cloudabi_sys_fd_read)
str r3, [sp, #-4]
mov ip, #10
swi 0
Sync in latest vDSOs from upstream. - Use conditional instruction to simplify the ARMv6 vDSO. This means that we no longer perform any branching. In the failure case, we simply slide over the assignments of the return values. The vDSO could be improved even further by using stmia to do assignments in parallel. Unfortunately, the script used to generate these is not smart enough for that (yet). Spotted by: andrew@. - Make the style of the i686 vDSO more similar to the others by using decimal literals.
2016-09-19 17:31:05 +00:00
ldrcc r2, [sp, #-4]
strcc r0, [r2]
movcc r0, $0
Add very preliminary support for CloudABI for ARMv6. In order to make CloudABI work on ARMv6, start off by copying over the sysvec for ARM64 and adjust it to use 32-bit registers. Also add code for fetching arguments from the stack if needed, as there are fewer register than on ARM64. Also import the vDSO that is needed to invoke system calls. This vDSO uses the intra procedure call register (ip) to store the system call number. This is a bit simpler than what native FreeBSD does, as FreeBSD uses r7, while preserving the original r7 into ip. This sysvec seems to be complete enough to start CloudABI processes. These processes are capable of linking in the vDSO and are therefore capable of executing (most?) system calls successfully. Unfortunately, the biggest show stopper is still that TLS is completely broken: - The linker used by CloudABI, LLD, still has troubles with some of the relocations needed for TLS. See LLVM bug 30218 for more details. - Whereas FreeBSD uses the tpidruro register for TLS, for CloudABI I want to make use of tpidrurw, so that userspace can modify the base address directly. This is needed for efficient emulation. Unfortunately, this register doesn't seem to be preserved across context switches yet. Obtained from: https://github.com/NuxiNL/cloudabi (the vDSO)
2016-09-18 11:36:54 +00:00
bx lr
END(cloudabi_sys_fd_read)
ENTRY(cloudabi_sys_fd_replace)
mov ip, #11
swi 0
bx lr
END(cloudabi_sys_fd_replace)
ENTRY(cloudabi_sys_fd_seek)
mov ip, #12
swi 0
Sync in latest vDSOs from upstream. - Use conditional instruction to simplify the ARMv6 vDSO. This means that we no longer perform any branching. In the failure case, we simply slide over the assignments of the return values. The vDSO could be improved even further by using stmia to do assignments in parallel. Unfortunately, the script used to generate these is not smart enough for that (yet). Spotted by: andrew@. - Make the style of the i686 vDSO more similar to the others by using decimal literals.
2016-09-19 17:31:05 +00:00
ldrcc r2, [sp, #4]
strcc r0, [r2, 0]
strcc r1, [r2, 4]
movcc r0, $0
Add very preliminary support for CloudABI for ARMv6. In order to make CloudABI work on ARMv6, start off by copying over the sysvec for ARM64 and adjust it to use 32-bit registers. Also add code for fetching arguments from the stack if needed, as there are fewer register than on ARM64. Also import the vDSO that is needed to invoke system calls. This vDSO uses the intra procedure call register (ip) to store the system call number. This is a bit simpler than what native FreeBSD does, as FreeBSD uses r7, while preserving the original r7 into ip. This sysvec seems to be complete enough to start CloudABI processes. These processes are capable of linking in the vDSO and are therefore capable of executing (most?) system calls successfully. Unfortunately, the biggest show stopper is still that TLS is completely broken: - The linker used by CloudABI, LLD, still has troubles with some of the relocations needed for TLS. See LLVM bug 30218 for more details. - Whereas FreeBSD uses the tpidruro register for TLS, for CloudABI I want to make use of tpidrurw, so that userspace can modify the base address directly. This is needed for efficient emulation. Unfortunately, this register doesn't seem to be preserved across context switches yet. Obtained from: https://github.com/NuxiNL/cloudabi (the vDSO)
2016-09-18 11:36:54 +00:00
bx lr
END(cloudabi_sys_fd_seek)
ENTRY(cloudabi_sys_fd_stat_get)
mov ip, #13
swi 0
bx lr
END(cloudabi_sys_fd_stat_get)
ENTRY(cloudabi_sys_fd_stat_put)
mov ip, #14
swi 0
bx lr
END(cloudabi_sys_fd_stat_put)
ENTRY(cloudabi_sys_fd_sync)
mov ip, #15
swi 0
bx lr
END(cloudabi_sys_fd_sync)
ENTRY(cloudabi_sys_fd_write)
str r3, [sp, #-4]
mov ip, #16
swi 0
Sync in latest vDSOs from upstream. - Use conditional instruction to simplify the ARMv6 vDSO. This means that we no longer perform any branching. In the failure case, we simply slide over the assignments of the return values. The vDSO could be improved even further by using stmia to do assignments in parallel. Unfortunately, the script used to generate these is not smart enough for that (yet). Spotted by: andrew@. - Make the style of the i686 vDSO more similar to the others by using decimal literals.
2016-09-19 17:31:05 +00:00
ldrcc r2, [sp, #-4]
strcc r0, [r2]
movcc r0, $0
Add very preliminary support for CloudABI for ARMv6. In order to make CloudABI work on ARMv6, start off by copying over the sysvec for ARM64 and adjust it to use 32-bit registers. Also add code for fetching arguments from the stack if needed, as there are fewer register than on ARM64. Also import the vDSO that is needed to invoke system calls. This vDSO uses the intra procedure call register (ip) to store the system call number. This is a bit simpler than what native FreeBSD does, as FreeBSD uses r7, while preserving the original r7 into ip. This sysvec seems to be complete enough to start CloudABI processes. These processes are capable of linking in the vDSO and are therefore capable of executing (most?) system calls successfully. Unfortunately, the biggest show stopper is still that TLS is completely broken: - The linker used by CloudABI, LLD, still has troubles with some of the relocations needed for TLS. See LLVM bug 30218 for more details. - Whereas FreeBSD uses the tpidruro register for TLS, for CloudABI I want to make use of tpidrurw, so that userspace can modify the base address directly. This is needed for efficient emulation. Unfortunately, this register doesn't seem to be preserved across context switches yet. Obtained from: https://github.com/NuxiNL/cloudabi (the vDSO)
2016-09-18 11:36:54 +00:00
bx lr
END(cloudabi_sys_fd_write)
ENTRY(cloudabi_sys_file_advise)
mov ip, #17
swi 0
bx lr
END(cloudabi_sys_file_advise)
ENTRY(cloudabi_sys_file_allocate)
mov ip, #18
swi 0
bx lr
END(cloudabi_sys_file_allocate)
ENTRY(cloudabi_sys_file_create)
mov ip, #19
swi 0
bx lr
END(cloudabi_sys_file_create)
ENTRY(cloudabi_sys_file_link)
mov ip, #20
swi 0
bx lr
END(cloudabi_sys_file_link)
ENTRY(cloudabi_sys_file_open)
mov ip, #21
swi 0
Sync in latest vDSOs from upstream. - Use conditional instruction to simplify the ARMv6 vDSO. This means that we no longer perform any branching. In the failure case, we simply slide over the assignments of the return values. The vDSO could be improved even further by using stmia to do assignments in parallel. Unfortunately, the script used to generate these is not smart enough for that (yet). Spotted by: andrew@. - Make the style of the i686 vDSO more similar to the others by using decimal literals.
2016-09-19 17:31:05 +00:00
ldrcc r2, [sp, #8]
strcc r0, [r2]
movcc r0, $0
Add very preliminary support for CloudABI for ARMv6. In order to make CloudABI work on ARMv6, start off by copying over the sysvec for ARM64 and adjust it to use 32-bit registers. Also add code for fetching arguments from the stack if needed, as there are fewer register than on ARM64. Also import the vDSO that is needed to invoke system calls. This vDSO uses the intra procedure call register (ip) to store the system call number. This is a bit simpler than what native FreeBSD does, as FreeBSD uses r7, while preserving the original r7 into ip. This sysvec seems to be complete enough to start CloudABI processes. These processes are capable of linking in the vDSO and are therefore capable of executing (most?) system calls successfully. Unfortunately, the biggest show stopper is still that TLS is completely broken: - The linker used by CloudABI, LLD, still has troubles with some of the relocations needed for TLS. See LLVM bug 30218 for more details. - Whereas FreeBSD uses the tpidruro register for TLS, for CloudABI I want to make use of tpidrurw, so that userspace can modify the base address directly. This is needed for efficient emulation. Unfortunately, this register doesn't seem to be preserved across context switches yet. Obtained from: https://github.com/NuxiNL/cloudabi (the vDSO)
2016-09-18 11:36:54 +00:00
bx lr
END(cloudabi_sys_file_open)
ENTRY(cloudabi_sys_file_readdir)
mov ip, #22
swi 0
Sync in latest vDSOs from upstream. - Use conditional instruction to simplify the ARMv6 vDSO. This means that we no longer perform any branching. In the failure case, we simply slide over the assignments of the return values. The vDSO could be improved even further by using stmia to do assignments in parallel. Unfortunately, the script used to generate these is not smart enough for that (yet). Spotted by: andrew@. - Make the style of the i686 vDSO more similar to the others by using decimal literals.
2016-09-19 17:31:05 +00:00
ldrcc r2, [sp, #8]
strcc r0, [r2]
movcc r0, $0
Add very preliminary support for CloudABI for ARMv6. In order to make CloudABI work on ARMv6, start off by copying over the sysvec for ARM64 and adjust it to use 32-bit registers. Also add code for fetching arguments from the stack if needed, as there are fewer register than on ARM64. Also import the vDSO that is needed to invoke system calls. This vDSO uses the intra procedure call register (ip) to store the system call number. This is a bit simpler than what native FreeBSD does, as FreeBSD uses r7, while preserving the original r7 into ip. This sysvec seems to be complete enough to start CloudABI processes. These processes are capable of linking in the vDSO and are therefore capable of executing (most?) system calls successfully. Unfortunately, the biggest show stopper is still that TLS is completely broken: - The linker used by CloudABI, LLD, still has troubles with some of the relocations needed for TLS. See LLVM bug 30218 for more details. - Whereas FreeBSD uses the tpidruro register for TLS, for CloudABI I want to make use of tpidrurw, so that userspace can modify the base address directly. This is needed for efficient emulation. Unfortunately, this register doesn't seem to be preserved across context switches yet. Obtained from: https://github.com/NuxiNL/cloudabi (the vDSO)
2016-09-18 11:36:54 +00:00
bx lr
END(cloudabi_sys_file_readdir)
ENTRY(cloudabi_sys_file_readlink)
mov ip, #23
swi 0
Sync in latest vDSOs from upstream. - Use conditional instruction to simplify the ARMv6 vDSO. This means that we no longer perform any branching. In the failure case, we simply slide over the assignments of the return values. The vDSO could be improved even further by using stmia to do assignments in parallel. Unfortunately, the script used to generate these is not smart enough for that (yet). Spotted by: andrew@. - Make the style of the i686 vDSO more similar to the others by using decimal literals.
2016-09-19 17:31:05 +00:00
ldrcc r2, [sp, #4]
strcc r0, [r2]
movcc r0, $0
Add very preliminary support for CloudABI for ARMv6. In order to make CloudABI work on ARMv6, start off by copying over the sysvec for ARM64 and adjust it to use 32-bit registers. Also add code for fetching arguments from the stack if needed, as there are fewer register than on ARM64. Also import the vDSO that is needed to invoke system calls. This vDSO uses the intra procedure call register (ip) to store the system call number. This is a bit simpler than what native FreeBSD does, as FreeBSD uses r7, while preserving the original r7 into ip. This sysvec seems to be complete enough to start CloudABI processes. These processes are capable of linking in the vDSO and are therefore capable of executing (most?) system calls successfully. Unfortunately, the biggest show stopper is still that TLS is completely broken: - The linker used by CloudABI, LLD, still has troubles with some of the relocations needed for TLS. See LLVM bug 30218 for more details. - Whereas FreeBSD uses the tpidruro register for TLS, for CloudABI I want to make use of tpidrurw, so that userspace can modify the base address directly. This is needed for efficient emulation. Unfortunately, this register doesn't seem to be preserved across context switches yet. Obtained from: https://github.com/NuxiNL/cloudabi (the vDSO)
2016-09-18 11:36:54 +00:00
bx lr
END(cloudabi_sys_file_readlink)
ENTRY(cloudabi_sys_file_rename)
mov ip, #24
swi 0
bx lr
END(cloudabi_sys_file_rename)
ENTRY(cloudabi_sys_file_stat_fget)
mov ip, #25
swi 0
bx lr
END(cloudabi_sys_file_stat_fget)
ENTRY(cloudabi_sys_file_stat_fput)
mov ip, #26
swi 0
bx lr
END(cloudabi_sys_file_stat_fput)
ENTRY(cloudabi_sys_file_stat_get)
mov ip, #27
swi 0
bx lr
END(cloudabi_sys_file_stat_get)
ENTRY(cloudabi_sys_file_stat_put)
mov ip, #28
swi 0
bx lr
END(cloudabi_sys_file_stat_put)
ENTRY(cloudabi_sys_file_symlink)
mov ip, #29
swi 0
bx lr
END(cloudabi_sys_file_symlink)
ENTRY(cloudabi_sys_file_unlink)
mov ip, #30
swi 0
bx lr
END(cloudabi_sys_file_unlink)
ENTRY(cloudabi_sys_lock_unlock)
mov ip, #31
swi 0
bx lr
END(cloudabi_sys_lock_unlock)
ENTRY(cloudabi_sys_mem_advise)
mov ip, #32
swi 0
bx lr
END(cloudabi_sys_mem_advise)
ENTRY(cloudabi_sys_mem_map)
Upgrade to the latest sources generated from the CloudABI specification. The CloudABI specification has had some minor changes over the last half year. No substantial features have been added, but some features that are deemed unnecessary in retrospect have been removed: - mlock()/munlock(): These calls tend to be used for two different purposes: real-time support and handling of sensitive (cryptographic) material that shouldn't end up in swap. The former use case is out of scope for CloudABI. The latter may also be handled by encrypting swap. Removing this has the advantage that we no longer need to worry about having resource limits put in place. - SOCK_SEQPACKET: Support for SOCK_SEQPACKET is rather inconsistent across various operating systems. Some operating systems supported by CloudABI (e.g., macOS) don't support it at all. Considering that they are rarely used, remove support for the time being. - getsockname(), getpeername(), etc.: A shortcoming of the sockets API is that it doesn't allow you to create socket(pair)s, having fake socket addresses associated with them. This makes it harder to test applications or transparently forward (proxy) connections to them. With CloudABI, we're slowly moving networking connectivity into a separate daemon called Flower. In addition to passing around socket file descriptors, this daemon provides address information in the form of arbitrary string labels. There is thus no longer any need for requesting socket address information from the kernel itself. This change also updates consumers of the generated code accordingly. Even though system calls end up getting renumbered, this won't cause any problems in practice. CloudABI programs always call into the kernel through a kernel-supplied vDSO that has the numbers updated as well. Obtained from: https://github.com/NuxiNL/cloudabi
2017-07-26 06:57:15 +00:00
mov ip, #33
Add very preliminary support for CloudABI for ARMv6. In order to make CloudABI work on ARMv6, start off by copying over the sysvec for ARM64 and adjust it to use 32-bit registers. Also add code for fetching arguments from the stack if needed, as there are fewer register than on ARM64. Also import the vDSO that is needed to invoke system calls. This vDSO uses the intra procedure call register (ip) to store the system call number. This is a bit simpler than what native FreeBSD does, as FreeBSD uses r7, while preserving the original r7 into ip. This sysvec seems to be complete enough to start CloudABI processes. These processes are capable of linking in the vDSO and are therefore capable of executing (most?) system calls successfully. Unfortunately, the biggest show stopper is still that TLS is completely broken: - The linker used by CloudABI, LLD, still has troubles with some of the relocations needed for TLS. See LLVM bug 30218 for more details. - Whereas FreeBSD uses the tpidruro register for TLS, for CloudABI I want to make use of tpidrurw, so that userspace can modify the base address directly. This is needed for efficient emulation. Unfortunately, this register doesn't seem to be preserved across context switches yet. Obtained from: https://github.com/NuxiNL/cloudabi (the vDSO)
2016-09-18 11:36:54 +00:00
swi 0
Sync in latest vDSOs from upstream. - Use conditional instruction to simplify the ARMv6 vDSO. This means that we no longer perform any branching. In the failure case, we simply slide over the assignments of the return values. The vDSO could be improved even further by using stmia to do assignments in parallel. Unfortunately, the script used to generate these is not smart enough for that (yet). Spotted by: andrew@. - Make the style of the i686 vDSO more similar to the others by using decimal literals.
2016-09-19 17:31:05 +00:00
ldrcc r2, [sp, #16]
strcc r0, [r2]
movcc r0, $0
Add very preliminary support for CloudABI for ARMv6. In order to make CloudABI work on ARMv6, start off by copying over the sysvec for ARM64 and adjust it to use 32-bit registers. Also add code for fetching arguments from the stack if needed, as there are fewer register than on ARM64. Also import the vDSO that is needed to invoke system calls. This vDSO uses the intra procedure call register (ip) to store the system call number. This is a bit simpler than what native FreeBSD does, as FreeBSD uses r7, while preserving the original r7 into ip. This sysvec seems to be complete enough to start CloudABI processes. These processes are capable of linking in the vDSO and are therefore capable of executing (most?) system calls successfully. Unfortunately, the biggest show stopper is still that TLS is completely broken: - The linker used by CloudABI, LLD, still has troubles with some of the relocations needed for TLS. See LLVM bug 30218 for more details. - Whereas FreeBSD uses the tpidruro register for TLS, for CloudABI I want to make use of tpidrurw, so that userspace can modify the base address directly. This is needed for efficient emulation. Unfortunately, this register doesn't seem to be preserved across context switches yet. Obtained from: https://github.com/NuxiNL/cloudabi (the vDSO)
2016-09-18 11:36:54 +00:00
bx lr
END(cloudabi_sys_mem_map)
ENTRY(cloudabi_sys_mem_protect)
Upgrade to the latest sources generated from the CloudABI specification. The CloudABI specification has had some minor changes over the last half year. No substantial features have been added, but some features that are deemed unnecessary in retrospect have been removed: - mlock()/munlock(): These calls tend to be used for two different purposes: real-time support and handling of sensitive (cryptographic) material that shouldn't end up in swap. The former use case is out of scope for CloudABI. The latter may also be handled by encrypting swap. Removing this has the advantage that we no longer need to worry about having resource limits put in place. - SOCK_SEQPACKET: Support for SOCK_SEQPACKET is rather inconsistent across various operating systems. Some operating systems supported by CloudABI (e.g., macOS) don't support it at all. Considering that they are rarely used, remove support for the time being. - getsockname(), getpeername(), etc.: A shortcoming of the sockets API is that it doesn't allow you to create socket(pair)s, having fake socket addresses associated with them. This makes it harder to test applications or transparently forward (proxy) connections to them. With CloudABI, we're slowly moving networking connectivity into a separate daemon called Flower. In addition to passing around socket file descriptors, this daemon provides address information in the form of arbitrary string labels. There is thus no longer any need for requesting socket address information from the kernel itself. This change also updates consumers of the generated code accordingly. Even though system calls end up getting renumbered, this won't cause any problems in practice. CloudABI programs always call into the kernel through a kernel-supplied vDSO that has the numbers updated as well. Obtained from: https://github.com/NuxiNL/cloudabi
2017-07-26 06:57:15 +00:00
mov ip, #34
Add very preliminary support for CloudABI for ARMv6. In order to make CloudABI work on ARMv6, start off by copying over the sysvec for ARM64 and adjust it to use 32-bit registers. Also add code for fetching arguments from the stack if needed, as there are fewer register than on ARM64. Also import the vDSO that is needed to invoke system calls. This vDSO uses the intra procedure call register (ip) to store the system call number. This is a bit simpler than what native FreeBSD does, as FreeBSD uses r7, while preserving the original r7 into ip. This sysvec seems to be complete enough to start CloudABI processes. These processes are capable of linking in the vDSO and are therefore capable of executing (most?) system calls successfully. Unfortunately, the biggest show stopper is still that TLS is completely broken: - The linker used by CloudABI, LLD, still has troubles with some of the relocations needed for TLS. See LLVM bug 30218 for more details. - Whereas FreeBSD uses the tpidruro register for TLS, for CloudABI I want to make use of tpidrurw, so that userspace can modify the base address directly. This is needed for efficient emulation. Unfortunately, this register doesn't seem to be preserved across context switches yet. Obtained from: https://github.com/NuxiNL/cloudabi (the vDSO)
2016-09-18 11:36:54 +00:00
swi 0
bx lr
END(cloudabi_sys_mem_protect)
ENTRY(cloudabi_sys_mem_sync)
Upgrade to the latest sources generated from the CloudABI specification. The CloudABI specification has had some minor changes over the last half year. No substantial features have been added, but some features that are deemed unnecessary in retrospect have been removed: - mlock()/munlock(): These calls tend to be used for two different purposes: real-time support and handling of sensitive (cryptographic) material that shouldn't end up in swap. The former use case is out of scope for CloudABI. The latter may also be handled by encrypting swap. Removing this has the advantage that we no longer need to worry about having resource limits put in place. - SOCK_SEQPACKET: Support for SOCK_SEQPACKET is rather inconsistent across various operating systems. Some operating systems supported by CloudABI (e.g., macOS) don't support it at all. Considering that they are rarely used, remove support for the time being. - getsockname(), getpeername(), etc.: A shortcoming of the sockets API is that it doesn't allow you to create socket(pair)s, having fake socket addresses associated with them. This makes it harder to test applications or transparently forward (proxy) connections to them. With CloudABI, we're slowly moving networking connectivity into a separate daemon called Flower. In addition to passing around socket file descriptors, this daemon provides address information in the form of arbitrary string labels. There is thus no longer any need for requesting socket address information from the kernel itself. This change also updates consumers of the generated code accordingly. Even though system calls end up getting renumbered, this won't cause any problems in practice. CloudABI programs always call into the kernel through a kernel-supplied vDSO that has the numbers updated as well. Obtained from: https://github.com/NuxiNL/cloudabi
2017-07-26 06:57:15 +00:00
mov ip, #35
Add very preliminary support for CloudABI for ARMv6. In order to make CloudABI work on ARMv6, start off by copying over the sysvec for ARM64 and adjust it to use 32-bit registers. Also add code for fetching arguments from the stack if needed, as there are fewer register than on ARM64. Also import the vDSO that is needed to invoke system calls. This vDSO uses the intra procedure call register (ip) to store the system call number. This is a bit simpler than what native FreeBSD does, as FreeBSD uses r7, while preserving the original r7 into ip. This sysvec seems to be complete enough to start CloudABI processes. These processes are capable of linking in the vDSO and are therefore capable of executing (most?) system calls successfully. Unfortunately, the biggest show stopper is still that TLS is completely broken: - The linker used by CloudABI, LLD, still has troubles with some of the relocations needed for TLS. See LLVM bug 30218 for more details. - Whereas FreeBSD uses the tpidruro register for TLS, for CloudABI I want to make use of tpidrurw, so that userspace can modify the base address directly. This is needed for efficient emulation. Unfortunately, this register doesn't seem to be preserved across context switches yet. Obtained from: https://github.com/NuxiNL/cloudabi (the vDSO)
2016-09-18 11:36:54 +00:00
swi 0
bx lr
END(cloudabi_sys_mem_sync)
ENTRY(cloudabi_sys_mem_unmap)
Upgrade to the latest sources generated from the CloudABI specification. The CloudABI specification has had some minor changes over the last half year. No substantial features have been added, but some features that are deemed unnecessary in retrospect have been removed: - mlock()/munlock(): These calls tend to be used for two different purposes: real-time support and handling of sensitive (cryptographic) material that shouldn't end up in swap. The former use case is out of scope for CloudABI. The latter may also be handled by encrypting swap. Removing this has the advantage that we no longer need to worry about having resource limits put in place. - SOCK_SEQPACKET: Support for SOCK_SEQPACKET is rather inconsistent across various operating systems. Some operating systems supported by CloudABI (e.g., macOS) don't support it at all. Considering that they are rarely used, remove support for the time being. - getsockname(), getpeername(), etc.: A shortcoming of the sockets API is that it doesn't allow you to create socket(pair)s, having fake socket addresses associated with them. This makes it harder to test applications or transparently forward (proxy) connections to them. With CloudABI, we're slowly moving networking connectivity into a separate daemon called Flower. In addition to passing around socket file descriptors, this daemon provides address information in the form of arbitrary string labels. There is thus no longer any need for requesting socket address information from the kernel itself. This change also updates consumers of the generated code accordingly. Even though system calls end up getting renumbered, this won't cause any problems in practice. CloudABI programs always call into the kernel through a kernel-supplied vDSO that has the numbers updated as well. Obtained from: https://github.com/NuxiNL/cloudabi
2017-07-26 06:57:15 +00:00
mov ip, #36
Add very preliminary support for CloudABI for ARMv6. In order to make CloudABI work on ARMv6, start off by copying over the sysvec for ARM64 and adjust it to use 32-bit registers. Also add code for fetching arguments from the stack if needed, as there are fewer register than on ARM64. Also import the vDSO that is needed to invoke system calls. This vDSO uses the intra procedure call register (ip) to store the system call number. This is a bit simpler than what native FreeBSD does, as FreeBSD uses r7, while preserving the original r7 into ip. This sysvec seems to be complete enough to start CloudABI processes. These processes are capable of linking in the vDSO and are therefore capable of executing (most?) system calls successfully. Unfortunately, the biggest show stopper is still that TLS is completely broken: - The linker used by CloudABI, LLD, still has troubles with some of the relocations needed for TLS. See LLVM bug 30218 for more details. - Whereas FreeBSD uses the tpidruro register for TLS, for CloudABI I want to make use of tpidrurw, so that userspace can modify the base address directly. This is needed for efficient emulation. Unfortunately, this register doesn't seem to be preserved across context switches yet. Obtained from: https://github.com/NuxiNL/cloudabi (the vDSO)
2016-09-18 11:36:54 +00:00
swi 0
bx lr
END(cloudabi_sys_mem_unmap)
ENTRY(cloudabi_sys_poll)
str r3, [sp, #-4]
Upgrade to the latest sources generated from the CloudABI specification. The CloudABI specification has had some minor changes over the last half year. No substantial features have been added, but some features that are deemed unnecessary in retrospect have been removed: - mlock()/munlock(): These calls tend to be used for two different purposes: real-time support and handling of sensitive (cryptographic) material that shouldn't end up in swap. The former use case is out of scope for CloudABI. The latter may also be handled by encrypting swap. Removing this has the advantage that we no longer need to worry about having resource limits put in place. - SOCK_SEQPACKET: Support for SOCK_SEQPACKET is rather inconsistent across various operating systems. Some operating systems supported by CloudABI (e.g., macOS) don't support it at all. Considering that they are rarely used, remove support for the time being. - getsockname(), getpeername(), etc.: A shortcoming of the sockets API is that it doesn't allow you to create socket(pair)s, having fake socket addresses associated with them. This makes it harder to test applications or transparently forward (proxy) connections to them. With CloudABI, we're slowly moving networking connectivity into a separate daemon called Flower. In addition to passing around socket file descriptors, this daemon provides address information in the form of arbitrary string labels. There is thus no longer any need for requesting socket address information from the kernel itself. This change also updates consumers of the generated code accordingly. Even though system calls end up getting renumbered, this won't cause any problems in practice. CloudABI programs always call into the kernel through a kernel-supplied vDSO that has the numbers updated as well. Obtained from: https://github.com/NuxiNL/cloudabi
2017-07-26 06:57:15 +00:00
mov ip, #37
Add very preliminary support for CloudABI for ARMv6. In order to make CloudABI work on ARMv6, start off by copying over the sysvec for ARM64 and adjust it to use 32-bit registers. Also add code for fetching arguments from the stack if needed, as there are fewer register than on ARM64. Also import the vDSO that is needed to invoke system calls. This vDSO uses the intra procedure call register (ip) to store the system call number. This is a bit simpler than what native FreeBSD does, as FreeBSD uses r7, while preserving the original r7 into ip. This sysvec seems to be complete enough to start CloudABI processes. These processes are capable of linking in the vDSO and are therefore capable of executing (most?) system calls successfully. Unfortunately, the biggest show stopper is still that TLS is completely broken: - The linker used by CloudABI, LLD, still has troubles with some of the relocations needed for TLS. See LLVM bug 30218 for more details. - Whereas FreeBSD uses the tpidruro register for TLS, for CloudABI I want to make use of tpidrurw, so that userspace can modify the base address directly. This is needed for efficient emulation. Unfortunately, this register doesn't seem to be preserved across context switches yet. Obtained from: https://github.com/NuxiNL/cloudabi (the vDSO)
2016-09-18 11:36:54 +00:00
swi 0
Sync in latest vDSOs from upstream. - Use conditional instruction to simplify the ARMv6 vDSO. This means that we no longer perform any branching. In the failure case, we simply slide over the assignments of the return values. The vDSO could be improved even further by using stmia to do assignments in parallel. Unfortunately, the script used to generate these is not smart enough for that (yet). Spotted by: andrew@. - Make the style of the i686 vDSO more similar to the others by using decimal literals.
2016-09-19 17:31:05 +00:00
ldrcc r2, [sp, #-4]
strcc r0, [r2]
movcc r0, $0
Add very preliminary support for CloudABI for ARMv6. In order to make CloudABI work on ARMv6, start off by copying over the sysvec for ARM64 and adjust it to use 32-bit registers. Also add code for fetching arguments from the stack if needed, as there are fewer register than on ARM64. Also import the vDSO that is needed to invoke system calls. This vDSO uses the intra procedure call register (ip) to store the system call number. This is a bit simpler than what native FreeBSD does, as FreeBSD uses r7, while preserving the original r7 into ip. This sysvec seems to be complete enough to start CloudABI processes. These processes are capable of linking in the vDSO and are therefore capable of executing (most?) system calls successfully. Unfortunately, the biggest show stopper is still that TLS is completely broken: - The linker used by CloudABI, LLD, still has troubles with some of the relocations needed for TLS. See LLVM bug 30218 for more details. - Whereas FreeBSD uses the tpidruro register for TLS, for CloudABI I want to make use of tpidrurw, so that userspace can modify the base address directly. This is needed for efficient emulation. Unfortunately, this register doesn't seem to be preserved across context switches yet. Obtained from: https://github.com/NuxiNL/cloudabi (the vDSO)
2016-09-18 11:36:54 +00:00
bx lr
END(cloudabi_sys_poll)
ENTRY(cloudabi_sys_poll_fd)
Upgrade to the latest sources generated from the CloudABI specification. The CloudABI specification has had some minor changes over the last half year. No substantial features have been added, but some features that are deemed unnecessary in retrospect have been removed: - mlock()/munlock(): These calls tend to be used for two different purposes: real-time support and handling of sensitive (cryptographic) material that shouldn't end up in swap. The former use case is out of scope for CloudABI. The latter may also be handled by encrypting swap. Removing this has the advantage that we no longer need to worry about having resource limits put in place. - SOCK_SEQPACKET: Support for SOCK_SEQPACKET is rather inconsistent across various operating systems. Some operating systems supported by CloudABI (e.g., macOS) don't support it at all. Considering that they are rarely used, remove support for the time being. - getsockname(), getpeername(), etc.: A shortcoming of the sockets API is that it doesn't allow you to create socket(pair)s, having fake socket addresses associated with them. This makes it harder to test applications or transparently forward (proxy) connections to them. With CloudABI, we're slowly moving networking connectivity into a separate daemon called Flower. In addition to passing around socket file descriptors, this daemon provides address information in the form of arbitrary string labels. There is thus no longer any need for requesting socket address information from the kernel itself. This change also updates consumers of the generated code accordingly. Even though system calls end up getting renumbered, this won't cause any problems in practice. CloudABI programs always call into the kernel through a kernel-supplied vDSO that has the numbers updated as well. Obtained from: https://github.com/NuxiNL/cloudabi
2017-07-26 06:57:15 +00:00
mov ip, #38
Add very preliminary support for CloudABI for ARMv6. In order to make CloudABI work on ARMv6, start off by copying over the sysvec for ARM64 and adjust it to use 32-bit registers. Also add code for fetching arguments from the stack if needed, as there are fewer register than on ARM64. Also import the vDSO that is needed to invoke system calls. This vDSO uses the intra procedure call register (ip) to store the system call number. This is a bit simpler than what native FreeBSD does, as FreeBSD uses r7, while preserving the original r7 into ip. This sysvec seems to be complete enough to start CloudABI processes. These processes are capable of linking in the vDSO and are therefore capable of executing (most?) system calls successfully. Unfortunately, the biggest show stopper is still that TLS is completely broken: - The linker used by CloudABI, LLD, still has troubles with some of the relocations needed for TLS. See LLVM bug 30218 for more details. - Whereas FreeBSD uses the tpidruro register for TLS, for CloudABI I want to make use of tpidrurw, so that userspace can modify the base address directly. This is needed for efficient emulation. Unfortunately, this register doesn't seem to be preserved across context switches yet. Obtained from: https://github.com/NuxiNL/cloudabi (the vDSO)
2016-09-18 11:36:54 +00:00
swi 0
Sync in latest vDSOs from upstream. - Use conditional instruction to simplify the ARMv6 vDSO. This means that we no longer perform any branching. In the failure case, we simply slide over the assignments of the return values. The vDSO could be improved even further by using stmia to do assignments in parallel. Unfortunately, the script used to generate these is not smart enough for that (yet). Spotted by: andrew@. - Make the style of the i686 vDSO more similar to the others by using decimal literals.
2016-09-19 17:31:05 +00:00
ldrcc r2, [sp, #8]
strcc r0, [r2]
movcc r0, $0
Add very preliminary support for CloudABI for ARMv6. In order to make CloudABI work on ARMv6, start off by copying over the sysvec for ARM64 and adjust it to use 32-bit registers. Also add code for fetching arguments from the stack if needed, as there are fewer register than on ARM64. Also import the vDSO that is needed to invoke system calls. This vDSO uses the intra procedure call register (ip) to store the system call number. This is a bit simpler than what native FreeBSD does, as FreeBSD uses r7, while preserving the original r7 into ip. This sysvec seems to be complete enough to start CloudABI processes. These processes are capable of linking in the vDSO and are therefore capable of executing (most?) system calls successfully. Unfortunately, the biggest show stopper is still that TLS is completely broken: - The linker used by CloudABI, LLD, still has troubles with some of the relocations needed for TLS. See LLVM bug 30218 for more details. - Whereas FreeBSD uses the tpidruro register for TLS, for CloudABI I want to make use of tpidrurw, so that userspace can modify the base address directly. This is needed for efficient emulation. Unfortunately, this register doesn't seem to be preserved across context switches yet. Obtained from: https://github.com/NuxiNL/cloudabi (the vDSO)
2016-09-18 11:36:54 +00:00
bx lr
END(cloudabi_sys_poll_fd)
ENTRY(cloudabi_sys_proc_exec)
Upgrade to the latest sources generated from the CloudABI specification. The CloudABI specification has had some minor changes over the last half year. No substantial features have been added, but some features that are deemed unnecessary in retrospect have been removed: - mlock()/munlock(): These calls tend to be used for two different purposes: real-time support and handling of sensitive (cryptographic) material that shouldn't end up in swap. The former use case is out of scope for CloudABI. The latter may also be handled by encrypting swap. Removing this has the advantage that we no longer need to worry about having resource limits put in place. - SOCK_SEQPACKET: Support for SOCK_SEQPACKET is rather inconsistent across various operating systems. Some operating systems supported by CloudABI (e.g., macOS) don't support it at all. Considering that they are rarely used, remove support for the time being. - getsockname(), getpeername(), etc.: A shortcoming of the sockets API is that it doesn't allow you to create socket(pair)s, having fake socket addresses associated with them. This makes it harder to test applications or transparently forward (proxy) connections to them. With CloudABI, we're slowly moving networking connectivity into a separate daemon called Flower. In addition to passing around socket file descriptors, this daemon provides address information in the form of arbitrary string labels. There is thus no longer any need for requesting socket address information from the kernel itself. This change also updates consumers of the generated code accordingly. Even though system calls end up getting renumbered, this won't cause any problems in practice. CloudABI programs always call into the kernel through a kernel-supplied vDSO that has the numbers updated as well. Obtained from: https://github.com/NuxiNL/cloudabi
2017-07-26 06:57:15 +00:00
mov ip, #39
Add very preliminary support for CloudABI for ARMv6. In order to make CloudABI work on ARMv6, start off by copying over the sysvec for ARM64 and adjust it to use 32-bit registers. Also add code for fetching arguments from the stack if needed, as there are fewer register than on ARM64. Also import the vDSO that is needed to invoke system calls. This vDSO uses the intra procedure call register (ip) to store the system call number. This is a bit simpler than what native FreeBSD does, as FreeBSD uses r7, while preserving the original r7 into ip. This sysvec seems to be complete enough to start CloudABI processes. These processes are capable of linking in the vDSO and are therefore capable of executing (most?) system calls successfully. Unfortunately, the biggest show stopper is still that TLS is completely broken: - The linker used by CloudABI, LLD, still has troubles with some of the relocations needed for TLS. See LLVM bug 30218 for more details. - Whereas FreeBSD uses the tpidruro register for TLS, for CloudABI I want to make use of tpidrurw, so that userspace can modify the base address directly. This is needed for efficient emulation. Unfortunately, this register doesn't seem to be preserved across context switches yet. Obtained from: https://github.com/NuxiNL/cloudabi (the vDSO)
2016-09-18 11:36:54 +00:00
swi 0
bx lr
END(cloudabi_sys_proc_exec)
ENTRY(cloudabi_sys_proc_exit)
Upgrade to the latest sources generated from the CloudABI specification. The CloudABI specification has had some minor changes over the last half year. No substantial features have been added, but some features that are deemed unnecessary in retrospect have been removed: - mlock()/munlock(): These calls tend to be used for two different purposes: real-time support and handling of sensitive (cryptographic) material that shouldn't end up in swap. The former use case is out of scope for CloudABI. The latter may also be handled by encrypting swap. Removing this has the advantage that we no longer need to worry about having resource limits put in place. - SOCK_SEQPACKET: Support for SOCK_SEQPACKET is rather inconsistent across various operating systems. Some operating systems supported by CloudABI (e.g., macOS) don't support it at all. Considering that they are rarely used, remove support for the time being. - getsockname(), getpeername(), etc.: A shortcoming of the sockets API is that it doesn't allow you to create socket(pair)s, having fake socket addresses associated with them. This makes it harder to test applications or transparently forward (proxy) connections to them. With CloudABI, we're slowly moving networking connectivity into a separate daemon called Flower. In addition to passing around socket file descriptors, this daemon provides address information in the form of arbitrary string labels. There is thus no longer any need for requesting socket address information from the kernel itself. This change also updates consumers of the generated code accordingly. Even though system calls end up getting renumbered, this won't cause any problems in practice. CloudABI programs always call into the kernel through a kernel-supplied vDSO that has the numbers updated as well. Obtained from: https://github.com/NuxiNL/cloudabi
2017-07-26 06:57:15 +00:00
mov ip, #40
Add very preliminary support for CloudABI for ARMv6. In order to make CloudABI work on ARMv6, start off by copying over the sysvec for ARM64 and adjust it to use 32-bit registers. Also add code for fetching arguments from the stack if needed, as there are fewer register than on ARM64. Also import the vDSO that is needed to invoke system calls. This vDSO uses the intra procedure call register (ip) to store the system call number. This is a bit simpler than what native FreeBSD does, as FreeBSD uses r7, while preserving the original r7 into ip. This sysvec seems to be complete enough to start CloudABI processes. These processes are capable of linking in the vDSO and are therefore capable of executing (most?) system calls successfully. Unfortunately, the biggest show stopper is still that TLS is completely broken: - The linker used by CloudABI, LLD, still has troubles with some of the relocations needed for TLS. See LLVM bug 30218 for more details. - Whereas FreeBSD uses the tpidruro register for TLS, for CloudABI I want to make use of tpidrurw, so that userspace can modify the base address directly. This is needed for efficient emulation. Unfortunately, this register doesn't seem to be preserved across context switches yet. Obtained from: https://github.com/NuxiNL/cloudabi (the vDSO)
2016-09-18 11:36:54 +00:00
swi 0
END(cloudabi_sys_proc_exit)
ENTRY(cloudabi_sys_proc_fork)
str r0, [sp, #-4]
str r1, [sp, #-8]
Upgrade to the latest sources generated from the CloudABI specification. The CloudABI specification has had some minor changes over the last half year. No substantial features have been added, but some features that are deemed unnecessary in retrospect have been removed: - mlock()/munlock(): These calls tend to be used for two different purposes: real-time support and handling of sensitive (cryptographic) material that shouldn't end up in swap. The former use case is out of scope for CloudABI. The latter may also be handled by encrypting swap. Removing this has the advantage that we no longer need to worry about having resource limits put in place. - SOCK_SEQPACKET: Support for SOCK_SEQPACKET is rather inconsistent across various operating systems. Some operating systems supported by CloudABI (e.g., macOS) don't support it at all. Considering that they are rarely used, remove support for the time being. - getsockname(), getpeername(), etc.: A shortcoming of the sockets API is that it doesn't allow you to create socket(pair)s, having fake socket addresses associated with them. This makes it harder to test applications or transparently forward (proxy) connections to them. With CloudABI, we're slowly moving networking connectivity into a separate daemon called Flower. In addition to passing around socket file descriptors, this daemon provides address information in the form of arbitrary string labels. There is thus no longer any need for requesting socket address information from the kernel itself. This change also updates consumers of the generated code accordingly. Even though system calls end up getting renumbered, this won't cause any problems in practice. CloudABI programs always call into the kernel through a kernel-supplied vDSO that has the numbers updated as well. Obtained from: https://github.com/NuxiNL/cloudabi
2017-07-26 06:57:15 +00:00
mov ip, #41
Add very preliminary support for CloudABI for ARMv6. In order to make CloudABI work on ARMv6, start off by copying over the sysvec for ARM64 and adjust it to use 32-bit registers. Also add code for fetching arguments from the stack if needed, as there are fewer register than on ARM64. Also import the vDSO that is needed to invoke system calls. This vDSO uses the intra procedure call register (ip) to store the system call number. This is a bit simpler than what native FreeBSD does, as FreeBSD uses r7, while preserving the original r7 into ip. This sysvec seems to be complete enough to start CloudABI processes. These processes are capable of linking in the vDSO and are therefore capable of executing (most?) system calls successfully. Unfortunately, the biggest show stopper is still that TLS is completely broken: - The linker used by CloudABI, LLD, still has troubles with some of the relocations needed for TLS. See LLVM bug 30218 for more details. - Whereas FreeBSD uses the tpidruro register for TLS, for CloudABI I want to make use of tpidrurw, so that userspace can modify the base address directly. This is needed for efficient emulation. Unfortunately, this register doesn't seem to be preserved across context switches yet. Obtained from: https://github.com/NuxiNL/cloudabi (the vDSO)
2016-09-18 11:36:54 +00:00
swi 0
Sync in latest vDSOs from upstream. - Use conditional instruction to simplify the ARMv6 vDSO. This means that we no longer perform any branching. In the failure case, we simply slide over the assignments of the return values. The vDSO could be improved even further by using stmia to do assignments in parallel. Unfortunately, the script used to generate these is not smart enough for that (yet). Spotted by: andrew@. - Make the style of the i686 vDSO more similar to the others by using decimal literals.
2016-09-19 17:31:05 +00:00
ldrcc r2, [sp, #-4]
ldrcc r3, [sp, #-8]
strcc r0, [r2]
strcc r1, [r3]
movcc r0, $0
Add very preliminary support for CloudABI for ARMv6. In order to make CloudABI work on ARMv6, start off by copying over the sysvec for ARM64 and adjust it to use 32-bit registers. Also add code for fetching arguments from the stack if needed, as there are fewer register than on ARM64. Also import the vDSO that is needed to invoke system calls. This vDSO uses the intra procedure call register (ip) to store the system call number. This is a bit simpler than what native FreeBSD does, as FreeBSD uses r7, while preserving the original r7 into ip. This sysvec seems to be complete enough to start CloudABI processes. These processes are capable of linking in the vDSO and are therefore capable of executing (most?) system calls successfully. Unfortunately, the biggest show stopper is still that TLS is completely broken: - The linker used by CloudABI, LLD, still has troubles with some of the relocations needed for TLS. See LLVM bug 30218 for more details. - Whereas FreeBSD uses the tpidruro register for TLS, for CloudABI I want to make use of tpidrurw, so that userspace can modify the base address directly. This is needed for efficient emulation. Unfortunately, this register doesn't seem to be preserved across context switches yet. Obtained from: https://github.com/NuxiNL/cloudabi (the vDSO)
2016-09-18 11:36:54 +00:00
bx lr
END(cloudabi_sys_proc_fork)
ENTRY(cloudabi_sys_proc_raise)
Upgrade to the latest sources generated from the CloudABI specification. The CloudABI specification has had some minor changes over the last half year. No substantial features have been added, but some features that are deemed unnecessary in retrospect have been removed: - mlock()/munlock(): These calls tend to be used for two different purposes: real-time support and handling of sensitive (cryptographic) material that shouldn't end up in swap. The former use case is out of scope for CloudABI. The latter may also be handled by encrypting swap. Removing this has the advantage that we no longer need to worry about having resource limits put in place. - SOCK_SEQPACKET: Support for SOCK_SEQPACKET is rather inconsistent across various operating systems. Some operating systems supported by CloudABI (e.g., macOS) don't support it at all. Considering that they are rarely used, remove support for the time being. - getsockname(), getpeername(), etc.: A shortcoming of the sockets API is that it doesn't allow you to create socket(pair)s, having fake socket addresses associated with them. This makes it harder to test applications or transparently forward (proxy) connections to them. With CloudABI, we're slowly moving networking connectivity into a separate daemon called Flower. In addition to passing around socket file descriptors, this daemon provides address information in the form of arbitrary string labels. There is thus no longer any need for requesting socket address information from the kernel itself. This change also updates consumers of the generated code accordingly. Even though system calls end up getting renumbered, this won't cause any problems in practice. CloudABI programs always call into the kernel through a kernel-supplied vDSO that has the numbers updated as well. Obtained from: https://github.com/NuxiNL/cloudabi
2017-07-26 06:57:15 +00:00
mov ip, #42
Add very preliminary support for CloudABI for ARMv6. In order to make CloudABI work on ARMv6, start off by copying over the sysvec for ARM64 and adjust it to use 32-bit registers. Also add code for fetching arguments from the stack if needed, as there are fewer register than on ARM64. Also import the vDSO that is needed to invoke system calls. This vDSO uses the intra procedure call register (ip) to store the system call number. This is a bit simpler than what native FreeBSD does, as FreeBSD uses r7, while preserving the original r7 into ip. This sysvec seems to be complete enough to start CloudABI processes. These processes are capable of linking in the vDSO and are therefore capable of executing (most?) system calls successfully. Unfortunately, the biggest show stopper is still that TLS is completely broken: - The linker used by CloudABI, LLD, still has troubles with some of the relocations needed for TLS. See LLVM bug 30218 for more details. - Whereas FreeBSD uses the tpidruro register for TLS, for CloudABI I want to make use of tpidrurw, so that userspace can modify the base address directly. This is needed for efficient emulation. Unfortunately, this register doesn't seem to be preserved across context switches yet. Obtained from: https://github.com/NuxiNL/cloudabi (the vDSO)
2016-09-18 11:36:54 +00:00
swi 0
bx lr
END(cloudabi_sys_proc_raise)
ENTRY(cloudabi_sys_random_get)
Upgrade to the latest sources generated from the CloudABI specification. The CloudABI specification has had some minor changes over the last half year. No substantial features have been added, but some features that are deemed unnecessary in retrospect have been removed: - mlock()/munlock(): These calls tend to be used for two different purposes: real-time support and handling of sensitive (cryptographic) material that shouldn't end up in swap. The former use case is out of scope for CloudABI. The latter may also be handled by encrypting swap. Removing this has the advantage that we no longer need to worry about having resource limits put in place. - SOCK_SEQPACKET: Support for SOCK_SEQPACKET is rather inconsistent across various operating systems. Some operating systems supported by CloudABI (e.g., macOS) don't support it at all. Considering that they are rarely used, remove support for the time being. - getsockname(), getpeername(), etc.: A shortcoming of the sockets API is that it doesn't allow you to create socket(pair)s, having fake socket addresses associated with them. This makes it harder to test applications or transparently forward (proxy) connections to them. With CloudABI, we're slowly moving networking connectivity into a separate daemon called Flower. In addition to passing around socket file descriptors, this daemon provides address information in the form of arbitrary string labels. There is thus no longer any need for requesting socket address information from the kernel itself. This change also updates consumers of the generated code accordingly. Even though system calls end up getting renumbered, this won't cause any problems in practice. CloudABI programs always call into the kernel through a kernel-supplied vDSO that has the numbers updated as well. Obtained from: https://github.com/NuxiNL/cloudabi
2017-07-26 06:57:15 +00:00
mov ip, #43
Add very preliminary support for CloudABI for ARMv6. In order to make CloudABI work on ARMv6, start off by copying over the sysvec for ARM64 and adjust it to use 32-bit registers. Also add code for fetching arguments from the stack if needed, as there are fewer register than on ARM64. Also import the vDSO that is needed to invoke system calls. This vDSO uses the intra procedure call register (ip) to store the system call number. This is a bit simpler than what native FreeBSD does, as FreeBSD uses r7, while preserving the original r7 into ip. This sysvec seems to be complete enough to start CloudABI processes. These processes are capable of linking in the vDSO and are therefore capable of executing (most?) system calls successfully. Unfortunately, the biggest show stopper is still that TLS is completely broken: - The linker used by CloudABI, LLD, still has troubles with some of the relocations needed for TLS. See LLVM bug 30218 for more details. - Whereas FreeBSD uses the tpidruro register for TLS, for CloudABI I want to make use of tpidrurw, so that userspace can modify the base address directly. This is needed for efficient emulation. Unfortunately, this register doesn't seem to be preserved across context switches yet. Obtained from: https://github.com/NuxiNL/cloudabi (the vDSO)
2016-09-18 11:36:54 +00:00
swi 0
bx lr
END(cloudabi_sys_random_get)
ENTRY(cloudabi_sys_sock_recv)
Complete the CloudABI networking refactoring. Now that all of the packaged software has been adjusted to either use Flower (https://github.com/NuxiNL/flower) for making incoming/outgoing network connections or can have connections injected, there is no longer need to keep accept() around. It is now a lot easier to write networked services that are address family independent, dual-stack, testable, etc. Remove all of the bits related to accept(), but also to getsockopt(SO_ACCEPTCONN).
2017-08-30 07:30:06 +00:00
mov ip, #44
Add very preliminary support for CloudABI for ARMv6. In order to make CloudABI work on ARMv6, start off by copying over the sysvec for ARM64 and adjust it to use 32-bit registers. Also add code for fetching arguments from the stack if needed, as there are fewer register than on ARM64. Also import the vDSO that is needed to invoke system calls. This vDSO uses the intra procedure call register (ip) to store the system call number. This is a bit simpler than what native FreeBSD does, as FreeBSD uses r7, while preserving the original r7 into ip. This sysvec seems to be complete enough to start CloudABI processes. These processes are capable of linking in the vDSO and are therefore capable of executing (most?) system calls successfully. Unfortunately, the biggest show stopper is still that TLS is completely broken: - The linker used by CloudABI, LLD, still has troubles with some of the relocations needed for TLS. See LLVM bug 30218 for more details. - Whereas FreeBSD uses the tpidruro register for TLS, for CloudABI I want to make use of tpidrurw, so that userspace can modify the base address directly. This is needed for efficient emulation. Unfortunately, this register doesn't seem to be preserved across context switches yet. Obtained from: https://github.com/NuxiNL/cloudabi (the vDSO)
2016-09-18 11:36:54 +00:00
swi 0
bx lr
END(cloudabi_sys_sock_recv)
ENTRY(cloudabi_sys_sock_send)
Complete the CloudABI networking refactoring. Now that all of the packaged software has been adjusted to either use Flower (https://github.com/NuxiNL/flower) for making incoming/outgoing network connections or can have connections injected, there is no longer need to keep accept() around. It is now a lot easier to write networked services that are address family independent, dual-stack, testable, etc. Remove all of the bits related to accept(), but also to getsockopt(SO_ACCEPTCONN).
2017-08-30 07:30:06 +00:00
mov ip, #45
Add very preliminary support for CloudABI for ARMv6. In order to make CloudABI work on ARMv6, start off by copying over the sysvec for ARM64 and adjust it to use 32-bit registers. Also add code for fetching arguments from the stack if needed, as there are fewer register than on ARM64. Also import the vDSO that is needed to invoke system calls. This vDSO uses the intra procedure call register (ip) to store the system call number. This is a bit simpler than what native FreeBSD does, as FreeBSD uses r7, while preserving the original r7 into ip. This sysvec seems to be complete enough to start CloudABI processes. These processes are capable of linking in the vDSO and are therefore capable of executing (most?) system calls successfully. Unfortunately, the biggest show stopper is still that TLS is completely broken: - The linker used by CloudABI, LLD, still has troubles with some of the relocations needed for TLS. See LLVM bug 30218 for more details. - Whereas FreeBSD uses the tpidruro register for TLS, for CloudABI I want to make use of tpidrurw, so that userspace can modify the base address directly. This is needed for efficient emulation. Unfortunately, this register doesn't seem to be preserved across context switches yet. Obtained from: https://github.com/NuxiNL/cloudabi (the vDSO)
2016-09-18 11:36:54 +00:00
swi 0
bx lr
END(cloudabi_sys_sock_send)
ENTRY(cloudabi_sys_sock_shutdown)
Complete the CloudABI networking refactoring. Now that all of the packaged software has been adjusted to either use Flower (https://github.com/NuxiNL/flower) for making incoming/outgoing network connections or can have connections injected, there is no longer need to keep accept() around. It is now a lot easier to write networked services that are address family independent, dual-stack, testable, etc. Remove all of the bits related to accept(), but also to getsockopt(SO_ACCEPTCONN).
2017-08-30 07:30:06 +00:00
mov ip, #46
Add very preliminary support for CloudABI for ARMv6. In order to make CloudABI work on ARMv6, start off by copying over the sysvec for ARM64 and adjust it to use 32-bit registers. Also add code for fetching arguments from the stack if needed, as there are fewer register than on ARM64. Also import the vDSO that is needed to invoke system calls. This vDSO uses the intra procedure call register (ip) to store the system call number. This is a bit simpler than what native FreeBSD does, as FreeBSD uses r7, while preserving the original r7 into ip. This sysvec seems to be complete enough to start CloudABI processes. These processes are capable of linking in the vDSO and are therefore capable of executing (most?) system calls successfully. Unfortunately, the biggest show stopper is still that TLS is completely broken: - The linker used by CloudABI, LLD, still has troubles with some of the relocations needed for TLS. See LLVM bug 30218 for more details. - Whereas FreeBSD uses the tpidruro register for TLS, for CloudABI I want to make use of tpidrurw, so that userspace can modify the base address directly. This is needed for efficient emulation. Unfortunately, this register doesn't seem to be preserved across context switches yet. Obtained from: https://github.com/NuxiNL/cloudabi (the vDSO)
2016-09-18 11:36:54 +00:00
swi 0
bx lr
END(cloudabi_sys_sock_shutdown)
ENTRY(cloudabi_sys_thread_create)
str r1, [sp, #-4]
Complete the CloudABI networking refactoring. Now that all of the packaged software has been adjusted to either use Flower (https://github.com/NuxiNL/flower) for making incoming/outgoing network connections or can have connections injected, there is no longer need to keep accept() around. It is now a lot easier to write networked services that are address family independent, dual-stack, testable, etc. Remove all of the bits related to accept(), but also to getsockopt(SO_ACCEPTCONN).
2017-08-30 07:30:06 +00:00
mov ip, #47
Add very preliminary support for CloudABI for ARMv6. In order to make CloudABI work on ARMv6, start off by copying over the sysvec for ARM64 and adjust it to use 32-bit registers. Also add code for fetching arguments from the stack if needed, as there are fewer register than on ARM64. Also import the vDSO that is needed to invoke system calls. This vDSO uses the intra procedure call register (ip) to store the system call number. This is a bit simpler than what native FreeBSD does, as FreeBSD uses r7, while preserving the original r7 into ip. This sysvec seems to be complete enough to start CloudABI processes. These processes are capable of linking in the vDSO and are therefore capable of executing (most?) system calls successfully. Unfortunately, the biggest show stopper is still that TLS is completely broken: - The linker used by CloudABI, LLD, still has troubles with some of the relocations needed for TLS. See LLVM bug 30218 for more details. - Whereas FreeBSD uses the tpidruro register for TLS, for CloudABI I want to make use of tpidrurw, so that userspace can modify the base address directly. This is needed for efficient emulation. Unfortunately, this register doesn't seem to be preserved across context switches yet. Obtained from: https://github.com/NuxiNL/cloudabi (the vDSO)
2016-09-18 11:36:54 +00:00
swi 0
Sync in latest vDSOs from upstream. - Use conditional instruction to simplify the ARMv6 vDSO. This means that we no longer perform any branching. In the failure case, we simply slide over the assignments of the return values. The vDSO could be improved even further by using stmia to do assignments in parallel. Unfortunately, the script used to generate these is not smart enough for that (yet). Spotted by: andrew@. - Make the style of the i686 vDSO more similar to the others by using decimal literals.
2016-09-19 17:31:05 +00:00
ldrcc r2, [sp, #-4]
strcc r0, [r2]
movcc r0, $0
Add very preliminary support for CloudABI for ARMv6. In order to make CloudABI work on ARMv6, start off by copying over the sysvec for ARM64 and adjust it to use 32-bit registers. Also add code for fetching arguments from the stack if needed, as there are fewer register than on ARM64. Also import the vDSO that is needed to invoke system calls. This vDSO uses the intra procedure call register (ip) to store the system call number. This is a bit simpler than what native FreeBSD does, as FreeBSD uses r7, while preserving the original r7 into ip. This sysvec seems to be complete enough to start CloudABI processes. These processes are capable of linking in the vDSO and are therefore capable of executing (most?) system calls successfully. Unfortunately, the biggest show stopper is still that TLS is completely broken: - The linker used by CloudABI, LLD, still has troubles with some of the relocations needed for TLS. See LLVM bug 30218 for more details. - Whereas FreeBSD uses the tpidruro register for TLS, for CloudABI I want to make use of tpidrurw, so that userspace can modify the base address directly. This is needed for efficient emulation. Unfortunately, this register doesn't seem to be preserved across context switches yet. Obtained from: https://github.com/NuxiNL/cloudabi (the vDSO)
2016-09-18 11:36:54 +00:00
bx lr
END(cloudabi_sys_thread_create)
ENTRY(cloudabi_sys_thread_exit)
Complete the CloudABI networking refactoring. Now that all of the packaged software has been adjusted to either use Flower (https://github.com/NuxiNL/flower) for making incoming/outgoing network connections or can have connections injected, there is no longer need to keep accept() around. It is now a lot easier to write networked services that are address family independent, dual-stack, testable, etc. Remove all of the bits related to accept(), but also to getsockopt(SO_ACCEPTCONN).
2017-08-30 07:30:06 +00:00
mov ip, #48
Add very preliminary support for CloudABI for ARMv6. In order to make CloudABI work on ARMv6, start off by copying over the sysvec for ARM64 and adjust it to use 32-bit registers. Also add code for fetching arguments from the stack if needed, as there are fewer register than on ARM64. Also import the vDSO that is needed to invoke system calls. This vDSO uses the intra procedure call register (ip) to store the system call number. This is a bit simpler than what native FreeBSD does, as FreeBSD uses r7, while preserving the original r7 into ip. This sysvec seems to be complete enough to start CloudABI processes. These processes are capable of linking in the vDSO and are therefore capable of executing (most?) system calls successfully. Unfortunately, the biggest show stopper is still that TLS is completely broken: - The linker used by CloudABI, LLD, still has troubles with some of the relocations needed for TLS. See LLVM bug 30218 for more details. - Whereas FreeBSD uses the tpidruro register for TLS, for CloudABI I want to make use of tpidrurw, so that userspace can modify the base address directly. This is needed for efficient emulation. Unfortunately, this register doesn't seem to be preserved across context switches yet. Obtained from: https://github.com/NuxiNL/cloudabi (the vDSO)
2016-09-18 11:36:54 +00:00
swi 0
END(cloudabi_sys_thread_exit)
ENTRY(cloudabi_sys_thread_yield)
Complete the CloudABI networking refactoring. Now that all of the packaged software has been adjusted to either use Flower (https://github.com/NuxiNL/flower) for making incoming/outgoing network connections or can have connections injected, there is no longer need to keep accept() around. It is now a lot easier to write networked services that are address family independent, dual-stack, testable, etc. Remove all of the bits related to accept(), but also to getsockopt(SO_ACCEPTCONN).
2017-08-30 07:30:06 +00:00
mov ip, #49
Add very preliminary support for CloudABI for ARMv6. In order to make CloudABI work on ARMv6, start off by copying over the sysvec for ARM64 and adjust it to use 32-bit registers. Also add code for fetching arguments from the stack if needed, as there are fewer register than on ARM64. Also import the vDSO that is needed to invoke system calls. This vDSO uses the intra procedure call register (ip) to store the system call number. This is a bit simpler than what native FreeBSD does, as FreeBSD uses r7, while preserving the original r7 into ip. This sysvec seems to be complete enough to start CloudABI processes. These processes are capable of linking in the vDSO and are therefore capable of executing (most?) system calls successfully. Unfortunately, the biggest show stopper is still that TLS is completely broken: - The linker used by CloudABI, LLD, still has troubles with some of the relocations needed for TLS. See LLVM bug 30218 for more details. - Whereas FreeBSD uses the tpidruro register for TLS, for CloudABI I want to make use of tpidrurw, so that userspace can modify the base address directly. This is needed for efficient emulation. Unfortunately, this register doesn't seem to be preserved across context switches yet. Obtained from: https://github.com/NuxiNL/cloudabi (the vDSO)
2016-09-18 11:36:54 +00:00
swi 0
bx lr
END(cloudabi_sys_thread_yield)
Reference in New Issue Copy Permalink