cross-debugging

[J-Dunn]

Geany is an excellent tool but gdb support unfortunately does not support cross-debugging, which is a rapidly growing need. I certainly don't want to be forced to use some ugly mastodont like eclipse just for that.

This patch is very short, so it seems that there is little functionality missing to achieve this. Would it be possible to integrate something like this into geany-plugins?
http://faumarz.blogspot.fr/2014/03/gdb-and-geany-ide-remote-cross-debugging.html

This relies on symlinking the cross debugger to gdb which is a hack. It really needs an additional config for the full name : arm-none-eabi-gdb , or whatever.

Starting the remote gdbserver debugging session could probably be done in the existing project properties dialogue. by defining an 'execute command' . The supplied patch prevents spawning gdb directly. This could be integrated more cleanly, with minimal changes.

Thanks.

[Andy1978]

Any progress on this? I was hoping to use the "debugger" plugin to debug AVR using avr-gdb via avarice but found that the gdb binary is hard-coded. Creating a symlink would work as hack...

[elextr]

If using another version of GDB works with the plugin as implied by the link technique then it would be reasonable to add a configurable command, but somebody has to do it, pull requests are welcome.

[pascal-fb-martin]

Why not using gdb-multiarch when in remote mode? It works fine between my desktop PC and Raspberry Pi target.

That might require dbm_gdb.c to "declare" two modules, so that there is a different "run" function, using a different gdb program, for the remote mode.

[pascal-fb-martin]

I have a patch that seems to work, derived from J-Dunn's patch with the following differences:

• Updated to latest version of the Debugger plugin.
• Explicit debugger mode's combo box widget to replace the invisible-to-the-user '@' prefix convention.
• Support native gdb ("Local"), native gdb in remote mode ("Remote"), gdb-multiarch in remote mode ("Cross Development"), the last mode allowing me to debug ARM code remotely from my desktop PC without changing a gdb symlink.

A pull request should follow soon.

[J-Dunn]

Thanks for the interest. Firstly, that was not my patch in the sense that I wrote it. Just something I found which looked better than nothing. It was a bit of a hack as I noted.

This bug report is VERY old. It may even pre-date the move to python 3 which at the time would have killed scope plugin since it was effectively unmaintained. I think it has got some attention since.

I have not assessed the state of play on this recently. There seems to be some confusion about what gdb gets included in the cross compiler packages. IIRC Fedora does not include one, possibly because gdb runs on the local host to control a remote device, so is not a "cross" program.

I'd need some time, which I don't have right now, to get back into this to provide feedback. Looks good from the outside.

[pascal-fb-martin]

Not as old as gdb.. :-)

Otherwise, I agree with "It really needs an additional config..", but the whole debugger configuration should probably be stored in the project file (when a project is open) rather than in a (global) plugin configuration. Not all projects are cross-development projects.

I wonder what the policy is for storing plugin context in a project configuration?

[elextr]

So long as its in a separate section plugins can save to the project file on the project_save signal, see project_organiser.

But debugger also should work from the user config when there is no project as well, so you are going to have to figure out how to do that, not sure any current plugins do, project_organiser just stops working when there is no project IIUC.

[J-Dunn]

Not all projects are cross-development projects.

It seems what is needed is a binary config ( checkbox ) which selects whether the debugging session is remote or not. It defaults to false. This is used to select the augmented commands needed in a remote session, as provided in the patch linked in #1.

Since distros seem to handle what gets installed differently , there may be a need to specify a gdb path. A copy of gdb may or may not be in path and may or may not be the one required. It would be nice if this was configurable without the user needing to symlink outside of Geany.

When flipping between two files or projects running in different contexts ( local/remote ), it is not unreasonable to expect to at least toggle the checkbox on the plugin. This state could be added to the project file.

[elextr]

A copy of gdb may or may not be in path and may or may not be the one required. It would be nice if this was configurable without the user needing to symlink outside of Geany.

indeed

This state could be added to the project file.

The plugin still needs to work without projects, many beginners use debugger, and they don't use projects.

If the plugin wants to save settings in the project file when one is open, thats fine, but it needs to detect that there is no project and then save in the user config instead (or not save it of course).

Since AFAIK all other settings of debugger are saved in the the user config having just one setting in the project file doesn't make much sense.

[pascal-fb-martin]

This is not just the debugger mode, there are also the name of the target file and the arguments: these change from projects to project. I tried Scope but it does not seem to save anything and I got quickly tired of re-entering everything. That and a starting patch made Debugger much more attractive. (Otherwise Scope allows more access to gdb.)

I was thinking of testing if there is a project open, and use the global plugin settings if there is none. Obviously this would require knowing when a project is opened or closed (to reload the settings according to the new context). If the project has no setting (section not present), it would use the plugin global settings (until saved, at least).

I agree that some behavior is a matter of user preference.

This is not critical, but it would be nice since my "somewhat micro-service without a cloud" hobby leads me to switch from project to project frequently.

[pascal-fb-martin]

The plugin still needs to work without projects, many beginners use debugger, and they don't use projects.

Amusingly, this is the project feature that attracted me to geany: at last a tool that can maintain a context project by project without imposing its own source and build organization. But, yes, I realize that a project is optional.

[pascal-fb-martin]

So long as its in a separate section plugins can save to the project file on the project_save signal, see project_organiser.

Thanks for the tip: I found the documentation for signals, and that seems to be all that I would need.

I will let the dust settle for now: if my pull request is merged, I will wait a little for anyone to complain about regressions before doing more damages. :-)

[pascal-fb-martin]

BTW, the benefit of using gdb-multiarch compared to using the target-specific cross debugger is that the plugin does not need to know what is the target's architecture. One less configuration to worry about.

[elextr]

Just a note, a project is a single file, so its saving is controlled by Geany, the user config is a directory, so debugger has its own file and save at any time it wants/needs to.

[Edit: and of course projects only save a few settings, but you can run geany -c blah to use a config directory ("blah" in this case) as if it was a project. Of course you need to restart to swap projects, but you can also safely run multiple copies of Geany this way so your project switching may be even more convenient that way.]

[pascal-fb-martin]

LOL: saving settings to the project is an existing option in the Debugger plugin.

Knowing what to look for made it easy to retrieve what it does, and it is pretty much what I would have wanted. It does not automatically jump back and forth between the project and non-project mode: that is OK because I plan to use the project mode all the time anyway (for that very reason).

Thank you all for your help, and sorry for taking your time.