qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "J. Mayer" <l_indien@magic.fr>
To: qemu-devel@nongnu.org
Subject: [Qemu-devel] ELF loader fix
Date: Thu, 05 Apr 2007 22:04:25 +0200	[thread overview]
Message-ID: <1175803466.5576.23.camel@rapid> (raw)

[-- Attachment #1: Type: text/plain, Size: 418 bytes --]

It appears that the start_data is not well computed in Qemu:
it's set to the end_code value, which does not follow what the Linux
kernel does.
Here's a patch that fix this issue. But as it may affect ARM emulated
target (at least those with no MMU, as noticed in the patch), I prefer
to let people that do know ARM better check what this patch may break in
this case.

-- 
J. Mayer <l_indien@magic.fr>
Never organized

[-- Attachment #2: elfload.diff --]
[-- Type: text/x-patch, Size: 2055 bytes --]

Index: linux-user/elfload.c
===================================================================
RCS file: /sources/qemu/qemu/linux-user/elfload.c,v
retrieving revision 1.39
diff -u -d -d -p -r1.39 elfload.c
--- linux-user/elfload.c	5 Apr 2007 07:13:51 -0000	1.39
+++ linux-user/elfload.c	5 Apr 2007 19:58:35 -0000
@@ -106,6 +128,7 @@ static inline void init_thread(struct ta
     /* XXX: it seems that r0 is zeroed after ! */
     regs->ARM_r0 = 0;
     /* For uClinux PIC binaries.  */
+    /* XXX: Linux does this only on ARM with no MMU (do we care ?) */
     regs->ARM_r10 = infop->start_data;
 }
 
@@ -916,7 +939,7 @@ int load_elf_binary(struct linux_binprm 
     char * elf_interpreter;
     unsigned long elf_entry, interp_load_addr = 0;
     int status;
-    unsigned long start_code, end_code, end_data;
+    unsigned long start_code, end_code, start_data, end_data;
     unsigned long elf_stack;
     char passed_fileno[6];
 
@@ -977,6 +1000,7 @@ int load_elf_binary(struct linux_binprm 
     elf_interpreter = NULL;
     start_code = ~0UL;
     end_code = 0;
+    start_data = 0;
     end_data = 0;
 
     for(i=0;i < elf_ex.e_phnum; i++) {
@@ -1186,6 +1210,8 @@ int load_elf_binary(struct linux_binprm 
         k = elf_ppnt->p_vaddr;
         if (k < start_code) 
             start_code = k;
+        if (start_data < k)
+            start_data = k;
         k = elf_ppnt->p_vaddr + elf_ppnt->p_filesz;
         if (k > elf_bss) 
             elf_bss = k;
@@ -1202,7 +1228,7 @@ int load_elf_binary(struct linux_binprm 
     elf_brk += load_bias;
     start_code += load_bias;
     end_code += load_bias;
-    //    start_data += load_bias;
+    start_data += load_bias;
     end_data += load_bias;
 
     if (elf_interpreter) {
@@ -1247,7 +1273,7 @@ int load_elf_binary(struct linux_binprm 
     info->start_brk = info->brk = elf_brk;
     info->end_code = end_code;
     info->start_code = start_code;
-    info->start_data = end_code;
+    info->start_data = start_data;
     info->end_data = end_data;
     info->start_stack = bprm->p;
 

                 reply	other threads:[~2007-04-05 20:08 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=1175803466.5576.23.camel@rapid \
    --to=l_indien@magic.fr \
    --cc=qemu-devel@nongnu.org \
    /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).