> Add new command line option "-semihosting-arg". It is used for passing > input arguments to the guest in semihosting mode. The option can be used > multiple times. If n arguments are passed, then argument count > (semihosting_argc) will be equal to n+1 as semihosting_argv[0] points at > the program name. However, if no arguments are passed then argument > count will be 0.
Is there any specific reason for not passing the name of the executable even if no -semihosting-arg is present? I think there are the following cases: 1) one or more -semihosting-arg options are given. So n+1 arguments are passed with the first one being kernel/boot name if available. The arguments are passed using UHI argc/argn operations (a0 == -1). 2) No -semihosting-arg options are given but the kernel/boot name is known. This could be passed either via the normal argument passing conventions that are already in place or via argc/argn operations. 3) No -semihosting arg options and unknown application name. For this you could again either do what is already done and pass kernel/append options or set a0=0 and indicate that there is no information at all. I wonder if there should be some detection of using both -semihosting-arg and -append? I think they are in direct conflict. It would probably be good to have cases 2/3 above do the same as what happened before and pass kernel name + append options. (By that I also mean setting up the argv array directly and setting a0 to a positive value (2) rather than using the new interface). While it may not be used, this would theoretically allow a kernel to be booted with -semihosting enabled, pass arguments in the same way they always have and allow very early boot to emit messages using UHI. I.e. the kernel will almost certainly never use the argc/argn/argnlen interface. I don't have any comments on the code except to say it looks to match the spec for argc/argn/argnlen. Thanks, Matthew