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

[Matthew Fortune]

Liviu Ionescu <address@hidden> writes:
> > On 01 Apr 2015, at 16:18, Leon Alrae <address@hidden> wrote:
> >
> > ... This simple patch adds "arg" sub-argument which in my opinion is
> > flexible enough to satisfy semi-hosting interfaces which allocate
> > buffers at runtime (so it is possible to pass any number of strings of
> > any length) as well as the ones which have limited buffer for a single
> input string.
> 
> I'm not sure I understand this.
> 
> the ARM semihosting interface (see below for the specs) uses a single

Please bear in mind that ARM is not the only architecture with a well
defined semi-hosting interface. MIPS latest semihosting interface (UHI)
can support passing of arguments with spaces for such cases where that
has value. There is also support for obtaining the argument vectors at
runtime and allocating space from a stack for storage which removes
the size limitation. UHI does of course still support the simple case of
an argument vector being pre-allocated with simple argc/argv being passed
in.

> buffer, usually of 80 bytes for embedded applications, that must be
> entirely allocated before the call, and in this buffer a single null
> terminated string is returned, assuming the buffer is large enough,
> otherwise -1 is returned.
> 
> what the semihosting debugger (qemu in our case) must do, is to get this
> string from somewhere, preferably from the command line, and pass it to
> the debugged application.
> 
> 
> to me, the natural implementation is to use a single string.

When the semihosting naturally just supports a single string then that of
course makes sense but I'm sure we can get all use-cases catered for
without adding extra steps for anyone.

> can you explain what are the advantages of handling multiple strings
> that must be later concatenated with spaces separators, to compose the
> full command line?

For the use cases where they are not concatenated together and retain
spaces embedded in an argument. This also avoids carving up the command
line in target code and moves it to the host.

> in other words, why is it better to define something like
> 
>   "gcm --gtest_output=xml:gcm.xml --gtest_filter=FooTest.* --
> gtest_repeat=10"
> 
> as
> 
>   -semihosting-config target=native,arg="gcm",arg="--
> gtest_output=xml:gcm.xml",arg="--gtest_filter=FooTest.*",arg="--
> gtest_repeat=10"
> 
> instead of
> 
>   -semihosting-config target=native,cmdline="gcm --
> gtest_output=xml:gcm.xml --gtest_filter=FooTest.* --gtest_repeat=10"
> 
> (the example if from the Google Test infrastructure).
> 
> please note that the command line is generally passed to the test from
> an upper layer, and, in your case, it needs to be parsed, split into
> substrings, and these substrings be surrounded by ,arg="%s".
> 
> for my use case, this solution is not convenient at all.

I don't see any need to remove the 'cmdline' option but just make the use
of it mutually exclusive to using 'arg'. That seems like it would address
all the issues?

Thanks,
Matthew

> 
> 
> regards,
> 
> Liviu
> 
> 
> 
> SYS_GET_CMDLINE (0x15)
> Returns the command line used to call the executable, that is, argc and
> argv.
> 
> Entry
> -----
> On entry, R1 points to a two-word data block to be used for returning
> the command string and its length:
> 
> word 1
>       a pointer to a buffer of at least the size specified in word two
> 
> word 2
>       the length of the buffer in bytes.
> 
> Return
> ------
> On exit:
> 
> Register R1 points to a two-word data block:
> 
> word 1
>       a pointer to null-terminated string of the command line word 2
>       the length of the string.
> 
> The debug agent might impose limits on the maximum length of the string
> that can be transferred. However, the agent must be able to transfer a
> command line of at least 80 bytes.
> 
> Register R0 contains an error code:
>       • 0 if the call is successful
>       • -1 if the call is not successful, for example, because of a
> communications error.
> 
>