1
0
Fork 0
mirror of https://github.com/eclipse-cdt/cdt synced 2025-04-29 19:45:01 +02:00
cdt/debug/org.eclipse.cdt.debug.application/scripts
Jonah Graham 0568568c33 Change standalone debugger to no longer limit number of bundles
The maintenance of having a streamlined standalone debugger that
starts as fast as possible is no longer possible. See for
example #591 - therefore when using standalone debugger, use
the same sets of plug-ins/features as the product it is installed
in uses. The side effect is that the standalone debugger in this
use case will start slower and extra "stuff" will be present in
this UI.

For people just building the standalone debugger, provide a minimum
feature set. This will be many more bundles than before, but
should still provide a reasonably small set that starts well.

This simplification also includes removing the the duplicates set
of CDT docs (debug/org.eclipse.cdt.debug.application.doc). These
provided a simplified version of CDT's documentation targetted
at just standalone debugger. However there are a few problems related
to this duplication:

- The two sets of docs were not kept in sync
- The standalone docs appear in the online help, leading to
  duplicated entries
- With the config.ini changes above, there is no way to exclude
  the main docs in the standalone case, so remove the duplicate

A number of directly related clean-ups are included too:

- Remove the `ConfigGenerator.java` that stopped being referenced
  in PR #761
- Complete the removal of `build-standalone-debugger-rcp` profile
  that was started in #761. There is a small drawback to not having
  this profile, the standalone debugger is very slow to build
  compared to the rest of CDT. If this becomes a problem, restoring
  this profile along with the changes made in #761 is reasonable.
- bring debug.product's licenses up to date
- modernize command line args to eclipse when using debug.product

Fixes #781
2024-05-12 16:12:17 -04:00
..
cdtdebug.sh Change standalone debugger to no longer limit number of bundles 2024-05-12 16:12:17 -04:00
install.sh Change standalone debugger to no longer limit number of bundles 2024-05-12 16:12:17 -04:00
README Bug 458066 - cannot specify pid to Standalone Debugger 2015-01-29 17:24:25 -05:00

The CDT Stand-alone Debugger brings up an minimal Eclipse instance which has all that
is needed of the CDT plug-ins to debug a C/C++ executable.  Build is not supported.
Editing is allowed, but you will need to rebuild outside the Stand-alone Debugger for
those changes to manifest in your debugging session.

To install the Stand-alone debugger locally in your $HOME directory, run the install.sh
script found in the scripts sub-directory of the plugins directory in your Eclipse installation:

  ./install.sh

The install script will create a cdtdebugger directory in your $HOME directory.  This
directory will contain a config.ini file, a dev.properties file, and a cdtdebug.sh script.
The cdtdebug.sh script will start the debugger from the command-line.  The cdtdebug.sh script
does not have to be located in the cdtdebugger directory and can be moved if you prefer.

The script takes a few options which are mentioned below:

-data : workspace to use for your Eclipse session if you do not want the default
        $HOME/workspace-cdtdebug
        
-consoleLog : if you want error messages reported directly to the command console

-a [pid] : specify attaching to an existing executable running on system.  If no pid is
           specified, a dialog will be brought up to allow you to select an executable
           from the list of existing processes.  The same dialog will be brought up if
           the specified pid is invalid.  The pid is not used for a remote debugging 
           session triggered by the -r option described below.
           
-b $PATH : path to build log for an executable.  This will be used to figure out
           include paths and compilation flags.  This option assumes you will
           be using the -e option described below.
           
-c $CPATH : path to core-file.  This option must precede a -e option to specify an
            executable.
            
-e $PATH [args...] : path to your executable to debug plus any optional command line
                     arguments to pass to main().  This option must be last and should
                     not precede any other arguments as they will be treated as arguments
                     to main.

-r $ADDR:$PORT : remote debugging towards hostname or IP address $ADDR and IP port $PORT.
                 The gdbserver must be running on the target and waiting for a connection.
                 This option can be used at the same time as the -a option.  In such a case
                 a Remote-Attach session will be started allowing the user to attach to 
                 different processes on the remote target.  The user will need to press
                 the 'connect' button or use the context-menu of the Debug view to choose 
                 one or more processes to attach to. In this case the -e flag is optional, 
                 and when not specified, a dialog will be used instead to prompt for the 
                 binary's location. This option, when used without -a, will trigger a
                 manual Remote debugging session to a single, pre-selected binary, and 
                 therefore requires the use of the -e option to specify the location of
                 the binary on the local machine that matches the one on the remote target.
                     
If no -a or -e option is specified, the last executable debugged via -e will be offered for
debugging.  Otherwise, if this is the first time, a dialog will be presented to enter
an executable, build log, and program arguments.

  e.g. ~/cdtdebugger/cdtdebug.sh -b ~/build.log -e ~/myproject/bin/a.out arg1 arg2

The cdtdebug.sh script that is found in the plug-in can also be run directly, but cannot
be moved.  The one installed in the cdtdebugger directory on the other hand, can be moved.