From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58076) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yfsig-0005I0-EY for qemu-devel@nongnu.org; Wed, 08 Apr 2015 12:20:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Yfsic-0007Gg-RW for qemu-devel@nongnu.org; Wed, 08 Apr 2015 12:20:50 -0400 Received: from mailapp01.imgtec.com ([195.59.15.196]:28560) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yfsic-0007G5-0S for qemu-devel@nongnu.org; Wed, 08 Apr 2015 12:20:46 -0400 Message-ID: <55255556.8020504@imgtec.com> Date: Wed, 8 Apr 2015 17:20:38 +0100 From: Leon Alrae MIME-Version: 1.0 References: <1427894283-31953-1-git-send-email-leon.alrae@imgtec.com> <9DE872C8-4AE3-48FC-B4A1-61ADE4DB7F32@livius.net> <551CF623.7040506@imgtec.com> <551D086D.9010604@imgtec.com> <551D1BC2.10408@imgtec.com> <1C30C43D-CD89-4EBF-991A-9CC53019ED7B@livius.net> <6D39441BF12EF246A7ABCE6654B023532101BA54@LEMAIL01.le.imgtec.org> <1741D364-48FC-4682-B660-82A5B48F8DE4@livius.net> In-Reply-To: <1741D364-48FC-4682-B660-82A5B48F8DE4@livius.net> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [RFC PATCH] vl.c: add -semihosting-config "arg" sub-argument List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Liviu Ionescu , Matthew Fortune Cc: "peter.maydell@linaro.org" , "qemu-devel@nongnu.org" , "christopher.covington@linaro.org" On 02/04/2015 17:47, Liviu Ionescu wrote: >=20 >> On 02 Apr 2015, at 17:27, Matthew Fortune = wrote: >> >> Liviu Ionescu writes: >>> for completeness: >>> >>> ilg-mbp:gnuarmeclipse-qemu.git ilg$ "/Applications/GNU ARM >>> Eclipse/QEMU/2.2.91-201504021111-dev/bin/qemu-system-gnuarmeclipse" - >>> verbose -machine STM32-H103 -gdb tcp::1234 -semihosting-config >>> enable=3Don,target=3Dnative,cmdline=3D'n "1 a" 2 3' >> >> I see here that you have switched quotes because you know that you are >> providing a double quoted argument within the string. >=20 > my code works both ways symmetrically: >=20 > ilg-mbp:~ ilg$ "/Applications/GNU ARM Eclipse"/QEMU/2.2.91-201504021111= -dev/bin/qemu-system-gnuarmeclipse -verbose -machine STM32-H103 -gdb tcp:= :1234 -semihosting-config enable=3Don,target=3Dnative,cmdline=3D"name 1 '= 2 a' 3" >=20 > GNU ARM Eclipse QEMU v2.2.91 (qemu-system-gnuarmeclipse). > Board: 'STM32-H103' (Olimex Header Board for STM32F103RBT6 (Experimenta= l)). > Device: 'STM32F103RB' (cortex-m3, MPU), Flash: 128 KB, RAM: 20 KB. > Command line: 'name 1 '2 a' 3' (14 bytes). > GDB Server listening on: 'tcp::1234'... > ... connection accepted from 127.0.0.1. >=20 > Execute 'mon system_reset'. > main(argc=3D4, argv=3D["name", "1", "2 a", "3"]); > Hello ARM World! >=20 > in other words, after being delivered by SYS_GET_CMDLINE to the applica= tion, the startup parser uses either single or double quotes to split the= string into arguments, similarly to a real life shell. >=20 >> The root of all >> argument passing issues tends to boil down to how to quote and or esca= pe >> characters appropriately. Because you know the arguments you can quote >> correctly but for an unknown user-provided set of arguments (where the= y >> do not know how their arguments will flow down to an application) then >> the appropriate quoting and escaping becomes harder. >> >> The problem characters are obviously single and double quotes. Having >> different quoting rules for any of the layers between a user and >> the emulated program is always going to cause some confusion so when >> quoting is necessary I have always found that following the standard >> argument passing rules of the native application is the least >> problematic. >=20 > I guess you are generally right, but in this case any quoting is perfec= tly fine. >=20 >> qemu-system... -semihosting-config "arg=3Dfoo bar" -semihosting-config= "arg=3Dsecond" >> >> This should give an argv of ["foo bar", "second"] >=20 > yes, but for the casual user the above syntax is already not natural an= d even more confusing: should I use "arg=3Dfoo bar" or arg=3D"foo bar"? s= hould I repeat -semihosting-config for each argument, or I can group all = together (-semihosting-config arg=3D"foo bar",arg=3D"second")? >=20 >=20 > if for your use cases this syntax is acceptable, ok, go for it. Hmm... the -semihosting-config group would be indeed unusual comparing to the other groups, but on the other hand this would solve also the double-comma problem. For simple cases the casual user can just stick to the cmdline. >=20 >=20 > my first use of qemu is as a background GDB server started by an Eclips= e plug-in. the plug-in will have a single edit field, where the user can = enter the semihosting command line args. for args that include spaces, th= e user should use either single or double quotes, as in any other field. >=20 > my preferred implemention for this would be the original -semihosting-c= mdline "some string". >=20 > both proposed implementations (-semihosting-config cmdline=3D"some-stri= ng") and even worse for the multiple (-semihosting-config arg=3Dsome-stri= ng), are way more complicated to use in my Eclipse plug-in, requiring spe= cial precautions for passing single/double quotes, commas and possibly eq= uals. >=20 > with the -semihosting-cmdline some-string, the only thing I have to do = is to pass [-semihosting-cmdline] in one string array element, and the un= modified [some-string], regardless the quoting used, as the next string a= rray element, and call exec(). >=20 > given the above reasons, there are good chances that in my qemu fork (G= NU ARM Eclipse QEMU) I'll have to use the separate -semihosting-cmdline o= ption; if you'll accept my patches in the main trunk, ok, if not... no pr= oblem;=20 >=20 > as a conclusion, if you like arg=3D, go for it, but just be aware that = this solution does not cover all use cases properly. I wasn't focussing on a specific use case, I just thought that having only one flexible command line option used for passing input arguments regardless of semi-hosting interface would be ideal. I do understand however that in your particular case cmdline is more convenient, thus I personally don=92t mind having both options: the user-friendly cmdline an= d more flexible arg. Leon