eclipse-embed-cdt / eclipse-plugins

The Eclipse Embedded CDT plug-ins for Arm & RISC-V C/C++ developers (formerly known as the GNU MCU Eclipse plug-ins). Includes the archive of previous plug-ins versions, as Releases.
http://eclipse-embed-cdt.github.io/
Eclipse Public License 2.0
554 stars 130 forks source link

Feature request: add option to connect to a different OpenOCD port #569

Closed MicBiso closed 1 year ago

MicBiso commented 1 year ago

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

TommyMurphyTM1234 commented 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.

MicBiso commented 1 year ago

Ok, let me try again.

image

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:

image

to 3334 for example, I get this:

image

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.

TommyMurphyTM1234 commented 1 year ago

What OpenOCD script are you using to interact with your target?

MicBiso commented 1 year ago

What do you mean by script? The configuration file?

image

MicBiso commented 1 year ago

image

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:

image

jonahgraham commented 1 year ago

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.

MicBiso commented 1 year ago

No, that's not e2studio, it's "plain" Eclipse:

image

I don't want to use e2studio.

TommyMurphyTM1234 commented 1 year ago

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:

  1. Port 3333 for the Cortex-A55
  2. 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.

TommyMurphyTM1234 commented 1 year ago

What if you do this:

  1. Uncheck Start OpenOCD locally
  2. Change Remote Target > Port number to 3334
  3. Check Start OpenOCD locally

Does GDB now use 3334?

MicBiso commented 1 year ago

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.

TommyMurphyTM1234 commented 1 year ago

image

TommyMurphyTM1234 commented 1 year ago

Yes.

Ok - so that's the solution?

MicBiso commented 1 year ago

Suboptimal I would say. If I use the plugin I do not want to start OpenOCD manually myself.

TommyMurphyTM1234 commented 1 year ago

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.

  1. Uncheck Start OpenOCD locally TEMPORARILY
  2. Change Remote Target > Port number to 3334 - so GDB should use this
  3. 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?

MicBiso commented 1 year ago

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"

TommyMurphyTM1234 commented 1 year ago

OK - I'll have to let @ilg-ul or @jonahgraham comment.

jonahgraham commented 1 year ago

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.

ilg-ul commented 1 year ago

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.

MicBiso commented 1 year ago

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.

TommyMurphyTM1234 commented 1 year ago

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:

  1. 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
  2. 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)
  3. 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.

MicBiso commented 1 year ago

Perfect summary, thanks!

ilg-ul commented 1 year ago

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?

TommyMurphyTM1234 commented 1 year ago

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:

  1. Always have Remote Target > Port number enabled/editable
  2. 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!).

MicBiso commented 1 year ago

Thanks @TommyMurphyTM1234! I started typing my answer but yours was better than mine!

jonahgraham commented 1 year ago

I prototyped up in PR #570 a fix for this that adds this checkbox:

image

Is this a good solution? Or a non-starter?

ilg-ul commented 1 year ago

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.

TommyMurphyTM1234 commented 1 year ago

I prototyped up in PR #570 a fix for this that adds this checkbox:

image

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:

  1. OpenOCD Setup > GDB port and Remote Target > Port number default to 3333
  2. Changes to OpenOCD Setup > GDB port are reflected/applied to Remote Target > Port number
  3. Changes to Remote Target > Port number override whatever was previously there (and are not reflected back to OpenOCD Setup > GDB port)
  4. Remote Target > Port number is always enabled - even if OpenOCD Setup > Start OpenOCD locally is enabled
  5. 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?
jonahgraham commented 1 year ago

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.

jonahgraham commented 1 year ago

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.

jonahgraham commented 1 year ago

Before I refactor based on @TommyMurphyTM1234's suggestion I will wait for @ilg-ul's input.

TommyMurphyTM1234 commented 1 year ago

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.

ilg-ul commented 1 year ago

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.

ilg-ul commented 1 year ago

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.

jonahgraham commented 1 year ago

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.

jonahgraham commented 1 year ago

With PR #571 the text boxes are always enabled:

image

If the user edits the port/ip address a standard Warning decoration is displayed like this:

image

or:

image

(both warning will display if both settings are mis-matched)

The warning has a hover like this:

image

Other notes:

ilg-ul commented 1 year ago

Looks good to me. I'll give it a try on Monday, this weekend I'll not be at my computer.

jonahgraham commented 1 year ago

@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/?

MicBiso commented 1 year ago

@jonahgraham - thanks. I'll give it a go asap.

MicBiso commented 1 year ago

It works as expected:

image

Thanks again.

ilg-ul commented 1 year ago

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.