All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wolfgang Schildbach <Wolfgang.Schildbach@codingtechnologies.com>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] qemu qemu-doc.texi
Date: Mon, 19 Jun 2006 16:47:24 +0200	[thread overview]
Message-ID: <OF322926F9.C191A3D7-ONC1257192.00501E76-C1257192.00513EE4@codingtechnologies.com> (raw)
In-Reply-To: <200606121747.13346.paul@codesourcery.com>

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

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 <paul@codesourcery.com> 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 #2: arm_semihosting_commandline.diff --]
[-- Type: application/octet-stream, Size: 2838 bytes --]

Index: linux-user/arm-semi.c
===================================================================
RCS file: /sources/qemu/qemu/linux-user/arm-semi.c,v
retrieving revision 1.5
diff -r1.5 arm-semi.c
80c80,81
< #define ARG(n) tget32(args + n * 4)
---
> #define ARG(n) tget32(args + (n) * 4)
> #define SET_ARG(n,val) tput32(args + (n) * 4,val)
161,164c162,201
<         /* XXX: Not implemented.  */
<         s = (char *)g2h(ARG(0));
<         *s = 0;
<         return -1;
---
>         /* The ARM semihosting interface requires that the commandline is
>            presented with blanks separating the arguments. Thus, we need
>            to build a new command line, given the global pointer to the
>            command line we received.
>            A better way would be to build this command line on the user stack,
>            similar to the way it is done in loader_build_argptr(), and then
>            just hand that pointer back to the caller */
>         {
>             extern char **global_userspace_argv ; /* initialized in main() */
>             char **av = global_userspace_argv ;   /* work ptr */
>             int len = ARG(1); /* amount of RAM that the ARM binary has set
>                                  aside for the command line */
>             /* lock the buffer on the ARM side */
>             char *cmdline_buffer = (char*)lock_user(ARG(0),len,0);
>             s = cmdline_buffer ;
>             do {
>                 int n = strlen(*av) ;
> 
>                 /* is there still space in the supplied buffer, including
>                    the terminating zero? */
>                 if (s - cmdline_buffer + n+1 > len)
>                     break ; /* no */
> 
>                 memcpy(s,*av,n);
>                 s += n ;
>                 *s++ = ' ';
>                 len -= n+1 ;
>                 av++;
>             } while (*av);
>             *s++ = 0; /* terminate cmdline string */
> 
>             /* unlock the buffer on the ARM side */
>             unlock_user(cmdline_buffer, ARG(0), ARG(1));
> 
>             /* adjust the commandline length argument */
>             SET_ARG(1, (uint32_t)(s - cmdline_buffer));
> 
>             /* successfull return if commandline fit into buffer */
>             return *av == 0 ? 0 : -1 ;
>         }
Index: linux-user/main.c
===================================================================
RCS file: /sources/qemu/qemu/linux-user/main.c,v
retrieving revision 1.88
diff -r1.88 main.c
312a313,315
> /* XXX: this is an ugly hack, to make argc/argv available to ARM semihosting */
> char **global_userspace_argv ;
> 
1531,1532c1534,1536
<     
<     if (loader_exec(filename, argv+optind, environ, regs, info) != 0) {
---
>     global_userspace_argv = argv + optind;
> 
>     if ((loader_exec(filename, global_userspace_argv, environ, regs, info)) != 0) {

  reply	other threads:[~2006-06-19 14:47 UTC|newest]

Thread overview: 61+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-06-11 16:28 [Qemu-devel] qemu qemu-doc.texi Paul Brook
2006-06-12 14:09 ` Wolfgang Schildbach
2006-06-12 14:18   ` Paul Brook
2006-06-12 16:17     ` Wolfgang Schildbach
2006-06-12 16:47       ` Paul Brook
2006-06-19 14:47         ` Wolfgang Schildbach [this message]
  -- strict thread matches above, loose matches on Subject: below --
2008-03-18  6:52 Aurelien Jarno
2008-03-18  6:51 Aurelien Jarno
2008-01-17 22:22 Andrzej Zaborowski
2008-01-09 12:14 Thiemo Seufer
2007-12-17  3:47 Thiemo Seufer
2007-12-17  3:38 Thiemo Seufer
2007-12-11 21:56 Andrzej Zaborowski
2007-11-26 18:46 Blue Swirl
2007-11-21 22:38 Thiemo Seufer
2007-08-25  1:40 Thiemo Seufer
2007-07-13 18:40 Thiemo Seufer
2007-07-11 21:43 Thiemo Seufer
2007-06-04  0:50 Paul Brook
2007-05-23 20:16 Paul Brook
2007-05-01 17:53 Andrzej Zaborowski
2007-02-28 16:25 Paul Brook
2007-02-19  1:23 Thiemo Seufer
2007-02-10 22:14 Thiemo Seufer
2007-02-05 19:42 Fabrice Bellard
2007-02-05 19:38 Fabrice Bellard
2006-12-11 18:35 Thiemo Seufer
2006-09-20 20:28 Fabrice Bellard
2006-09-03 17:10 Fabrice Bellard
2006-08-21 20:28 Fabrice Bellard
2006-08-21 20:26 Fabrice Bellard
2006-08-19 16:56 Fabrice Bellard
2006-08-07 21:34 Fabrice Bellard
2006-06-21 21:19 Fabrice Bellard
2006-06-16 21:48 Paul Brook
2006-06-14 18:35 Fabrice Bellard
2006-05-26  0:49 Paul Brook
2006-05-13 16:55 Paul Brook
2006-05-06 14:23 Fabrice Bellard
2006-04-23 21:57 Fabrice Bellard
2006-04-16 18:46 Paul Brook
2006-03-31 21:17 Fabrice Bellard
2006-02-20  0:35 Paul Brook
2006-02-01 21:30 Fabrice Bellard
2005-12-19 22:12 Fabrice Bellard
2005-12-18 20:11 Fabrice Bellard
2005-11-19 17:42 Fabrice Bellard
2005-07-28 22:27 Fabrice Bellard
2005-07-03 17:34 Fabrice Bellard
2005-06-05 16:48 Fabrice Bellard
2005-03-13  9:43 Fabrice Bellard
2005-02-20 19:09 Fabrice Bellard
2005-02-12 15:16 Fabrice Bellard
2005-02-12 15:02 Fabrice Bellard
2004-12-13 20:07 Fabrice Bellard
2003-10-28  1:38 Fabrice Bellard
2003-10-28  0:48 Fabrice Bellard
2003-07-13 22:37 Fabrice Bellard
2003-07-06 19:01 Fabrice Bellard
2003-06-30 23:16 Fabrice Bellard
2003-06-27 18:50 Fabrice Bellard

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=OF322926F9.C191A3D7-ONC1257192.00501E76-C1257192.00513EE4@codingtechnologies.com \
    --to=wolfgang.schildbach@codingtechnologies.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.