Appendix D Creating C Components


Debug C components

To debug a component you must run the debug version of the Jaguar server. Then you can attach your debugger to the server executable and set breakpoints to step into your component code.

Running the debuggable version of the server

On UNIX, run the script $JAGUAR/devbin/srvstart_dev.

On Windows NT, use the Jaguar Server (dev) icon to launch the debuggable server. Alternatively, run the script %JAGUAR%/bin/serverstart_dev.bat.

Debugging the component

In order to debug components, you must be running the debug version of the server. Follow the steps below to attach to the Jaguar server and step into your component code:

  1. Attach the Jaguar server process with your debugger.
    Alternatively, start the debugger with the Jaguar executable. For example, on UNIX, enter:
    dbx $JAGUAR/devbin/jagsrv ServerName


    On Windows NT, enter:
    msdev %JAGUAR%\devbin\jagsrv ServerName


    ServerName is the name of the Jaguar server. If you are using the preconfigured server rather than one that you created yourself, use "Jaguar."
  2. Set a breakpoint on the function jag_dbg_stop. This function executes every time the server loads a component DLL. The jag_dbg_stop prototype is:
    void jag_dbg_stop(char *compName)

    The compName parameter specifies the name of the library or shared library that was just loaded. Several components may be loaded before yours. In the debugger, display the compName value when the jag_dbg_stop breakpoint is tripped, and monitor the value to determine when your component is loaded. Breakpoints on jag_dbg_stop are triggered before the Jaguar server calls the component's create method.

    Note   Make sure the jag_dbg_stop breakpoint is set before your client application instantiates any stub objects.

  3. When your component's DLL is loaded, you can specify the component's C function names as breakpoints and step into the method's code when it is invoked. Note that the actual C function names exported by the DLL will not match the method names that you see in your source code. The next section describes how to determine the C function names for your methods.

Determining actual function names for your methods

In many operating systems, all functions in a single executable must have unique names. For this reason, the generated skeleton code contains macros that rename each method with a longer name at compile time. The final name is guaranteed to be unique among installed components. You must use these longer names to set breakpoints when debugging.

To view the name mappings, look at the generated skeleton header file for your component. There will be a macro that renames each method. The final method is renamed according to this syntax:

package_component_method

where package is the package name, component is the component name and method is the method name.

For example, the component named "sendrows" in a package named "jagdb," is renamed as follows:

#define    send_rows     jagdb_sendrows_send_rows

 


Copyright © 2000 Sybase, Inc. All rights reserved.