Re: [Qemu-devel] runtime configurable semihosting
On 13 November 2014 09:44, Liviu Ionescu i...@livius.net wrote: Peter Maydell wrote: I took a quick look at the syntax of command options and monitor commands, and I would suggest the following: - extend the option -semihosting with an optional target=native|gdb|auto, default auto unfortunately the parser is not able to detect a missing optional, and will always consume the next option, so this syntax is not available. Sorry, yes, you're right; I should have looked more carefully. So we do need a new option; however I think it would be better for the new option to be a general qemuopts option, like this: -semihosting-config target=[native|gdb|auto] because that then gives us a place to put future semihosting related config options, and also allows the config files used by -readconfig/-writeconfig to change this setting. (We can have -semihosting-config have an implied 'enable=true', so you don't have to use the old -semihosting option if you're specifying -semihosting-config.) thanks -- PMM
Re: [Qemu-devel] runtime configurable semihosting
On 18 Nov 2014, at 15:31, Peter Maydell peter.mayd...@linaro.org wrote: Sorry, yes, you're right; I should have looked more carefully. So we do need a new option; or we should fix the parser. if the current keyword is not in the list, it can be pushed back, and defaults used. -semihosting-config target=[native|gdb|auto] ok, I'll implement this, and if you fix the parser we'll change it to the plain -semihosting. have -semihosting-config have an implied 'enable=true', so ok Liviu
Re: [Qemu-devel] runtime configurable semihosting
On 18 November 2014 16:46, Liviu Ionescu i...@livius.net wrote: On 18 Nov 2014, at 15:31, Peter Maydell peter.mayd...@linaro.org wrote: Sorry, yes, you're right; I should have looked more carefully. So we do need a new option; or we should fix the parser. if the current keyword is not in the list, it can be pushed back, and defaults used. This is veering quite close to magic, really. It changes the current handling of some valid command lines (admittedly ones with implausible image names, but still). -semihosting-config target=[native|gdb|auto] ok, I'll implement this, and if you fix the parser we'll change it to the plain -semihosting. Thanks. -- PMM
Re: [Qemu-devel] runtime configurable semihosting
On 12 Nov 2014, at 21:17, Liviu Ionescu i...@livius.net wrote: semihosting ... be runtime configurable on this, I think. I took a quick look at the syntax of command options and monitor commands, and I would suggest the following: - extend the option -semihosting with an optional target=native|gdb|auto, default auto unfortunately the parser is not able to detect a missing optional, and will always consume the next option, so this syntax is not available. the only reliable solution was to add a new option -semihosting-target native|gdb|auto which works as expected. regards, Liviu
Re: [Qemu-devel] runtime configurable semihosting
Hi Liviu, On 11/12/2014 02:17 PM, Liviu Ionescu wrote: semihosting ... be runtime configurable on this, I think. I took a quick look at the syntax of command options and monitor commands, and I would suggest the following: - extend the option -semihosting with an optional target=native|gdb|auto, default auto - if necessary, add a monitor command semihosting target=native|gdb|auto, default auto any comments? How do these targets change the existing behavior? Thanks, Chris -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [Qemu-devel] runtime configurable semihosting
On 13 November 2014 17:48, Christopher Covington c...@codeaurora.org wrote: Hi Liviu, On 11/12/2014 02:17 PM, Liviu Ionescu wrote: semihosting ... be runtime configurable on this, I think. I took a quick look at the syntax of command options and monitor commands, and I would suggest the following: - extend the option -semihosting with an optional target=native|gdb|auto, default auto - if necessary, add a monitor command semihosting target=native|gdb|auto, default auto any comments? How do these targets change the existing behavior? Our current behaviour is auto, which means send semihosting commands via gdb if and only if the gdbstub has a gdb connected when the first semihosting command is made by the guest. native would mean handle semihosting ourselves even if there's a gdb connected. I'm not sure how useful gdb is as distinct from auto (what do you do with the semihosting requests if no gdb is connected in this case?). -- PMM
Re: [Qemu-devel] runtime configurable semihosting
On 13 Nov 2014, at 23:23, Liviu Ionescu i...@livius.net wrote: ... gdb, but since I never used this configuration... btw, can anyone suggest how to configure things to test this kind of 'semihosting forwarding'? does the standard GDB support this, or a custom one is required? from the source code I saw that some special packages are sent to GDB, but my arm-none-eabi-gdb silently ignores them. or am I missing something? regards, Liviu
Re: [Qemu-devel] runtime configurable semihosting
On 13 November 2014 21:23, Liviu Ionescu i...@livius.net wrote: On 13 Nov 2014, at 19:52, Peter Maydell peter.mayd...@linaro.org wrote: ... I'm not sure how useful gdb is as distinct from auto (what do you do with the semihosting requests if no gdb is connected in this case?). well, I also had some doubts about gdb, but since I never used this configuration, I preferred to keep it, mainly for completeness. I did some tests and apparently nothing wrong happens when setting gdb and no connection is available. I'm about to prepare the patch, do you suggest to remove this case? ...I'm confused, I think. I thought 'gdb' was an option you added? Can you explain what the three options you're proposing do, and which of them is the behaviour we have today? thanks -- PMM
Re: [Qemu-devel] runtime configurable semihosting
On 13 Nov 2014, at 23:38, Peter Maydell peter.mayd...@linaro.org wrote: On 13 November 2014 21:23, Liviu Ionescu i...@livius.net wrote: ...I'm confused, I think. I thought 'gdb' was an option you added? that's correct, but only part of the whole image, in fact I added -semihosting-target auto|native|gdb; however my patch only changes the destination of the semihosting calls, not the actual behaviour. Can you explain what the three options you're proposing do, and which of them is the behaviour we have today? the behaviour is exactly the one you presented, 'auto' is the actual behaviour, 'native' is via qemu, 'gdb' is via... gbd. :-) --- there were many details that required fixing, hopefully I'll figure out how to send the patch soon. regards, Liviu p.s. I'm a bit puzzled by your patch submission procedure (the Eclipse CDT team uses Gerrit, and things are more or less automated), manually preparing patches and sending them to a mailing list seems quite tedious...
Re: [Qemu-devel] runtime configurable semihosting
On 13 November 2014 21:51, Liviu Ionescu i...@livius.net wrote: On 13 Nov 2014, at 23:38, Peter Maydell peter.mayd...@linaro.org wrote: On 13 November 2014 21:23, Liviu Ionescu i...@livius.net wrote: ...I'm confused, I think. I thought 'gdb' was an option you added? that's correct, but only part of the whole image, in fact I added -semihosting-target auto|native|gdb; however my patch only changes the destination of the semihosting calls, not the actual behaviour. Can you explain what the three options you're proposing do, and which of them is the behaviour we have today? the behaviour is exactly the one you presented, 'auto' is the actual behaviour, 'native' is via qemu, 'gdb' is via... gbd. :-) Right, but what does it mean to say 'gdb' that's different from 'auto' ? What happens in that case if you don't have a gdb attached? p.s. I'm a bit puzzled by your patch submission procedure (the Eclipse CDT team uses Gerrit, and things are more or less automated), manually preparing patches and sending them to a mailing list seems quite tedious... I use a flow like: git format-patch -o ~/my-sent-patches HEAD^ # check that the ~/my-sent-patches/0001-whatever.patch looks ok git send-email --to=qemu-devel@nongnu.org ~/my-sent-patches/0001-whatever.patch but that does require you to have set up git send-email so it knows how to send emails. (You can probably do it in one command but I happen to have my main dev machine and the machine I send email from being different, so I copy the patchfiles around in the middle.) -- PMM
Re: [Qemu-devel] runtime configurable semihosting
On 14 Nov 2014, at 00:16, Peter Maydell peter.mayd...@linaro.org wrote: Right, but what does it mean to say 'gdb' that's different from 'auto' ? auto sends either to gdb or qemu, gdb always sends to gdb, native always to qemu. What happens in that case if you don't have a gdb attached? according to my tests, nothing. but, as I already mentioned, I have no experience with forwarding semihosting to gdb, and I may be missing the point. I use a flow like: ... thank you, I'm trying to figure out the details (Signed-oof-by, cover letter, etc) Liviu
Re: [Qemu-devel] runtime configurable semihosting
On 13 November 2014 22:23, Liviu Ionescu i...@livius.net wrote: On 14 Nov 2014, at 00:16, Peter Maydell peter.mayd...@linaro.org wrote: Right, but what does it mean to say 'gdb' that's different from 'auto' ? auto sends either to gdb or qemu, gdb always sends to gdb, native always to qemu. What happens in that case if you don't have a gdb attached? according to my tests, nothing. Oh, I see now. gdb_do_syscall() will return doing nothing if gdbserver_state is NULL (so gdb will throw away semihosting requests until a gdb is eventually connected, at which point we start to honour them). Yes, that makes sense as a behaviour (though 'auto' and 'native' are going to be the major uses). I use a flow like: ... thank you, I'm trying to figure out the details (Signed-off-by, cover letter, etc) The Signed-off-by is just a matter of putting that line in your commit message. It's pretty much the only thing we absolutely have to insist on, since it's a statement that you're happy for the code to go in and have the legal right to contribute it. Most other things we can fix up formatting details if needed. You don't need a cover letter unless you're submitting a series with more than one patch in it. -- PMM
