qemu-devel
[Top][All Lists]
Advanced

[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

Attachment: arm_semihosting_commandline.diff
Description: Binary data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]