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).