[Qemu-devel] [ARM/FDPIC v4 0/4] FDPIC ABI for ARM

[Qemu-devel] [ARM/FDPIC v4 0/4] FDPIC ABI for ARM

[Christophe Lyon]

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.

v3->v4:
- Fix nits in patch #3.

v2->v3:
- Do not add the is_fdpic field to TaskState, as the information can
  be retrieved from the 'info' data in TaskState.
- Setup_return() now returns an error if the FDPIC function
  description isn't readable. Callers of setup_return() are updated to
  force_sigsegv in such cases.

v1->v2:
- Patch #1 removes CONFIG_USE_FDPIC
- Patch #2 corresponds to the previous patch #1, and is now simpler
  without configure option
- Patch #3 corresponds to the previous patch #2, and uses TaskState
  instead of CPUARMState
- patch #4 corresponds to the previous patch #3, and fixes guest
  pointer dereferencing

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):
  Remove CONFIG_USE_FDPIC.
  linux-user: ARM-FDPIC: Identify ARM FDPIC binaries
  linux-user: ARM-FDPIC: Add support of FDPIC for ARM.
  linux-user: ARM-FDPIC: Add support for signals for FDPIC targets

 include/elf.h        |   1 +
 linux-user/elfload.c |  54 ++++++++++++++++++++------
 linux-user/qemu.h    |  13 ++++++-
 linux-user/signal.c  | 105 +++++++++++++++++++++++++++++++++++++++++++--------
 4 files changed, 144 insertions(+), 29 deletions(-)

-- 
2.6.3

[Qemu-devel] [ARM/FDPIC v4 1/4] Remove CONFIG_USE_FDPIC.

[Christophe Lyon]

We want to avoid code disabled by default, because it ends up less
tested. This patch removes all instances of #ifdef CONFIG_USE_FDPIC,
most of which can be safely kept. For the ones that should be
conditionally executed, we define elf_is_fdpic(). Without this patch,
defining CONFIG_USE_FDPIC would prevent QEMU from building precisely
because elf_is_fdpic is not defined.

Signed-off-by: Christophe Lyon <christophe.lyon@st.com>

diff --git a/linux-user/elfload.c b/linux-user/elfload.c
index c77ed1b..bbe93b0 100644
--- a/linux-user/elfload.c
+++ b/linux-user/elfload.c
@@ -1681,7 +1681,12 @@ static void zero_bss(abi_ulong elf_bss, abi_ulong last_bss, int prot)
     }
 }
 
-#ifdef CONFIG_USE_FDPIC
+/* Default implementation, always false.  */
+static int elf_is_fdpic(struct elfhdr *exec)
+{
+    return 0;
+}
+
 static abi_ulong loader_build_fdpic_loadmap(struct image_info *info, abi_ulong sp)
 {
     uint16_t n;
@@ -1706,7 +1711,6 @@ static abi_ulong loader_build_fdpic_loadmap(struct image_info *info, abi_ulong s
 
     return sp;
 }
-#endif
 
 static abi_ulong create_elf_tables(abi_ulong p, int argc, int envc,
                                    struct elfhdr *exec,
@@ -1725,7 +1729,6 @@ static abi_ulong create_elf_tables(abi_ulong p, int argc, int envc,
 
     sp = p;
 
-#ifdef CONFIG_USE_FDPIC
     /* Needs to be before we load the env/argc/... */
     if (elf_is_fdpic(exec)) {
         /* Need 4 byte alignment for these structs */
@@ -1737,7 +1740,6 @@ static abi_ulong create_elf_tables(abi_ulong p, int argc, int envc,
             sp = loader_build_fdpic_loadmap(interp_info, sp);
         }
     }
-#endif
 
     u_platform = 0;
     k_platform = ELF_PLATFORM;
@@ -2153,10 +2155,8 @@ static void load_elf_image(const char *image_name, int image_fd,
     }
     bswap_phdr(phdr, ehdr->e_phnum);
 
-#ifdef CONFIG_USE_FDPIC
     info->nsegs = 0;
     info->pt_dynamic_addr = 0;
-#endif
 
     mmap_lock();
 
@@ -2173,9 +2173,7 @@ static void load_elf_image(const char *image_name, int image_fd,
             if (a > hiaddr) {
                 hiaddr = a;
             }
-#ifdef CONFIG_USE_FDPIC
             ++info->nsegs;
-#endif
         }
     }
 
@@ -2200,8 +2198,7 @@ static void load_elf_image(const char *image_name, int image_fd,
     }
     load_bias = load_addr - loaddr;
 
-#ifdef CONFIG_USE_FDPIC
-    {
+    if (elf_is_fdpic(ehdr)) {
         struct elf32_fdpic_loadseg *loadsegs = info->loadsegs =
             g_malloc(sizeof(*loadsegs) * info->nsegs);
 
@@ -2219,7 +2216,6 @@ static void load_elf_image(const char *image_name, int image_fd,
             }
         }
     }
-#endif
 
     info->load_bias = load_bias;
     info->load_addr = load_addr;
diff --git a/linux-user/qemu.h b/linux-user/qemu.h
index 192a0d2..da3b517 100644
--- a/linux-user/qemu.h
+++ b/linux-user/qemu.h
@@ -51,13 +51,13 @@ struct image_info {
         abi_ulong       file_string;
         uint32_t        elf_flags;
 	int		personality;
-#ifdef CONFIG_USE_FDPIC
+
+        /* The fields below are used in FDPIC mode.  */
         abi_ulong       loadmap_addr;
         uint16_t        nsegs;
         void           *loadsegs;
         abi_ulong       pt_dynamic_addr;
         struct image_info *other_info;
-#endif
 };
 
 #ifdef TARGET_I386
-- 
2.6.3

[Qemu-devel] [ARM/FDPIC v4 2/4] linux-user: ARM-FDPIC: Identify ARM FDPIC binaries

[Christophe Lyon]

Define an ARM-specific version of elf_is_fdpic:
FDPIC ELF objects are identified with e_ident[EI_OSABI] ==
ELFOSABI_ARM_FDPIC.

Co-Authored-By: Mickaël Guêné <mickael.guene@st.com>
Signed-off-by: Christophe Lyon <christophe.lyon@st.com>

diff --git a/include/elf.h b/include/elf.h
index c0dc9bb..934dbbd 100644
--- a/include/elf.h
+++ b/include/elf.h
@@ -1483,6 +1483,7 @@ typedef struct elf64_shdr {
 #define ELFOSABI_TRU64          10      /* Compaq TRU64 UNIX.  */
 #define ELFOSABI_MODESTO        11      /* Novell Modesto.  */
 #define ELFOSABI_OPENBSD        12      /* OpenBSD.  */
+#define ELFOSABI_ARM_FDPIC      65      /* ARM FDPIC */
 #define ELFOSABI_ARM            97      /* ARM */
 #define ELFOSABI_STANDALONE     255     /* Standalone (embedded) application */
 
diff --git a/linux-user/elfload.c b/linux-user/elfload.c
index bbe93b0..76d7718 100644
--- a/linux-user/elfload.c
+++ b/linux-user/elfload.c
@@ -1681,11 +1681,18 @@ static void zero_bss(abi_ulong elf_bss, abi_ulong last_bss, int prot)
     }
 }
 
+#ifdef TARGET_ARM
+static int elf_is_fdpic(struct elfhdr *exec)
+{
+    return exec->e_ident[EI_OSABI] == ELFOSABI_ARM_FDPIC;
+}
+#else
 /* Default implementation, always false.  */
 static int elf_is_fdpic(struct elfhdr *exec)
 {
     return 0;
 }
+#endif
 
 static abi_ulong loader_build_fdpic_loadmap(struct image_info *info, abi_ulong sp)
 {
-- 
2.6.3

[Qemu-devel] [ARM/FDPIC v4 3/4] linux-user: ARM-FDPIC: Add support of FDPIC for ARM.

[Christophe Lyon]

Add FDPIC info into image_info structure since interpreter info is on
stack and needs to be saved to be accessed later on.

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/elfload.c b/linux-user/elfload.c
index 76d7718..36d5219 100644
--- a/linux-user/elfload.c
+++ b/linux-user/elfload.c
@@ -78,6 +78,11 @@ enum {
  */
 #define personality(pers)       (pers & PER_MASK)
 
+int info_is_fdpic(struct image_info *info)
+{
+    return info->personality == PER_LINUX_FDPIC;
+}
+
 /* this flag is uneffective under linux too, should be deleted */
 #ifndef MAP_DENYWRITE
 #define MAP_DENYWRITE 0
@@ -287,6 +292,25 @@ static inline void init_thread(struct target_pt_regs *regs,
     /* For uClinux PIC binaries.  */
     /* XXX: Linux does this only on ARM with no MMU (do we care ?) */
     regs->uregs[10] = infop->start_data;
+
+    /* Support ARM FDPIC.  */
+    if (info_is_fdpic(infop)) {
+        /* As described in the ABI document, r7 points to the loadmap info
+         * prepared by the kernel. If an interpreter is needed, r8 points
+         * to the interpreter loadmap and r9 points to the interpreter
+         * PT_DYNAMIC info. If no interpreter is needed, r8 is zero, and
+         * r9 points to the main program PT_DYNAMIC info.
+         */
+        regs->uregs[7] = infop->loadmap_addr;
+        if (infop->interpreter_loadmap_addr) {
+            /* Executable is dynamically loaded.  */
+            regs->uregs[8] = infop->interpreter_loadmap_addr;
+            regs->uregs[9] = infop->interpreter_pt_dynamic_addr;
+        } else {
+            regs->uregs[8] = 0;
+            regs->uregs[9] = infop->pt_dynamic_addr;
+        }
+    }
 }
 
 #define ELF_NREG    18
@@ -1745,6 +1769,11 @@ static abi_ulong create_elf_tables(abi_ulong p, int argc, int envc,
         if (interp_info) {
             interp_info->other_info = info;
             sp = loader_build_fdpic_loadmap(interp_info, sp);
+            info->interpreter_loadmap_addr = interp_info->loadmap_addr;
+            info->interpreter_pt_dynamic_addr = interp_info->pt_dynamic_addr;
+        } else {
+            info->interpreter_loadmap_addr = 0;
+            info->interpreter_pt_dynamic_addr = 0;
         }
     }
 
diff --git a/linux-user/qemu.h b/linux-user/qemu.h
index da3b517..c55c8e2 100644
--- a/linux-user/qemu.h
+++ b/linux-user/qemu.h
@@ -57,6 +57,8 @@ struct image_info {
         uint16_t        nsegs;
         void           *loadsegs;
         abi_ulong       pt_dynamic_addr;
+        abi_ulong       interpreter_loadmap_addr;
+        abi_ulong       interpreter_pt_dynamic_addr;
         struct image_info *other_info;
 };
 
@@ -183,6 +185,13 @@ int loader_exec(int fdexec, const char *filename, char **argv, char **envp,
              struct target_pt_regs * regs, struct image_info *infop,
              struct linux_binprm *);
 
+/* Returns true if the image uses the FDPIC ABI. If this is the case,
+ * we have to provide some information (loadmap, pt_dynamic_info) such
+ * that the program can be relocated adequately. This is also useful
+ * when handling signals.
+ */
+int info_is_fdpic(struct image_info *info);
+
 uint32_t get_elf_eflags(int fd);
 int load_elf_binary(struct linux_binprm *bprm, struct image_info *info);
 int load_flt_binary(struct linux_binprm *bprm, struct image_info *info);
-- 
2.6.3

[Qemu-devel] [ARM/FDPIC v4 4/4] linux-user: ARM-FDPIC: Add support for signals for FDPIC targets

[Christophe Lyon]

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 8d9e6e8..6dbc699 100644
--- a/linux-user/signal.c
+++ b/linux-user/signal.c
@@ -2045,13 +2045,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
@@ -2060,14 +2060,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
@@ -2090,6 +2090,21 @@ static const abi_ulong retcodes[4] = {
 	SWI_SYS_RT_SIGRETURN,	SWI_THUMB_RT_SIGRETURN
 };
 
+/*
+ * 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 */
+};
 
 static inline int valid_user_regs(CPUARMState *regs)
 {
@@ -2143,13 +2158,33 @@ get_sigframe(struct target_sigaction *ka, CPUARMState *regs, int framesize)
     return (sp - framesize) & ~7;
 }
 
-static void
+static int
 setup_return(CPUARMState *env, struct target_sigaction *ka,
              abi_ulong *rc, abi_ulong frame_addr, int usig, abi_ulong rc_addr)
 {
-    abi_ulong handler = ka->_sa_handler;
+    abi_ulong handler = 0;
+    abi_ulong handler_fdpic_GOT = 0;
     abi_ulong retcode;
-    int thumb = handler & 1;
+
+    int thumb;
+    int is_fdpic = info_is_fdpic(((TaskState *)thread_cpu->opaque)->info);
+
+    if (is_fdpic) {
+        /* In FDPIC mode, ka->_sa_handler points to a function
+         * descriptor (FD). The first word contains the address of the
+         * handler. The second word contains the value of the PIC
+         * register (r9).  */
+        abi_ulong funcdesc_ptr = ka->_sa_handler;
+        if (get_user_ual(handler, funcdesc_ptr)
+            || get_user_ual(handler_fdpic_GOT, funcdesc_ptr + 4)) {
+            return 1;
+        }
+    } else {
+        handler = ka->_sa_handler;
+    }
+
+    thumb = handler & 1;
+
     uint32_t cpsr = cpsr_read(env);
 
     cpsr &= ~CPSR_IT;
@@ -2160,7 +2195,28 @@ setup_return(CPUARMState *env, struct target_sigaction *ka,
     }
 
     if (ka->sa_flags & TARGET_SA_RESTORER) {
-        retcode = ka->sa_restorer;
+        if (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 {
+            retcode = ka->sa_restorer;
+        }
     } else {
         unsigned int idx = thumb;
 
@@ -2174,10 +2230,15 @@ setup_return(CPUARMState *env, struct target_sigaction *ka,
     }
 
     env->regs[0] = usig;
+    if (is_fdpic) {
+        env->regs[9] = handler_fdpic_GOT;
+    }
     env->regs[13] = frame_addr;
     env->regs[14] = retcode;
     env->regs[15] = handler & (thumb ? ~1 : ~3);
     cpsr_write(env, cpsr, CPSR_IT | CPSR_T, CPSRWriteByInstr);
+
+    return 0;
 }
 
 static abi_ulong *setup_sigframe_v2_vfp(abi_ulong *regspace, CPUARMState *env)
@@ -2270,12 +2331,15 @@ 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,
-                 frame_addr + offsetof(struct sigframe_v1, retcode));
+    if (setup_return(regs, ka, frame->retcode, frame_addr, usig,
+                     frame_addr + offsetof(struct sigframe_v1, retcode))) {
+        goto sigsegv;
+    }
 
     unlock_user_struct(frame, frame_addr, 1);
     return;
 sigsegv:
+    unlock_user_struct(frame, frame_addr, 1);
     force_sigsegv(usig);
 }
 
@@ -2292,12 +2356,15 @@ 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,
-                 frame_addr + offsetof(struct sigframe_v2, retcode));
+    if (setup_return(regs, ka, frame->retcode, frame_addr, usig,
+                     frame_addr + offsetof(struct sigframe_v2, retcode))) {
+        goto sigsegv;
+    }
 
     unlock_user_struct(frame, frame_addr, 1);
     return;
 sigsegv:
+    unlock_user_struct(frame, frame_addr, 1);
     force_sigsegv(usig);
 }
 
@@ -2347,8 +2414,10 @@ 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,
-                 frame_addr + offsetof(struct rt_sigframe_v1, retcode));
+    if (setup_return(env, ka, frame->retcode, frame_addr, usig,
+                     frame_addr + offsetof(struct rt_sigframe_v1, retcode))) {
+        goto sigsegv;
+    }
 
     env->regs[1] = info_addr;
     env->regs[2] = uc_addr;
@@ -2356,6 +2425,7 @@ static void setup_rt_frame_v1(int usig, struct target_sigaction *ka,
     unlock_user_struct(frame, frame_addr, 1);
     return;
 sigsegv:
+    unlock_user_struct(frame, frame_addr, 1);
     force_sigsegv(usig);
 }
 
@@ -2378,8 +2448,10 @@ 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,
-                 frame_addr + offsetof(struct rt_sigframe_v2, retcode));
+    if (setup_return(env, ka, frame->retcode, frame_addr, usig,
+                     frame_addr + offsetof(struct rt_sigframe_v2, retcode))) {
+        goto sigsegv;
+    }
 
     env->regs[1] = info_addr;
     env->regs[2] = uc_addr;
@@ -2387,6 +2459,7 @@ static void setup_rt_frame_v2(int usig, struct target_sigaction *ka,
     unlock_user_struct(frame, frame_addr, 1);
     return;
 sigsegv:
+    unlock_user_struct(frame, frame_addr, 1);
     force_sigsegv(usig);
 }
 
-- 
2.6.3

Re: [Qemu-devel] [ARM/FDPIC v4 0/4] FDPIC ABI for ARM

[Peter Maydell]

On 30 April 2018 at 09:03, Christophe Lyon <christophe.lyon@st.com> wrote:
> Hello,
>
> This patch series implements the QEMU contribution of the FDPIC
> ABI for ARM targets.

Hi; I definitely reviewed at least some of these patches,
but this respin seems to have lost all the reviewed-by tags?

thanks
-- PMM

Re: [Qemu-devel] [ARM/FDPIC v4 0/4] FDPIC ABI for ARM

[Christophe Lyon]

On 30 April 2018 at 10:11, Peter Maydell <peter.maydell@linaro.org> wrote:
> On 30 April 2018 at 09:03, Christophe Lyon <christophe.lyon@st.com> wrote:
>> Hello,
>>
>> This patch series implements the QEMU contribution of the FDPIC
>> ABI for ARM targets.
>
> Hi; I definitely reviewed at least some of these patches,
> but this respin seems to have lost all the reviewed-by tags?
>
Indeed, I failed to include them.
Shall I send a v5 including these tags?

Sorry,

Christophe

> thanks
> -- PMM

Re: [Qemu-devel] [ARM/FDPIC v4 0/4] FDPIC ABI for ARM

[Peter Maydell]

On 30 April 2018 at 09:40, Christophe Lyon <christophe.lyon@linaro.org> wrote:
> On 30 April 2018 at 10:11, Peter Maydell <peter.maydell@linaro.org> wrote:
>> On 30 April 2018 at 09:03, Christophe Lyon <christophe.lyon@st.com> wrote:
>>> Hello,
>>>
>>> This patch series implements the QEMU contribution of the FDPIC
>>> ABI for ARM targets.
>>
>> Hi; I definitely reviewed at least some of these patches,
>> but this respin seems to have lost all the reviewed-by tags?
>>
> Indeed, I failed to include them.
> Shall I send a v5 including these tags?

No, but if you can check which ones should have them that would
be helpful.

thanks
-- PMM

Re: [Qemu-devel] [ARM/FDPIC v4 0/4] FDPIC ABI for ARM

[Christophe Lyon]

On 30 April 2018 at 10:59, Peter Maydell <peter.maydell@linaro.org> wrote:
> On 30 April 2018 at 09:40, Christophe Lyon <christophe.lyon@linaro.org> wrote:
>> On 30 April 2018 at 10:11, Peter Maydell <peter.maydell@linaro.org> wrote:
>>> On 30 April 2018 at 09:03, Christophe Lyon <christophe.lyon@st.com> wrote:
>>>> Hello,
>>>>
>>>> This patch series implements the QEMU contribution of the FDPIC
>>>> ABI for ARM targets.
>>>
>>> Hi; I definitely reviewed at least some of these patches,
>>> but this respin seems to have lost all the reviewed-by tags?
>>>
>> Indeed, I failed to include them.
>> Shall I send a v5 including these tags?
>
> No, but if you can check which ones should have them that would
> be helpful.
>
OK, so all 4 patches have
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
(you added it to patch 3/4, provided I fixed the nits, which I did in v4).

Thanks

Christophe

> thanks
> -- PMM

Re: [Qemu-devel] [ARM/FDPIC v4 0/4] FDPIC ABI for ARM

[Peter Maydell]

On 30 April 2018 at 10:08, Christophe Lyon <christophe.lyon@linaro.org> wrote:
> On 30 April 2018 at 10:59, Peter Maydell <peter.maydell@linaro.org> wrote:
>> On 30 April 2018 at 09:40, Christophe Lyon <christophe.lyon@linaro.org> wrote:
>>> On 30 April 2018 at 10:11, Peter Maydell <peter.maydell@linaro.org> wrote:
>>>> On 30 April 2018 at 09:03, Christophe Lyon <christophe.lyon@st.com> wrote:
>>>>> Hello,
>>>>>
>>>>> This patch series implements the QEMU contribution of the FDPIC
>>>>> ABI for ARM targets.
>>>>
>>>> Hi; I definitely reviewed at least some of these patches,
>>>> but this respin seems to have lost all the reviewed-by tags?
>>>>
>>> Indeed, I failed to include them.
>>> Shall I send a v5 including these tags?
>>
>> No, but if you can check which ones should have them that would
>> be helpful.
>>
> OK, so all 4 patches have
> Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
> (you added it to patch 3/4, provided I fixed the nits, which I did in v4).

Great. Riku/Laurent -- I'm assuming you're going to take this set
via the linux-user tree.

-- PMM

Re: [Qemu-devel] [ARM/FDPIC v4 0/4] FDPIC ABI for ARM

[Laurent Vivier]

Le 30/04/2018 à 11:12, Peter Maydell a écrit :
> On 30 April 2018 at 10:08, Christophe Lyon <christophe.lyon@linaro.org> wrote:
>> On 30 April 2018 at 10:59, Peter Maydell <peter.maydell@linaro.org> wrote:
>>> On 30 April 2018 at 09:40, Christophe Lyon <christophe.lyon@linaro.org> wrote:
>>>> On 30 April 2018 at 10:11, Peter Maydell <peter.maydell@linaro.org> wrote:
>>>>> On 30 April 2018 at 09:03, Christophe Lyon <christophe.lyon@st.com> wrote:
>>>>>> Hello,
>>>>>>
>>>>>> This patch series implements the QEMU contribution of the FDPIC
>>>>>> ABI for ARM targets.
>>>>>
>>>>> Hi; I definitely reviewed at least some of these patches,
>>>>> but this respin seems to have lost all the reviewed-by tags?
>>>>>
>>>> Indeed, I failed to include them.
>>>> Shall I send a v5 including these tags?
>>>
>>> No, but if you can check which ones should have them that would
>>> be helpful.
>>>
>> OK, so all 4 patches have
>> Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
>> (you added it to patch 3/4, provided I fixed the nits, which I did in v4).
> 
> Great. Riku/Laurent -- I'm assuming you're going to take this set
> via the linux-user tree.

I just sent a pull request without it...

Do you prefer I update this one or I send another one later?

Thanks,
Laurent

Re: [Qemu-devel] [ARM/FDPIC v4 0/4] FDPIC ABI for ARM

[Peter Maydell]

On 30 April 2018 at 10:28, Laurent Vivier <laurent@vivier.eu> wrote:
> Le 30/04/2018 à 11:12, Peter Maydell a écrit :
>> Great. Riku/Laurent -- I'm assuming you're going to take this set
>> via the linux-user tree.
>
> I just sent a pull request without it...
>
> Do you prefer I update this one or I send another one later?

No, it can go into your next one I think. I see you've sent
the signal.c refactoring, which this will conflict with,
so either you or Christophe will need to rebase it anyway.

thanks
-- PMM

Re: [Qemu-devel] [ARM/FDPIC v4 0/4] FDPIC ABI for ARM

[Laurent Vivier]

Le 30/04/2018 à 11:46, Peter Maydell a écrit :
> On 30 April 2018 at 10:28, Laurent Vivier <laurent@vivier.eu> wrote:
>> Le 30/04/2018 à 11:12, Peter Maydell a écrit :
>>> Great. Riku/Laurent -- I'm assuming you're going to take this set
>>> via the linux-user tree.
>>
>> I just sent a pull request without it...
>>
>> Do you prefer I update this one or I send another one later?
> 
> No, it can go into your next one I think. I see you've sent
> the signal.c refactoring, which this will conflict with,
> so either you or Christophe will need to rebase it anyway.

Yes, I will.

Thanks,
Laurent

Re: [Qemu-devel] [ARM/FDPIC v4 0/4] FDPIC ABI for ARM

[Laurent Vivier]

Le 30/04/2018 à 11:46, Peter Maydell a écrit :
> On 30 April 2018 at 10:28, Laurent Vivier <laurent@vivier.eu> wrote:
>> Le 30/04/2018 à 11:12, Peter Maydell a écrit :
>>> Great. Riku/Laurent -- I'm assuming you're going to take this set
>>> via the linux-user tree.
>>
>> I just sent a pull request without it...
>>
>> Do you prefer I update this one or I send another one later?
> 
> No, it can go into your next one I think. I see you've sent
> the signal.c refactoring, which this will conflict with,
> so either you or Christophe will need to rebase it anyway.
> 
> thanks
> -- PMM
> 

OK, I've rebased the series on top of the new master and applied to my
branch linux-user-for-2.13
(see https://github.com/vivier/qemu/tree/linux-user-for-2.13)

Thanks,
Laurent

Re: [Qemu-devel] [ARM/FDPIC v4 0/4] FDPIC ABI for ARM

[Christophe Lyon]

On 30 April 2018 at 14:03, Laurent Vivier <laurent@vivier.eu> wrote:
> Le 30/04/2018 à 11:46, Peter Maydell a écrit :
>> On 30 April 2018 at 10:28, Laurent Vivier <laurent@vivier.eu> wrote:
>>> Le 30/04/2018 à 11:12, Peter Maydell a écrit :
>>>> Great. Riku/Laurent -- I'm assuming you're going to take this set
>>>> via the linux-user tree.
>>>
>>> I just sent a pull request without it...
>>>
>>> Do you prefer I update this one or I send another one later?
>>
>> No, it can go into your next one I think. I see you've sent
>> the signal.c refactoring, which this will conflict with,
>> so either you or Christophe will need to rebase it anyway.
>>
>> thanks
>> -- PMM
>>
>
> OK, I've rebased the series on top of the new master and applied to my
> branch linux-user-for-2.13
> (see https://github.com/vivier/qemu/tree/linux-user-for-2.13)
>

For the record, I ran a smoke test with this branch and my small
example with a signal handler worked as expected.

Thanks,

Christophe

> Thanks,
> Laurent