-
-
Notifications
You must be signed in to change notification settings - Fork 130
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature request: add option to connect to a different OpenOCD port #569
Comments
Your report seems confusing. This:
seems to contradict this:
Surely this behaviour is outside the scope of the plugin and dictated by something external? 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. to 3334 for example, I get this: So no matter what I configure, I can never connect to the second gdb port. |
What OpenOCD script are you using to interact with your target? |
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. |
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? |
Correct.
Yes. |
Ok - so that's the solution? |
Suboptimal I would say. |
That's not what I was suggesting.
Does GDB now use 3334 when the debug session is started? |
Sorry, I misunderstood.
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. |
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. |
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. |
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? |
They want to start one - that connects to the "second" core target (Cortex-M33) for which OpenOCD creates a GDB server on port 3334.
That's one way to do it but invasive to the default target script.
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!). |
When starting a gdbserver (like openocd) connected to a multi-core SoC the gdb server may open multiple ports. This change allows user to configure which port GDB connect to rather than forcing GDB to connec to the first port. Fixes eclipse-embed-cdt#569
Thanks @TommyMurphyTM1234! |
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. |
When starting a gdbserver (like openocd) connected to a multi-core SoC the gdb server may open multiple ports. This change allows user to configure which port GDB connect to rather than forcing GDB to connec to the first port. Fixes eclipse-embed-cdt#569
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:
|
Yes - that is how I did it. Checkbox is always checked on new launches (i.e. doesn't use
Not sure what this means - please expand unless I addressed your issue in the above paragraph. |
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. |
My only concern is about if/how any settings get persisted and applied to future launch configurations. |
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 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. |
When starting a gdbserver (like openocd) connected to a multi-core SoC the gdb server may open multiple ports. This change allows user to configure which port GDB connect to rather than forcing GDB to connect to the first port. When the ports do not match a warning triangle is displayed which can be clicked on to restore the matching values. When a user changes the "GDB port" in the "Start TYPE locally" section that is reflected in the "Port number" in the "Remote Target" section. Changes to "Port number" in the "Remote Target" which lead to the ports not matching will display the warning triangle. TODO: - [ ] Get approval for this solution in eclipse-embed-cdt#569 - [ ] Review wording of tool-tips on label decorations - [ ] Apply this same change to all the other TabDebugger.java files Fixes eclipse-embed-cdt#569
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:
|
Looks good to me. I'll give it a try on Monday, this weekend I'll not be at my computer. |
When starting a gdbserver (like openocd) connected to a multi-core SoC the gdb server may open multiple ports. This change allows user to configure which port GDB connect to rather than forcing GDB to connect to the first port. When the ports do not match a warning triangle is displayed which can be clicked on to restore the matching values. When a user changes the "GDB port" in the "Start TYPE locally" section that is reflected in the "Port number" in the "Remote Target" section. Changes to "Port number" in the "Remote Target" which lead to the ports not matching will display the warning triangle. Fixes eclipse-embed-cdt#569
When starting a gdbserver (like openocd) connected to a multi-core SoC the gdb server may open multiple ports. This change allows user to configure which port GDB connect to rather than forcing GDB to connect to the first port. When the ports do not match a warning triangle is displayed which can be clicked on to restore the matching values. When a user changes the "GDB port" in the "Start TYPE locally" section that is reflected in the "Port number" in the "Remote Target" section. Changes to "Port number" in the "Remote Target" which lead to the ports not matching will display the warning triangle. Fixes #569
@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. |
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
The text was updated successfully, but these errors were encountered: