configure | 10 +++++ include/elf.h | 1 + linux-user/arm/target_syscall.h | 1 + linux-user/elfload.c | 35 ++++++++++++++++ linux-user/main.c | 8 ++++ linux-user/qemu.h | 3 ++ linux-user/signal.c | 91 +++++++++++++++++++++++++++++++++++++---- target/arm/cpu.h | 6 +++ 8 files changed, 147 insertions(+), 8 deletions(-)
Hello,
This patch series implements the QEMU contribution of the FDPIC
ABI for ARM targets.
This ABI enables to run Linux on ARM MMU-less cores and supports
shared libraries to reduce the memory footprint.
Without MMU, text and data segment relative distances are different
from one process to another, hence the need for a dedicated FDPIC
register holding the start address of the data segment. One of the
side effects is that function pointers require two words to be
represented: the address of the code, and the data segment start
address. These two words are designated as "Function Descriptor",
hence the "FD PIC" name.
On ARM, the FDPIC register is r9 [3].
This work was developed some time ago by STMicroelectronics, and was
presented during Linaro Connect SFO15 (September 2015). You can watch
the discussion and read the slides [1].
This presentation was related to the toolchain published on github [2],
which is based on binutils-2.22, gcc-4.7, uclibc-0.9.33.2, gdb-7.5.1
and qemu-2.3.0, and for which pre-built binaries are available [2].
The ABI itself is described in details in [3].
Our Linux kernel patches have been updated and committed by Nicolas
Pitre (Linaro) in July 2017. They are required so that the loader is
able to handle this new file type. Indeed, the ELF files are tagged
with ELFOSABI_ARM_FDPIC. This new tag has been allocated by ARM, as
well as the new relocations involved.
This patch series has been rebased on top of QEMU from 2018-03-28.
I have also rebased the GCC patch series, but it is still WIP as
cleanup is still needed before I can request a review. It can be
useful to build a preview toolchain though, so my WIP branch is
available at [4].
To build such a toolchain, you'd also need to use my uClibc
branch [5].
I am currently working on updating the patches for the other toolchain
components, and will upstream them soon. This includes gcc, uclibc,
and gdb.
This series provides support for ARM v7 and later architectures and
has been used to run the GCC tests on arm-linux-gnueabi without
regression, as well as arm-linux-uclibceabi.
Are the QEMU patches OK for inclusion in master?
Thanks,
Christophe.
[1] http://connect.linaro.org/resource/sfo15/sfo15-406-arm-fdpic-toolset-kernel-libraries-for-cortex-m-cortex-r-mmuless-cores/
[2] https://github.com/mickael-guene/fdpic_manifest
[3] https://github.com/mickael-guene/fdpic_doc/blob/master/abi.txt
[4] https://git.linaro.org/people/christophe.lyon/gcc.git/log/?h=fdpic-upstream
[5] https://git.linaro.org/people/christophe.lyon/uclibc.git/log/?h=uClibc-0.9.33.2-fdpic-upstream
Christophe Lyon (4):
linux-user: ARM-FDPIC: Add configure option to support loading of
FDPIC binaries
linux-user: ARM-FDPIC: Add support of FDPIC for ARM.
linux-user: ARM-FDPIC: Add support for signals for FDPIC targets
linux-user: ARM-FDPIC: Add arm get tls syscall support
configure | 10 +++++
include/elf.h | 1 +
linux-user/arm/target_syscall.h | 1 +
linux-user/elfload.c | 35 ++++++++++++++++
linux-user/main.c | 8 ++++
linux-user/qemu.h | 3 ++
linux-user/signal.c | 91 +++++++++++++++++++++++++++++++++++++----
target/arm/cpu.h | 6 +++
8 files changed, 147 insertions(+), 8 deletions(-)
--
2.6.3
On 6 April 2018 at 16:17, Christophe Lyon <christophe.lyon@st.com> wrote: > Hello, > > This patch series implements the QEMU contribution of the FDPIC > ABI for ARM targets. > I am currently working on updating the patches for the other toolchain > components, and will upstream them soon. This includes gcc, uclibc, > and gdb. > > This series provides support for ARM v7 and later architectures and > has been used to run the GCC tests on arm-linux-gnueabi without > regression, as well as arm-linux-uclibceabi. > > Are the QEMU patches OK for inclusion in master? Hi; I've given the patches a quick look over for structural issues, though I haven't looked too closely at the details. I think that given that the support is in Linux master I'm happy with it also going into QEMU. NB that Laurent has some patchsets outstanding which rework the linux-user code to split the per-architecture parts of signal.c and main.c into per-architecture files rather than having lots of ifdefs. Those will probably land early in the 2.13 cycle. I mention this just as a heads-up that at some point you'll find yourself with a somewhat painful rebase. PS: I'd recommend cc'ing the linux-user maintainers (listed in the MAINTAINERS file) on your next version of this patchset. thanks -- PMM
On 13/04/2018 17:18, Peter Maydell wrote: > On 6 April 2018 at 16:17, Christophe Lyon <christophe.lyon@st.com> wrote: >> Hello, >> >> This patch series implements the QEMU contribution of the FDPIC >> ABI for ARM targets. > >> I am currently working on updating the patches for the other toolchain >> components, and will upstream them soon. This includes gcc, uclibc, >> and gdb. >> >> This series provides support for ARM v7 and later architectures and >> has been used to run the GCC tests on arm-linux-gnueabi without >> regression, as well as arm-linux-uclibceabi. >> >> Are the QEMU patches OK for inclusion in master? > > Hi; I've given the patches a quick look over for structural > issues, though I haven't looked too closely at the details. > I think that given that the support is in Linux master I'm > happy with it also going into QEMU. > > NB that Laurent has some patchsets outstanding which rework > the linux-user code to split the per-architecture parts of > signal.c and main.c into per-architecture files rather than > having lots of ifdefs. Those will probably land early in the > 2.13 cycle. I mention this just as a heads-up that at some point > you'll find yourself with a somewhat painful rebase. > Thanks for the heads-up, I was unaware of that, and indeed I'd rather avoid such a rebase. > PS: I'd recommend cc'ing the linux-user maintainers (listed in > the MAINTAINERS file) on your next version of this patchset. > > thanks > -- PMM > . >
The FDPIC restorer needs to deal with a function descriptor, hence we
have to extend 'retcode' such that it can hold the instructions needed
to perform this.
The restorer sequence uses the same thumbness as the exception
handler (mainly to support Thumb-only architectures).
Co-Authored-By: Mickaël Guêné <mickael.guene@st.com>
Signed-off-by: Christophe Lyon <christophe.lyon@st.com>
diff --git a/linux-user/signal.c b/linux-user/signal.c
index 2ea3e03..75643d7 100644
--- a/linux-user/signal.c
+++ b/linux-user/signal.c
@@ -2039,13 +2039,13 @@ struct sigframe_v1
{
struct target_sigcontext sc;
abi_ulong extramask[TARGET_NSIG_WORDS-1];
- abi_ulong retcode;
+ abi_ulong retcode[4];
};
struct sigframe_v2
{
struct target_ucontext_v2 uc;
- abi_ulong retcode;
+ abi_ulong retcode[4];
};
struct rt_sigframe_v1
@@ -2054,14 +2054,14 @@ struct rt_sigframe_v1
abi_ulong puc;
struct target_siginfo info;
struct target_ucontext_v1 uc;
- abi_ulong retcode;
+ abi_ulong retcode[4];
};
struct rt_sigframe_v2
{
struct target_siginfo info;
struct target_ucontext_v2 uc;
- abi_ulong retcode;
+ abi_ulong retcode[4];
};
#define TARGET_CONFIG_CPU_32 1
@@ -2084,6 +2084,23 @@ static const abi_ulong retcodes[4] = {
SWI_SYS_RT_SIGRETURN, SWI_THUMB_RT_SIGRETURN
};
+#if defined(CONFIG_USE_FDPIC)
+/*
+ * Stub needed to make sure the FD register (r9) contains the right
+ * value.
+ */
+static const unsigned long sigreturn_fdpic_codes[3] = {
+ 0xe59fc004, /* ldr r12, [pc, #4] to read function descriptor */
+ 0xe59c9004, /* ldr r9, [r12, #4] to setup GOT */
+ 0xe59cf000 /* ldr pc, [r12] to jump into restorer */
+};
+
+static const unsigned long sigreturn_fdpic_thumb_codes[3] = {
+ 0xc008f8df, /* ldr r12, [pc, #8] to read function descriptor */
+ 0x9004f8dc, /* ldr r9, [r12, #4] to setup GOT */
+ 0xf000f8dc /* ldr pc, [r12] to jump into restorer */
+};
+#endif
static inline int valid_user_regs(CPUARMState *regs)
{
@@ -2143,7 +2160,19 @@ setup_return(CPUARMState *env, struct target_sigaction *ka,
{
abi_ulong handler = ka->_sa_handler;
abi_ulong retcode;
+
+#ifdef CONFIG_USE_FDPIC
+ int thumb;
+
+ if (env->is_fdpic) {
+ thumb = (((abi_ulong *)g2h(ka->_sa_handler))[0]) & 1;
+ } else {
+ thumb = handler & 1;
+ }
+#else
int thumb = handler & 1;
+#endif
+
uint32_t cpsr = cpsr_read(env);
cpsr &= ~CPSR_IT;
@@ -2154,8 +2183,37 @@ setup_return(CPUARMState *env, struct target_sigaction *ka,
}
if (ka->sa_flags & TARGET_SA_RESTORER) {
+#ifdef CONFIG_USE_FDPIC
+ if (env->is_fdpic) {
+ /* For FDPIC we ensure that the restorer is called with a
+ * correct r9 value. For that we need to write code on
+ * the stack that sets r9 and jumps back to restorer
+ * value.
+ */
+ if (thumb) {
+ __put_user(sigreturn_fdpic_thumb_codes[0], rc);
+ __put_user(sigreturn_fdpic_thumb_codes[1], rc + 1);
+ __put_user(sigreturn_fdpic_thumb_codes[2], rc + 2);
+ __put_user((abi_ulong)ka->sa_restorer, rc + 3);
+ } else {
+ __put_user(sigreturn_fdpic_codes[0], rc);
+ __put_user(sigreturn_fdpic_codes[1], rc + 1);
+ __put_user(sigreturn_fdpic_codes[2], rc + 2);
+ __put_user((abi_ulong)ka->sa_restorer, rc + 3);
+ }
+
+ retcode = rc_addr + thumb;
+ } else
+#endif
retcode = ka->sa_restorer;
} else {
+#ifdef CONFIG_USE_FDPIC
+ if (env->is_fdpic) {
+ qemu_log_mask(LOG_UNIMP,
+ "arm: FDPIC signal return not implemented");
+ abort();
+ } else {
+#endif
unsigned int idx = thumb;
if (ka->sa_flags & TARGET_SA_SIGINFO) {
@@ -2165,12 +2223,29 @@ setup_return(CPUARMState *env, struct target_sigaction *ka,
__put_user(retcodes[idx], rc);
retcode = rc_addr + thumb;
+#ifdef CONFIG_USE_FDPIC
+ }
+#endif
}
env->regs[0] = usig;
+#ifdef CONFIG_USE_FDPIC
+ if (env->is_fdpic) {
+ env->regs[9] = ((abi_ulong *)g2h(ka->_sa_handler))[1];
+ }
+#endif
env->regs[13] = frame_addr;
env->regs[14] = retcode;
+#ifdef CONFIG_USE_FDPIC
+ if (env->is_fdpic) {
+ env->regs[15] = ((abi_ulong *)g2h(ka->_sa_handler))[0]
+ & (thumb ? ~1 : ~3);
+ } else {
+ env->regs[15] = handler & (thumb ? ~1 : ~3);
+ }
+#else
env->regs[15] = handler & (thumb ? ~1 : ~3);
+#endif
cpsr_write(env, cpsr, CPSR_IT | CPSR_T, CPSRWriteByInstr);
}
@@ -2264,7 +2339,7 @@ static void setup_frame_v1(int usig, struct target_sigaction *ka,
__put_user(set->sig[i], &frame->extramask[i - 1]);
}
- setup_return(regs, ka, &frame->retcode, frame_addr, usig,
+ setup_return(regs, ka, frame->retcode, frame_addr, usig,
frame_addr + offsetof(struct sigframe_v1, retcode));
unlock_user_struct(frame, frame_addr, 1);
@@ -2286,7 +2361,7 @@ static void setup_frame_v2(int usig, struct target_sigaction *ka,
setup_sigframe_v2(&frame->uc, set, regs);
- setup_return(regs, ka, &frame->retcode, frame_addr, usig,
+ setup_return(regs, ka, frame->retcode, frame_addr, usig,
frame_addr + offsetof(struct sigframe_v2, retcode));
unlock_user_struct(frame, frame_addr, 1);
@@ -2341,7 +2416,7 @@ static void setup_rt_frame_v1(int usig, struct target_sigaction *ka,
__put_user(set->sig[i], &frame->uc.tuc_sigmask.sig[i]);
}
- setup_return(env, ka, &frame->retcode, frame_addr, usig,
+ setup_return(env, ka, frame->retcode, frame_addr, usig,
frame_addr + offsetof(struct rt_sigframe_v1, retcode));
env->regs[1] = info_addr;
@@ -2372,7 +2447,7 @@ static void setup_rt_frame_v2(int usig, struct target_sigaction *ka,
setup_sigframe_v2(&frame->uc, set, env);
- setup_return(env, ka, &frame->retcode, frame_addr, usig,
+ setup_return(env, ka, frame->retcode, frame_addr, usig,
frame_addr + offsetof(struct rt_sigframe_v2, retcode));
env->regs[1] = info_addr;
--
2.6.3
On 6 April 2018 at 16:17, Christophe Lyon <christophe.lyon@st.com> wrote:
> The FDPIC restorer needs to deal with a function descriptor, hence we
> have to extend 'retcode' such that it can hold the instructions needed
> to perform this.
>
> The restorer sequence uses the same thumbness as the exception
> handler (mainly to support Thumb-only architectures).
>
> Co-Authored-By: Mickaël Guêné <mickael.guene@st.com>
> Signed-off-by: Christophe Lyon <christophe.lyon@st.com>
> +#if defined(CONFIG_USE_FDPIC)
> +/*
> + * Stub needed to make sure the FD register (r9) contains the right
> + * value.
> + */
> +static const unsigned long sigreturn_fdpic_codes[3] = {
> + 0xe59fc004, /* ldr r12, [pc, #4] to read function descriptor */
> + 0xe59c9004, /* ldr r9, [r12, #4] to setup GOT */
> + 0xe59cf000 /* ldr pc, [r12] to jump into restorer */
> +};
> +
> +static const unsigned long sigreturn_fdpic_thumb_codes[3] = {
> + 0xc008f8df, /* ldr r12, [pc, #8] to read function descriptor */
> + 0x9004f8dc, /* ldr r9, [r12, #4] to setup GOT */
> + 0xf000f8dc /* ldr pc, [r12] to jump into restorer */
> +};
> +#endif
>
> static inline int valid_user_regs(CPUARMState *regs)
> {
> @@ -2143,7 +2160,19 @@ setup_return(CPUARMState *env, struct target_sigaction *ka,
> {
> abi_ulong handler = ka->_sa_handler;
> abi_ulong retcode;
> +
> +#ifdef CONFIG_USE_FDPIC
> + int thumb;
> +
> + if (env->is_fdpic) {
> + thumb = (((abi_ulong *)g2h(ka->_sa_handler))[0]) & 1;
> + } else {
> + thumb = handler & 1;
> + }
Dereferencing a pointer obtained by a raw g2h() is very likely
wrong. You want either to use one of the get_user_*() macros, or
a lock_user/__get_user/unlock_user sequence, so that you can
detect whether the guest actually has read access to the address,
and correctly handle the case where it does not.
thanks
-- PMM
© 2016 - 2024 Red Hat, Inc.