Debug executable started from another command

Sysprogs forums Forums VisualGDB Debug executable started from another command

Viewing 8 posts - 1 through 8 (of 8 total)
  • Author
    Posts
  • #9525
    Al-Cambridge-UK
    Participant

    Hi,

    my requirement is to develop a CUPS filter on a Raspberry Pi, so I need to debug an executeable which was started from some other process rather than directly from VisualStudio+VisualGDB.

    To start with, I have written a simple shell script HelloCUPS.sh
    /usr/lib/cups/filter/HelloCUPSFilter param1 param2 param3

    I would like my debug session to run this script, and then to debug into the executeable HelloCUPSFilter when it starts.

    In the VisualGDB Debug settings, I selected mode Debug with a custom gdb stub and customised to run the command ./HelloCUBS.sh

    The Run command now button gives expected program output (at this stage just a dump of the arguments), but running the debugger doesn’t hit breakpoints in the source.

    I am sure there must be a neat way to do this, so I would welcome any suggestions.

    Thanks in advance,
    Alasdair

    #9526
    Al-Cambridge-UK
    Participant

    Here is the entirety of the HelloCUPSFilter program…

    #include <stdio.h>

    int main(int argc, char *argv[])
    {
    for( int i = 0; i < argc; i++ )
    {
    printf( “argv[%d]=%s\n”, i, argv[i] );
    }

    return -1;
    }

    #9527
    Al-Cambridge-UK
    Participant

    And here is the GDB Log…

    VisualGDB is licensed to Alasdair Hayden-Wright at Synoptics Ltd
    o21: gdbserver exited with code 255
    at yy.j1()
    at yy.w_2(DebugCustomizationSettings a)
    at di.l2()
    at VisualGDB.GDBDebugEngine.o(mk1 a, e b)

    #9530
    support
    Keymaster

    Hi,

    Please try configuring it as follows:

    1. In GDB Start mode select “start new instance”
    2. In “debugged program” select “/bin/sh”
    3. Set program arguments to <script file> <arguments>
    4. Add the following 2 commands to pre-debug commands:
    file <your executable launched by the script>
    set follow-fork mode child
    
    

    This should force gdb to start debugging sh with your script and then automatically switch to debugging your program once it gets started by the script.
    This will not work with gdbserver though and will require launching gdb on the target machine directly.

    #9570
    Al-Cambridge-UK
    Participant

    I’m afraid that I don’t understand that last sentence.

    I would be grateful for instructions to launch gdb on the target machine, please.

    #9606
    support
    Keymaster

    Hi,

    Sorry for the delayed reply. When you are using a cross-toolchain, VisualGDB builds the code on the Windows side and then deploys the file to the Linux machine and runs gdb on Windows (same machine that builds the code).

    In order to follow the steps above, please copy the current configuration via the VisualGDB Project Properties and change the build machine for that configuration to be your deployment machine. Then follow the steps described earlier to configure debugging.

    For your convenience we have made screenshots of the relevant settings:

    The /tmp/path-to-executable should match the location on the Linux machine where your executable is deployed.

    Note that this configuration should not be used to build the project, it’s just a workaround to start debugging with gdb on a different machine without using the features of the Custom edition.

    #9640
    Al-Cambridge-UK
    Participant

    Thank you for your reply, but I must apologise that I still don’t understand how these settings work.

    I do not understand from your last comment “this configuration should not be used to build the project” how to start debugging without compiling.

    I will summarise my requirements:

    • I am using VisualGDB Classic Linux edition to cross-compile for ARM and debugging on a Raspberry Pi over network. This has worked successfully for a number of projects over the last year.
    • I am developing a filter for CUPS printing, HelloCUPSFilter, and the difference here is that the executable will be started by another process. I am simulating this by calling the executable from within a command shell file, HelloCUPS.sh. My executable is deployed to the path /usr/lib/cups/filter. Initially my program merely prints the program arguments.
    • The source files to debug are therefore on my Windows computer, not on the deployment machine, pi@192.168.0.216.

    Your screenshot for Project settings doesproject settings not show settings for “File synchronization”.

    Your screenshot for Debug settings does not show settings for “Deploy main executable to” or “Deploy condition”.

    Please provide clear instructions for all steps in the process, and please assume that while competent I do not have detailed knowledge of your product.

    Thanks, Alasdair

    #9688
    support
    Keymaster

    Hi,

    Sorry for the confusion. We will try to explain it from scratch.

    Visual Studio uses a concept of configurations (e.g. Debug/Release) to build different variations of your program. You can switch those configurations via the Visual Studio toolbar (the default configuration is “Debug”). VisualGDB follows this concept and also allows having multiple configurations per project. If you open VisualGDB Project Properties and click “Configuration: Add” -> “Create a copy of current configuration”, VisualGDB will copy the build and debug settings from the current configuration (e.g. Debug) to another one (e.g. Debug2). You can then switch between those 2 configurations to quickly switch between different sets of settings.

    After you create the “Debug2” configuration please go to the Project Settings page and select your target machine in the “Computer used for building and debugging” field. Then uncheck the “deploy executable on a different machine” checkbox. This will make Debug2 a “direct build” configuration that will allow running gdb directly on the Linux machine without the use of gdbserver. The Debug Settings page will change (e.g. the “Deploy the main executable to” will disappear).

    As you are still building your project on the Windows machine, you would need to switch to the regular “Debug” configuration to build it, then try debugging it so that it is deployed and then switch to “Debug2” to debug it in the direct mode desribed above.

    You can also avoid the need to create a separate configuration by upgrading to the Custom edition. Then you will be able to tweak the normal “Debug” configuration to run gdb on the target machine. This process is described in detail in this thread: https://sysprogs.com/w/forums/topic/debugging-child-process/

    Hopefully this clarifies the necessary steps. If you need further details, please let us know.

Viewing 8 posts - 1 through 8 (of 8 total)
  • You must be logged in to reply to this topic.