On 19 Nov 2014, at 14:08, Peter Maydell <peter.mayd...@linaro.org> wrote:
> ... (Bear in mind that my target-arm.next > branch is a rebasing branch, so you can't git merge > or pull it; you need to fetch it and then rebase > your patchstack on it.) I currently have two more branches in my git, for each of the patches applied. I planned to make another branch, based on the -semihosting-config branch, and add the cmdline patches there. >>> my suggestion would be to extend the -semihosting-config >>> option with cmdline="..." instead of adding a separate option >>> (in my first patch I used -semihosting-cmdline). > > On the A and R profile code path this command line > is taken from the existing "-append" option. Is > there a reason we can't just make the M profile > code do the same thing? I already explained, but will do it again. first, we are talking about two completely different use cases. on the A profile you have a kernel, and when you start it, you 'append' to the kernel path some options, and this is what you pass to the bootloader. this has nothing to do with semihosting, the command line is always used by the bootloader to start the kernel. on the M profile we do not have a kernel, but an image (that you do not want to accept as a different thing), and for normal emulation (i.e. without semihosting) we do not have any command line options. now comes semihosting. I do not know how you used semihosting for other platforms, but for arm, the current code breaks with faults, so I have my doubts it was really used (if it was, ok). anyway, the current code uses the same strategy as for the bootloader, i.e. tries to use the kernel full path and concatenate with the 'append' string. on M profiles, the semihosting startup code cannot afford to allocate very large buffers for the command line, as for the A profiles, and usually only some tens of bytes are available; with the full paths as argv[0] this buffer is already not enough, and the semihosting code returns an error, without passing anything back to the application. both the J-Link GDB server and the openOCD GDB server have a method of passing a string as an *entire*, self-contained, command line to be returned by the semihosting SYS_GET_CMDLINE call, including the argv[0], without using anything else like executable path. I consider this strategy to be reasonable for QEMU too, and I would insist on considering it. so, for the A profile, nothing changes, use -kernel with the kernel name and -append with argv[1]...argv[n], as before. for semihosting, regardless of profile, but especially to satisfy the M profile limitations, I suggest an explicit: -semihosting-config target=native,cmdline="myTest 1 2 3" I do not know if it makes any sense to start a linux kernel with semihosting enabled, but if it does, we can make the cmdline= optional, and, if missing and the -kernel and -append are present, we can apply the previous strategy, i.e. compose the long string from the full kernel path and the appended options. if it does not, we simplify things and always use cmdline="" (my favourite). regards, Liviu p.s. in my GNU ARM Eclipse branch I'll continue to use -image, and completely get rid of the misleading -kernel & -append options; I hope at a certain moment you'll accept qemu is also fit for non linux exclusive use cases. > > thanks > -- PMM
