qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Christophe Lyon <christophe.lyon@st.com>
To: qemu-devel@nongnu.org, christophe.lyon@linaro.org,
	peter.maydell@linaro.org, riku.voipio@iki.fi, laurent@vivier.eu
Subject: [Qemu-devel] [ARM/FDPIC v4 3/4] linux-user: ARM-FDPIC: Add support of FDPIC for ARM.
Date: Mon, 30 Apr 2018 10:03:43 +0200	[thread overview]
Message-ID: <20180430080404.7323-4-christophe.lyon@st.com> (raw)
In-Reply-To: <20180430080404.7323-1-christophe.lyon@st.com>

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

  parent reply	other threads:[~2018-04-30  8:05 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-30  8:03 [Qemu-devel] [ARM/FDPIC v4 0/4] FDPIC ABI for ARM Christophe Lyon
2018-04-30  8:03 ` [Qemu-devel] [ARM/FDPIC v4 1/4] Remove CONFIG_USE_FDPIC Christophe Lyon
2018-04-30  8:03 ` [Qemu-devel] [ARM/FDPIC v4 2/4] linux-user: ARM-FDPIC: Identify ARM FDPIC binaries Christophe Lyon
2018-04-30  8:03 ` Christophe Lyon [this message]
2018-04-30  8:03 ` [Qemu-devel] [ARM/FDPIC v4 4/4] linux-user: ARM-FDPIC: Add support for signals for FDPIC targets Christophe Lyon
2018-04-30  8:11 ` [Qemu-devel] [ARM/FDPIC v4 0/4] FDPIC ABI for ARM Peter Maydell
2018-04-30  8:40   ` Christophe Lyon
2018-04-30  8:59     ` Peter Maydell
2018-04-30  9:08       ` Christophe Lyon
2018-04-30  9:12         ` Peter Maydell
2018-04-30  9:28           ` Laurent Vivier
2018-04-30  9:46             ` Peter Maydell
2018-04-30  9:47               ` Laurent Vivier
2018-04-30 12:03               ` Laurent Vivier
2018-05-02  8:38                 ` Christophe Lyon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180430080404.7323-4-christophe.lyon@st.com \
    --to=christophe.lyon@st.com \
    --cc=christophe.lyon@linaro.org \
    --cc=laurent@vivier.eu \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=riku.voipio@iki.fi \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).