Closed MicBiso closed 1 year ago
Your report seems confusing.
This:
In the Debugger tab I can choose the GDB, Telnet and Tcl ports, this is fine and it configures the ports when OpenOCD is invoked.
seems to contradict this:
However I cannot choose a different port GDB number but the one that is specified in the option above.
if I specify 3334 as GDB port, it will connect to port 3334 but this will still be the 1st core
Surely this behaviour is outside the scope of the plugin and dictated by something external? Maybe you need a custom OpenOCD script in order to discriminate between different core targets?
I think you need to explain the issue in more detail - ideally with screenshots and logs - because I cannot see that it's obviously an issue with the plugin itself.
Ok, let me try again.
Please ignore the error, it is not important for what I want to describe. As you can see when OpenOCD is launched, there are two gdb server ports: 3333 for the Cortex-A55 and 3334 for the Cortex-M33. There is no way for me to select the Cortex-M33 and port 3334. If I change this option:
to 3334 for example, I get this:
So no matter what I configure, I can never connect to the second gdb port. Now, of course I know that I could try to change the OpenOCD configuration file, but I think it would be good to have the possibility to specify in the plugin to which of the listening ports gdb should connect to.
What OpenOCD script are you using to interact with your target?
What do you mean by script? The configuration file?
In other words, the "Port Number" here should be left configurable, also when the "Start OpenOCD locally" box is checked. In fact if I change the GDB port to 3334 for instance, the same is reflected there:
I notice you are using Renesas - I think Renesas' e2studio contains launch configurations that allow such customizations, including selecting which cores to connect Eclipse to.
No, that's not e2studio, it's "plain" Eclipse:
I don't want to use e2studio.
OK - I understand the issue now.
With GDB OpenOCD Debugging > Debugger > OpenOCD Setup > GDB Port set to (the default) 3333 the script creates two GDB servers:
But, it seems, that when OpenOCD is started locally by the plugin then GDB always connects to GDB OpenOCD Debugging > Debugger > OpenOCD Setup > GDB Port and there is no option to get it to connect to that plus 1 or whatever.
What if you do this:
Does GDB now use 3334?
But, it seems, that when OpenOCD is started locally by the plugin then GDB always connects to GDB OpenOCD Debugging > Debugger > OpenOCD Setup > GDB Port and there is no option to get it to connect to that plus 1 or whatever.
Correct.
What if you do this:
Uncheck Start OpenOCD locally Change Remote Target > Port number to 3334 Check Start OpenOCD locally Does GDB now use 3334?
Yes.
Yes.
Ok - so that's the solution?
Suboptimal I would say. If I use the plugin I do not want to start OpenOCD manually myself.
Suboptimal I would say. If I use the plugin I do not want to start OpenOCD manually myself.
That's not what I was suggesting.
Does GDB now use 3334 when the debug session is started?
Sorry, I misunderstood. GDB port and Remote target Port number cannot be different.
Uncheck Start OpenOCD locally TEMPORARILY Change Remote Target > Port number to 3334 - so GDB should use this Re-check Start OpenOCD locally so that the plugin will launch OpenOCD Does GDB now use 3334 when the debug session is started?
Obviously not. As soon as I recheck "Start OpenOCD locally", the "Port Number" gets reconfigured to what is specified in "GDB port"
OK - I'll have to let @ilg-ul or @jonahgraham comment.
In other words, the "Port Number" here should be left configurable, also when the "Start OpenOCD locally" box is checked.
Yes - I think that would solve the problem. By default the port number should track the port in start openocd locally, but there should be a way to override it.
Can you summarise the issue? You can start multiple plugin instances, each with its own openocd listening on its own port.
If you want a single openocd instance to listen on multiple ports, you configure the first launcher to start it, and the second one to do not start it, but use the second port defined in the Remote Target field.
If this mechanism does not work as expected, please explain exactly how to reproduce the problem.
If you want a single openocd instance to listen on multiple ports, you configure the first launcher to start it, and the second one to do not start it, but use the second port defined in the Remote Target field.
Isn't this a bit nasty? I just want to connect to the second port without having to first start an instance of the plugin just for this. As said, it would be enough to have the "Port Number" field to be always configurable.
Can you summarise the issue? You can start multiple plugin instances, each with its own openocd listening on its own port.
If you want a single openocd instance to listen on multiple ports, you configure the first launcher to start it, and the second one to do not start it, but use the second port defined in the Remote Target field.
If this mechanism does not work as expected, please explain exactly how to reproduce the problem.
My understanding of the issue is:
The suggestion is to allow Remote Target > Port number to always be edited even if Start OpenOCD locally is checked, and have GDB launch using Remote Target > Port number rather than OpenOCD Setup > GDB port, thus allowing the port that GDB connects to to be configured.
Perfect summary, thanks!
Do you want to start one or two sessions?
If you want to start a single session, but not for the first core, you have to adjust your script to give you access to that core, and make openocd to listen on a single port, which you can configure in the plugin.
I have close to zero experience with openocd, so I have no idea how your script should be changed, but with J-Link, if I remember right, for multi core devices it was possible to start multiple GDB server instances, each with its port, configured for a separate core, and this simple use case was assumed for openocd too.
From Tommy's summary, I understand that you want to start openocd locally with a custom multi-port configuration, let it listen on multiple port, and do not disable the Remote Target fields (which prevents out of sync configurations for regular use cases), to allow the GDB client to connect to another port.
This can be done, but is it really a good solution? Why don't you use a separate script for the second core?
Do you want to start one or two sessions?
They want to start one - that connects to the "second" core target (Cortex-M33) for which OpenOCD creates a GDB server on port 3334.
If you want to start a single session, but not for the first core, you have to adjust your script to give you access to that core, and make openocd to listen on a single port, which you can configure in the plugin.
That's one way to do it but invasive to the default target script.
This can be done, but is it really a good solution?
I don't think that it's a bad solution.
As @jonahgraham said above, by default Remote Target > Port number should match OpenOCD Setup > GDB port, but the former is left editable (even if OpenOCD Setup > Start OpenOCD locally is checked) and GDB is launched by the plugin using the former rather than the latter. That allows the flexibility that is needed here but doesn't impact anything else that I can think of.
In short the suggested changes to the plugin are:
Edit: actually there is a negative impact. Assume a single core target (forget about multiple cores and GDB servers). If the user decides to configure OpenOCD to start the GDB server on something other than 3333 then they need to change this in two places now - OpenOCD Setup > GDB port AND Remote Target > Port number. Unless changes to the former always change the latter but changes to the latter can be used to override the default? (And that may be what @jonahgraham was suggesting above!).
Thanks @TommyMurphyTM1234! I started typing my answer but yours was better than mine!
I prototyped up in PR #570 a fix for this that adds this checkbox:
Is this a good solution? Or a non-starter?
If the default for the checkbox is always true, and the value is not stored persistently in the environment to be used as a default for the next launcher, it is ok.
My concern is that creating 'regular' launchers may inadvertently inherit this less used configuration.
I prototyped up in PR #570 a fix for this that adds this checkbox:
Is this a good solution? Or a non-starter?
At the moment, rather than introducing a new GUI element (Remote Target > Use host name etc. checkbox) I'd be more inclined to do this:
If the default for the checkbox is always true, and the value is not stored persistently in the environment to be used as a default for the next launcher, it is ok.
Yes - that is how I did it. Checkbox is always checked on new launches (i.e. doesn't use fPersistentPreferences
), and is set back to checked if you toggle the start gdbserver to on as well.
My concern is that creating 'regular' launchers may inadvertently inherit this less used configuration.
Not sure what this means - please expand unless I addressed your issue in the above paragraph.
At the moment I'd be more inclined to do this:
I like that better too. Maybe a tooltip on Remote Target > Port number to explain this too.
Before I refactor based on @TommyMurphyTM1234's suggestion I will wait for @ilg-ul's input.
At the moment I'd be more inclined to do this:
I like that better too. Maybe a tooltip on Remote Target > Port number to explain this too.
My only concern is about if/how any settings get persisted and applied to future launch configurations. But the way that Eclipse plugins persist settings (or not) across instances has always been a mystery to me.
creating 'regular' launchers may inadvertently inherit this less used configuration
The mechanism of keeping persistent preferences, used by Eclipse in many places, is both helpful and annoying.
The annoying case would be when the user configures the remote target port 3334, runs a debug session, and the next day creates a regular launcher, for a simple device which starts openocd to listen only on 3333, and scratches his head why the plugin timeouts (and asks for support!).
Thus I would favour a solution which explicitly shows in the interface that the Remote Target is out of sync with the locally started server, and be sure this checkbox always defaults to a position that prevents this case.
the way that Eclipse plugins persist settings (or not) across instances has always been a mystery to me
The mystery is not that deep, most values in the graphical interface are saved as persistent preferences and used as defaults when the plugin creates a new instance of the corresponding object.
In this case, a subsequent OpenOCD launcher will inherit most of the values of the previously created OpenOCD launcher, a subsequent QEMU launcher will inherit most of the values of the previously created QEMU launcher, etc.
I'm going to experiment if I can make something without a checkbox as @TommyMurphyTM1234 suggests that also explicitly shows what is going on and defaults as expected.
With PR #571 the text boxes are always enabled:
If the user edits the port/ip address a standard Warning decoration is displayed like this:
or:
(both warning will display if both settings are mis-matched)
The warning has a hover like this:
Other notes:
localhost
/ port number in GDB portLooks good to me. I'll give it a try on Monday, this weekend I'll not be at my computer.
@MicBiso - this change has now been merged and a development build has been created by the CI. Can you test the new feature using the p2 site https://download.eclipse.org/embed-cdt/builds/develop/p2/?
@jonahgraham - thanks. I'll give it a go asap.
It works as expected:
Thanks again.
Great!
Thank you Jonah for your contribution.
If @TommyMurphyTM1234 has no further suggestions (for this and for #566), I'll prepare a new release in the next few days.
Description
In the Debugger tab I can choose the GDB, Telnet and Tcl ports, this is fine and it configures the ports when OpenOCD is invoked. However I cannot choose a different port GDB number but the one that is specified in the option above. The use case is related to multicore devices with different (and consecutive ports) for the different cores, e.g. core 1 port 3333, core 2 port 3334, and so on. At the moment I can only connect to the core 1, i.e. port 3333 and if I specify 3334 as GDB port, it will connect to port 3334 but this will still be the 1st core, with 2nd core having port 3334 and so on. If I deselect the flag "Start OpenOCD locally" then for sure I can specify the exact port I want GDB to connect to but with the hassle to start OpenOCD manually.
It would be nice to have the possibility to specify the actual GDB port. I tried to use -ex "target extended-remote localhost:3334" as "other options" but it does not work.
Versions