Comments (40)
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.
from eclipse-plugins.
@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/?
from eclipse-plugins.
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.
from eclipse-plugins.
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.
from eclipse-plugins.
What OpenOCD script are you using to interact with your target?
from eclipse-plugins.
What do you mean by script? The configuration file?
from eclipse-plugins.
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:
from eclipse-plugins.
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.
from eclipse-plugins.
No, that's not e2studio, it's "plain" Eclipse:
I don't want to use e2studio.
from eclipse-plugins.
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:
- Port 3333 for the Cortex-A55
- Port 3334 for the Cortex-M33
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.
from eclipse-plugins.
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?
from eclipse-plugins.
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.
from eclipse-plugins.
from eclipse-plugins.
Yes.
Ok - so that's the solution?
from eclipse-plugins.
Suboptimal I would say.
If I use the plugin I do not want to start OpenOCD manually myself.
from eclipse-plugins.
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.
- 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 and create two GDB servers - Cortex-A55/3333 and Cortex-M33/3334
Does GDB now use 3334 when the debug session is started?
from eclipse-plugins.
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"
from eclipse-plugins.
OK - I'll have to let @ilg-ul or @jonahgraham comment.
from eclipse-plugins.
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.
from eclipse-plugins.
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.
from eclipse-plugins.
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.
from eclipse-plugins.
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:
- OpenOCD as configured above and using the relevant script is started by the plugin and creates two GDB servers:
- Port 3333 for the Cortex-A55
- Port 3334 for the Cortex-M33
- GDB as launched by the plugin will always connect to 3333 - or whatever is specified in OpenOCD Setup > GDB port even if Remote Target > Port number is different (e.g. 3334)
- The user wants to launch only a single debug session, have the plugin launch OpenOCD and GDB but connect to the second OpenOCD GDB server on 3334 - it looks like this is not possible as things stand.
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.
from eclipse-plugins.
Perfect summary, thanks!
from eclipse-plugins.
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?
from eclipse-plugins.
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:
- Always have Remote Target > Port number enabled/editable
- Always launch GDB to connect to Remote Target > Port number rather than OpenOCD Setup > GDB Port
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!).
from eclipse-plugins.
Thanks @TommyMurphyTM1234!
I started typing my answer but yours was better than mine!
from eclipse-plugins.
I prototyped up in PR #570 a fix for this that adds this checkbox:
Is this a good solution? Or a non-starter?
from eclipse-plugins.
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.
from eclipse-plugins.
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:
- OpenOCD Setup > GDB port and Remote Target > Port number default to 3333
- Changes to OpenOCD Setup > GDB port are reflected/applied to Remote Target > Port number
- Changes to Remote Target > Port number override whatever was previously there (and are not reflected back to OpenOCD Setup > GDB port)
- Remote Target > Port number is always enabled - even if OpenOCD Setup > Start OpenOCD locally is enabled
- GDB is always launched by the plugin using Remote Target > Port number rather than (the de-facto situation when OpenOCD Setup > Start OpenOCD locally is checked?) OpenOCD Setup > GDB port?
from eclipse-plugins.
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.
from eclipse-plugins.
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.
from eclipse-plugins.
Before I refactor based on @TommyMurphyTM1234's suggestion I will wait for @ilg-ul's input.
from eclipse-plugins.
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.
from eclipse-plugins.
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.
from eclipse-plugins.
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.
from eclipse-plugins.
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:
- Clicking on the warnings will restore the default value for that text box
- Enabling "Start OpenOCD locally" will restore IP address and port to
localhost
/ port number in GDB port - The warnings are not displayed if "Start OpenOCD locally" is disabled
- Editing the port in "OpenOCD Setup" section always updates the port in "Remote Target" section
from eclipse-plugins.
Looks good to me. I'll give it a try on Monday, this weekend I'll not be at my computer.
from eclipse-plugins.
@jonahgraham - thanks.
I'll give it a go asap.
from eclipse-plugins.
It works as expected:
Thanks again.
from eclipse-plugins.
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.
from eclipse-plugins.
Related Issues (20)
- The disassembly view dosen't show opcode HOT 17
- CMSIS Packs - Read error dialog Abort button has the same effect as Ignore HOT 1
- CMSIS Packs - nomenclature is inconsistent and a little confusing HOT 6
- Support enhanced GNU Tool Factory capabilities introduced in CDT 11.2.0 HOT 5
- openocd plugin has dependency on managedPlugin which is not given in the manifest file HOT 13
- Global RISC-V Toolchains name does not change with dropdown box HOT 54
- Feature request: add live watch support when debug in eclipse ide HOT 12
- Review the logic for setting the PATH with preferXpacksBin HOT 7
- GDB fails when workspace path has extended ASCII characters HOT 8
- 'xpm' is not recognized as an internal or external command HOT 1
- Is it possible to set the timeout when gdb server (such as openocd) starts? HOT 1
- Install CMSIS Pack from local .pack file? HOT 4
- How to pass -Wl,--start-group -lc_nano -lgcc -Wl,--end-group HOT 1
- Feature request: Add a checkbox to enable group linked library HOT 25
- embed-CDT cannot start openocd normally HOT 2
- make: unknown option -- jobserver-auth=gmake_semaphore_172 when using post-build steps HOT 16
- "Interrupt failed" occurred when using GDB OpenOCD Debugging HOT 5
- Error during update: No repository found at http://gnu-mcu-eclipse.netlify.com/v4-neon-updates. HOT 4
- EmbedCDT should compile with SimRel 2024-06 HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from eclipse-plugins.