Adding a target type for embedded development?

[WinterMute]

I've now added the launch application when debugging code and found that the extra arguments can be quite handy for passing extra arguments when debugging other applications so that program arguments dialog looks like this now.



Although Additional shell commands can launch an application before gdb runs, it turns out that there are different ways to background the process for windows & linux/osx. Doing this in code means the project files are still useable regardless of host OS.

I was thinking that maybe it would be better to check if we're debugging remotely before launching the host application this way. I'm not sure how MPI programs are normally debugged, would it work if we used gdb to launch mpirun?

My latest changes are here :- https://github.com/WinterMute/codeblocks_sf/compare/hosted-app

[oBFusCATed]

What does "debug arguments" mean/do?
Shouldn't this be "Host app arguments"?

[WinterMute]

It turned out to be useful to have extra arguments passed to applications when debugging. For instance I have a couple of projects that benefit from switching off stdio redirection when debugging to get messages in the gdb console and turn off saving to config files, things like that. Thought it might be useful for other people too.

[scarphin]

I apologize for my interference but I'm quite confused here. My understanding of your situation doesn't fit into anything I've done with CB and gdb so far so I'm just trying to detect if I missed any advantages with your method of debugging, so please bear with me. I mainly use AVRs for my work and the usual process is:
1- Compile the source into an .elf file (CB 'Build' command),
2- Extract the required .hex, .eeprom etc... (CB 'Post Build Steps'),
3- Program the chip (corresponding menu entry in CB 'Tools' plugin, may also be a post build step if one wants to automate it),
4- Debugging process (explained below),

Debugging:
1- If a debugging hardware is used, a 'gdbserver' is launched to connect the hardware with gdb (CB 'additional shell commands before connection'). If a simulator is used replace 'gdbserver' with the simulator,
2- Start debugging (CB 'Debug' command).

What I understand from your posts is you run the simulator with CB 'Run' command and launch a manual 'gdb' process to connect to it. If that is the case what I would do is:
1- Insert '$(TARGET_COMPILER_DIR)..\emulators\3dmoo $(TARGET_OUPUT_DIR)$(TARGET_OUTPUT_BASENAME).3dsx -gdbport 1000' into 'additional shell commands before connection',
2- Start debugging (CB 'Debug' command).

Which part of this doesn't work or meet your requirements? If not what is the advantage?

[oBFusCATed]

It turned out to be useful to have extra arguments passed to applications when debugging. For instance I have a couple of projects that benefit from switching off stdio redirection when debugging to get messages in the gdb console and turn off saving to config files, things like that. Thought it might be useful for other people too.

I'm not sure this is a good idea them. This dialog is confusing without this field and now it will become even more confusing.
I'd prefer this option be part of the debugger settings in the project -> properties dialog.

[WinterMute]

What I understand from your posts is you run the simulator with CB 'Run' command and launch a manual 'gdb' process to connect to it. If that is the case what I would do is:
1- Insert '$(TARGET_COMPILER_DIR)..\emulators\3dmoo $(TARGET_OUPUT_DIR)$(TARGET_OUTPUT_BASENAME).3dsx -gdbport 1000' into 'additional shell commands before connection',
2- Start debugging (CB 'Debug' command).

Which part of this doesn't work or meet your requirements? If not what is the advantage?

If I do that then gdb will never start since the emulator won't return control until it finishes. Backgrounding the process is different between windows (putting start at the beginning of the command) and OSX/Linux ( ending command with & ) which means that a project file created on one system will then not be transferable to another without editing. The simplest way to deal with that seems to be to launch the host application as part of the process that starts gdb, otherwise it involves using a script to detect host os or something like cb_console_runner that forks the host application and returns to the caller.

My ultimate goal here is to have a version of Code::Blocks that I can distribute with the devkitPro toolchains so that end users can have a project set up, ready to compile and run or debug with a couple of button clicks. The plan is to provide project files with the example code as well which means I'd really rather not have the user need to edit things before they can debug code just because the project was set up on a different OS.

It turned out to be useful to have extra arguments passed to applications when debugging. For instance I have a couple of projects that benefit from switching off stdio redirection when debugging to get messages in the gdb console and turn off saving to config files, things like that. Thought it might be useful for other people too.

I'm not sure this is a good idea them. This dialog is confusing without this field and now it will become even more confusing.
I'd prefer this option be part of the debugger settings in the project -> properties dialog.

OK, that seems reasonable.

I have a smaller set of changes without the debug arguments patches at https://github.com/WinterMute/codeblocks_sf/compare/hosted-application-changes

Is it possible to get access to the debugger settings from a wizard script?

[oBFusCATed]

Backgrounding the process is different between windows (putting start at the beginning of the command) and OSX/Linux ( ending command with & )

I think this could be done with the macro manager.
You can provide a macro that is named something like: $START_BACKGROUND(<command>) and then this macro does the right thing on ever supported OS.
Another option is add a checkbox somewhere in the UI of the debugger, which tells it to start commands in the background.
The third option is to wrap your executable in a shell/batch script.

Is it possible to get access to the debugger settings from a wizard script?

There is a method in the project to get access to the plugin xml tags, but I don't know if it is exposed to squirrel. Probably not.

[scarphin]

What I understand from your posts is you run the simulator with CB 'Run' command and launch a manual 'gdb' process to connect to it. If that is the case what I would do is:
1- Insert '$(TARGET_COMPILER_DIR)..\emulators\3dmoo $(TARGET_OUPUT_DIR)$(TARGET_OUTPUT_BASENAME).3dsx -gdbport 1000' into 'additional shell commands before connection',
2- Start debugging (CB 'Debug' command).

Which part of this doesn't work or meet your requirements? If not what is the advantage?

If I do that then gdb will never start since the emulator won't return control until it finishes. Backgrounding the process is different between windows (putting start at the beginning of the command) and OSX/Linux ( ending command with & ) which means that a project file created on one system will then not be transferable to another without editing. The simplest way to deal with that seems to be to launch the host application as part of the process that starts gdb, otherwise it involves using a script to detect host os or something like cb_console_runner that forks the host application and returns to the caller.

My ultimate goal here is to have a version of Code::Blocks that I can distribute with the devkitPro toolchains so that end users can have a project set up, ready to compile and run or debug with a couple of button clicks. The plan is to provide project files with the example code as well which means I'd really rather not have the user need to edit things before they can debug code just because the project was set up on a different OS.

Ok, fair enough, now I get your point. Btw have you considered providing different project files for each supported OS? Afaik that is what CB does currently. I'm guessing you'll have to provide OS specific CB builds in the end.