[Qemu-devel] [RFC PATCH 0/1] linux-user: Issue running applications through ld.so

[Qemu-devel] [RFC PATCH 0/1] linux-user: Issue running applications through ld.so

[Meador Inge]

Hi All,

I am running into an issue where QEMU fails to map a target executable
due to hitting the lower limit on /proc/sys/vm/mmap_min_addr.  This normally
just works because of all the nice guest base probing we have in place:

$ cat /proc/sys/vm/mmap_min_addr 
4096
$ qemu-arm ./hello.out
Hello, World!

In cases where the executable is run through the glibc loader we are not so
lucky:

$ qemu-arm /path/to/lib/ld-2.15.so --library-path /path/to/lib/ ./hello.out 
./hello.out: error while loading shared libraries: ./hello.out: failed to map
segment from shared object: Permission denied

The reason is that we successfully load the loader (since it can be put
anywhere), but later ld.so goes to map in hello.out at a fixed address
and fails because that fixed address is bellow mmap_min_addr and it is
too late to fixup the guest base.

I am able to fix the issue by probing for the guest base when needed for
shared objects.  This worked for all the test cases I threw at it
(including running the gcc and glibc test suites through QEMU).  However,
I am not all that familiar with the Linux usermode pieces and would like
some feedback.

Thoughts?
 
Meador Inge (1):
  linux-user: Probe the guest base for shared objects when needed

 linux-user/elfload.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

-- 
1.7.7.6

[Qemu-devel] [RFC PATCH 1/1] linux-user: Probe the guest base for shared objects when needed

[Meador Inge]

In some cases when running a shared library directly from QEMU
(e.g. ld.so) the guest base should still be probed so that
any images loaded later at fixed addresses by the target code
can still be mapped.

Signed-off-by: Meador Inge <meadori@codesourcery.com>
---
 linux-user/elfload.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/linux-user/elfload.c b/linux-user/elfload.c
index f3b1552..c71c287 100644
--- a/linux-user/elfload.c
+++ b/linux-user/elfload.c
@@ -1443,6 +1443,7 @@ static void probe_guest_base(const char *image_name,
                 goto exit_errmsg;
             }
         }
+        have_guest_base = 1;
         qemu_log("Relocating guest address space from 0x"
                  TARGET_ABI_FMT_lx " to 0x%lx\n",
                  loaddr, real_start);
@@ -1528,6 +1529,8 @@ static void load_elf_image(const char *image_name, int image_fd,
 
     load_addr = loaddr;
     if (ehdr->e_type == ET_DYN) {
+        if (loaddr < mmap_min_addr)
+            probe_guest_base(image_name, loaddr, hiaddr);
         /* The image indicates that it can be loaded anywhere.  Find a
            location that can hold the memory space required.  If the
            image is pre-linked, LOADDR will be non-zero.  Since we do
-- 
1.7.7.6

Re: [Qemu-devel] [RFC PATCH 1/1] linux-user: Probe the guest base for shared objects when needed

[Richard Henderson]

On 2012-06-07 13:59, Meador Inge wrote:
>      load_addr = loaddr;
>      if (ehdr->e_type == ET_DYN) {
> +        if (loaddr < mmap_min_addr)
> +            probe_guest_base(image_name, loaddr, hiaddr);

This doesn't make any sense.  loaddr is almost certainly 0, unless
you've pre-linked the ld.so image.  But the next statement is letting
the system pick the address at which the image will be loaded.

What you're actually wanting is to probe the address ranges of the
"real" program, which since this is essentially a program running a
program is not visible to us at all.

I think this is one of those cases where the -B or -R options
(or QEMU_GUEST_BASE and QEMU_RESERVED_VA env variables) are the best
way forward for whatever cpu you're emulating.  That or a change to
the target's default ld script, not to link real executables quite so 
low in the address space.


r~

Re: [Qemu-devel] [RFC PATCH 1/1] linux-user: Probe the guest base for shared objects when needed

[Meador Inge]

On 06/12/2012 09:08 AM, Richard Henderson wrote:

> On 2012-06-07 13:59, Meador Inge wrote:
>>      load_addr = loaddr;
>>      if (ehdr->e_type == ET_DYN) {
>> +        if (loaddr < mmap_min_addr)
>> +            probe_guest_base(image_name, loaddr, hiaddr);
> 
> This doesn't make any sense.  loaddr is almost certainly 0, unless
> you've pre-linked the ld.so image.  But the next statement is letting
> the system pick the address at which the image will be loaded.

It usually is.  I just want guest_base to be computed to something that
will work for cases where a fixed address image is later loaded (at which
point it is too late to compute the guest_base).  Always probing is one way I
found to do that, but as I originally said I don't know this code very well so
maybe that is not a good method.

> I think this is one of those cases where the -B or -R options
> (or QEMU_GUEST_BASE and QEMU_RESERVED_VA env variables) are the best
> way forward for whatever cpu you're emulating.  That or a change to
> the target's default ld script, not to link real executables quite so 
> low in the address space.

Hmmm, OK.  I was really hoping to have something more automatic.  Perhaps
I will have to use the options.

Thanks for the review.

-- 
Meador Inge
CodeSourcery / Mentor Embedded
http://www.mentor.com/embedded-software