[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] qemu qemu-doc.texi
From: |
Wolfgang Schildbach |
Subject: |
Re: [Qemu-devel] qemu qemu-doc.texi |
Date: |
Mon, 19 Jun 2006 16:47:24 +0200 |
Hi Paul,
Thanks for the explanation. I feel like fixing the alignment issue in the
qemu code is a little above my head right now. However, it turns out that
the alignment issue can be solved on the arm compiler/linker side, by
giving appropriate arguments to the linker (--ro-base 0x8034). The
"missing command line issue" can be attributed to the fact that the
corresponding ARM semihosting function was not implemented.
The patch below implements the SYS_GET_CMDLINE semihosting call, by
keeping a global pointer to the user space commandline arguments, and by
re-building a space-separated command line in the guest side supplied
buffer. This patch has two shortcomings:
- I am keeping a global pointer in order to have a handle on the command
line arguments inside do_arm_semihosting. Is there a better place to keep
this?
- The ARM (guest) side supplied buffer is only 256 bytes long; if the user
supplied command line is larger, the semihosting call will fail
(gracefully). A better strategy may be to build the string on the initial
guest stack (similar to loader_build_argptgr()) and then hand that pointer
to the guest.
I am not quite sure whether the ARGS[] array should be locked before
access (then again, none of the functions in do_arm_semihosting() do
this).
Anyhow, with the patch below (and the linker flags above), I can
successfully execute ADS/RVCT compiled binaries, together with command
line arguments, both little- and bigendian.
All comments welcome.
- Wolfgang
Paul Brook <address@hidden> wrote on 12.06.2006 18:47:12:
> > Where would I (start to) look for the reasons behind this? Is this
> > something that needs to be "fixed" on the ARM side (i.e. fix the
location
> > where the ARM code looks for the environment)?
>
> Look at the code in load_elf_binary that uses target_mmap to map
theloadable
> segments into memory. The page size I'm referring to below is the target
page
> size (4k for qemu-arm). target_mmap is more-or-less a wrapper around
normal
> mmap that deals with the corner cases and differences in page size when
> host != target.
>
> There are two issues:
> - mmap requires the file offset be a multiple of the page size. This is
> relatively easy to fix. If the file data is misaligned create an
anonymous
> mapping and pread the data.
>
> - The code assumes the VMA of the segments after roundind to a page
boundary
> do not overlap. ie. a single memory page will contain data from no more
than
> one segment. Fixing this is more complicated and probably involves
merging
> the regions used by sections with "overlapping" pages.
>
> Paul
--
Wolfgang Schildbach, Senior Research Engineer
Coding Technologies GmbH
arm_semihosting_commandline.diff
Description: Binary data