Developer forums (C::B DEVELOPMENT STRICTLY!) > Development

Adding a target type for embedded development?

<< < (4/5) > >>

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:

--- Quote from: WinterMute on December 14, 2014, 11:22:20 pm ---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.

--- End quote ---
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.

Navigation

[0] Message Index

[#] Next page

[*] Previous page