qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC PATCH] vl.c: add -semihosting-config "arg" sub-arg


From: Liviu Ionescu
Subject: Re: [Qemu-devel] [RFC PATCH] vl.c: add -semihosting-config "arg" sub-argument
Date: Thu, 2 Apr 2015 11:29:10 +0300

> On 02 Apr 2015, at 10:56, Leon Alrae <address@hidden> wrote:
> 
> ... The UHI semihosting supports Argn syscall which returns single argument,
> and Argn is called multiple times to build argv (each argument can
> contain whitespaces).

ok, I don't want to comment too much on UHI design, since I'm not familiar 
with; at first sight it seems an improvement, but at second sight, from the 
user perspective, with your implementation, it looks overkill; all shells I 
know accept a single command line string, possibly with quotes if substrings 
need to preserve the separator spaces, and internally the shells themselves 
split the string into substrings and pass them to the application as (argc, 
argv).

in my opinion, if UHI semihosting supports single argument Argn syscalls, then 
it is the responsibility of the debugger (qemu in our case) to parse the 
command line and to provide the individual substrings in the desired format, 
and not ask the user to do this task manually.

the ARM semihosting case, being more primitive in this respect, requires to run 
the code to split the line inside the debugged application.

as an example, the projects generated by my GNU ARM Eclipse templates use

https://sourceforge.net/p/micro-os-plus/iii/ci/master/tree/packages/portable/newlib.pack/src/newlib/_syscalls.c

which, at line 419, has an __initialize_args() function.

this is simplistic, to meet the bare metal limitations, but seems functional.

I guess something similar, but more elaborate, can be added to qemu for UHI 
semihosting.

> I believe having just one flexible command line option in QEMU
> satisfying these two cases would be ideal. But if arg doesn't suit your
> needs then as Matthew already mentioned we probably should go for having
> cmdline and arg mutually exclusive.

from the user point of view, I still do not see the advantages of multiple 
arg=, it is easier to use quotes in a complete command line, like in any shell; 
so my vote still goes to cmdline=.


regards,

Liviu




reply via email to

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